Capacity Notes
Addon domains vs separate accounts — Six sites, one allocation, and no way to tell which one is spending it
Your portfolio grew one addon domain at a time, and now something is slow but the resource graph only knows about the account, not about which site inside it is responsible.
The short answer
Addon domains share one allocation: the same CPU, memory, entry processes and I/O budget, plus one security boundary and one suspension notice covering everything on the account.
That is efficient while every site is yours and low-stakes. It becomes a measurement problem the moment one of them earns money, because a single account's resource graph cannot tell you which document root is responsible. Below: how to find out anyway, and where the split pays for itself.
By the HostingFast team · Reviewed 24 August 2026
24/7
Support that answers
1-click
WordPress install
Free
SSL certificates
Daily
Backups, all plans
Adding a domain to an existing account takes about thirty seconds, which is exactly why portfolios accumulate them without anybody making a decision. The consequences are all deferred and all shared.
There are two of them worth stating precisely. Everything on the account draws from one resource allocation, so contention is invisible until it is acute; and everything on the account shares one fate, so a compromise or a suspension takes the whole set.
One allocation, several appetites
The account's resource usage graphs in cPanel report entry processes, CPU and I/O for the account as a whole. Six addon domains produce one line. When that line hits a ceiling you know the account is constrained; you do not know which of the six caused it, and that is the practical cost of consolidation.
You can recover the detail with a little work. Per-document-root access logs tell you request volume per site; slow query logs tell you which database is expensive; a WordPress profiler run on each candidate narrows it further. It is entirely doable, just slower than reading a graph.
The cheap habit that saves the most time later: keep each site's traffic and error logs separated and look at them before you touch anything. Most contention turns out to be one site, one plugin, or one bot.
What is shared, and what is not
PHP version is per site, so a legacy application and a current one can run side by side on the same account. That is genuinely useful and is often the reason consolidation looked attractive in the first place.
Memory, CPU allocation, entry processes and disk are not per site. Neither is the security boundary: a compromise reached through an abandoned plugin on the site you forgot about is a compromise of everything under that account, and the suspension that follows covers the lot.
Backups are per account too, which sounds convenient until you want to restore one site to yesterday without rolling back the other five. That is a restore-shaped problem, and it is easier to avoid than to solve.
What a separate account buys you technically
Its own resource allocation, so contention is contained. Its own graphs, so diagnosis is a glance rather than an investigation. Its own backup and restore boundary. Its own suspension boundary. And a clean handover if the site ever changes hands.
For your own low-stakes projects none of that is worth paying for, and the multi-site allowances make consolidation sensible — Turbo carries 25 sites on 20 GB of NVMe with 50 databases, Nitro carries 100 on 200 GB with two cores and 4 GB.
Once a paying client is involved, the calculation changes entirely. A reseller plan gives every client their own account with limits you define, which is the same isolation argument applied at a scale where it is also a commercial one.
Where the line actually sits
Draw it at money and ownership. If a site earns revenue, carries a brand worth protecting, or belongs to somebody else, it wants its own boundary. If it is a personal project you would shrug about losing, an addon domain is the right answer and always has been.
Hosting a client's or a friend's site as an addon domain on your personal account is the specific arrangement to avoid. Shared fate plus split ownership is what turns a favour into a dispute, and it costs a weekend to untangle rather than a few pounds a month to prevent.
Splitting later is not difficult — a site moves between accounts as files, a database and a DNS change — but it is easier to do before the site matters than after it does.
Diagnosis is the argument, not tidiness
People usually argue for separate accounts on organisational grounds. The stronger argument is diagnostic: one account produces one graph, and one graph cannot tell you which of your six sites is the expensive one.
Every account here runs NVMe behind LiteSpeed with per-site PHP version switching, so consolidation is at least on a stack that raises the floor for all of them.
- One account, one resource graph
- PHP is per site; CPU is not
- One compromise takes everything
- Split before the site starts earning
Why HostingFast
Standard on every plan
Per-site PHP version switching
A legacy application and a current one can share an account without sharing an interpreter version.
Resource graphs with history
Account-level usage over time, which is where a genuine ceiling becomes visible rather than assumed.
Generous multi-site allowances
Turbo runs 25 sites on 20 GB of NVMe; Nitro runs 100 on 200 GB with two cores and 4 GB.
Reseller isolation when it matters
Every client gets their own account with limits you define, which is the same argument at commercial scale.
Daily backups and self-service restores
A restore point every day, run from the panel, without waiting in a queue to get it.
Imunify360 and account isolation
Server-level protection with accounts walled off from one another on the machine.
Quick Start
From order to online
- 1
Separate the logs before you diagnose
Make sure each document root writes its own access and error log. One account produces one resource graph, and per-site logs are the only cheap way to work out which site is behind the line.
- 2
Profile the suspects individually
Run a profiler and check the slow query log per site rather than per account. Most contention resolves to a single plugin, a single query or a single bot hammering one document root.
- 3
Split anything that earns money
Move revenue-generating and client-owned sites onto their own accounts before an incident forces the issue. Files, a database and a DNS change is a small job today and an urgent one later.
Built In
Loaded onto every plan
- Per-site PHP version switching from the control panel
- Account-level resource usage graphs with history
- Turbo carries 25 sites; Nitro carries 100, both on NVMe
- LiteSpeed caching in front of PHP on every account
- Daily backups with self-service restores from the panel
- Imunify360 protection with accounts isolated on the machine
- Free SSL per hostname, renewed automatically before expiry
- Staging environments for testing a change before it ships
- Reseller plans when the sites belong to somebody else
- In-place upgrades between tiers, with no migration involved
Frequently Asked
What people ask us most often
Do addon domains get their own CPU allocation?
No. Entry processes, CPU, memory and I/O are account-level, so every addon domain draws from the same budget. That is why the account graph shows one line for six sites, and why contention is invisible until it is acute.
Can each addon domain run a different PHP version?
Yes — PHP version is set per site from the control panel, along with extensions. That is one of the genuinely useful properties of consolidation, and it lets a legacy application sit beside a current one without holding either back.
How do I find out which site is eating the account's resources?
Split the logs. Per-document-root access logs give you request volume per site, the slow query log gives you the expensive database work, and a profiler run against each candidate narrows it further. It is more work than reading a graph, which is the real cost of sharing one.
When does a separate account pay for itself?
As soon as a site earns revenue, carries a brand worth protecting, or belongs to somebody else. Below that, the multi-site allowances make consolidation entirely sensible. Above it, you are buying containment, your own graph and a clean handover — all cheaper bought in advance.
Keep reading
DirectAdmin vs cPanel for Resellers
Panel overhead and provisioning time once a reseller pool is genuinely populated.
Hosting With Imunify360 Security
Server-level protection for people who would rather not become security engineers.
How to Add an Addon Domain
The exact steps, with the document-root mistake flagged before you make it.
Reseller Hosting
White-label reseller hosting where every client gets their own account and their own limits.
VPS Hosting
KVM virtual servers with full root, DDoS filtering and one flat monthly rate.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Give the earners their own graph.
Multi-site plans on NVMe with per-site PHP, or separate accounts the moment a site starts mattering to somebody else.
View Reseller Hosting plans