Shared Hosting Account Density Calculator

So there you are with a brand-new server and a list of potential customers. How many accounts will you cram in there before somebody complains? The answer isn’t as glamorous as you might hope.

There’s a skill to packing shared servers… It’s not simply a question of shoving square pegs into round holes. It’s a delicate balance of raw capacity and operational sanity, it also involves the friction generated by too many neighbors competing for the same resource.

How to Plan Server Space Wisely

Many hosts falls into the trap of considering CPU core or storage as single numbers. They ignore the resources required for each account. These include session files, local backups, and temporary restore points. They also include the occasional plugin update that spikes resource use for a brief moment then stays behind as logs.

This is why the calculator doesn’t simply divide your plan size by your total disk space. Instead, it factors in these hidden expenses and makes you consider a reserve against noisy neighbors. This reserve is actualy an insurance policy against some poor coder’s script running at 2 AM. But most of that comes down to knowing what’s really being measured.

The CPU limit isn’t referring to a millisecond peak usage. It refers to the amount of sustained load average that makes your site feel slow or fast. You may have a server with sixteen cores but split it among accounts doing heavy PHP processing and you’ll reach queue limits before reaching hardware ceiling. And that’s where folks get confused. They buy into compute power assuming it converts directly into account count, they fail to account for how context switching kills performance long before you exhaust the processor by running out of cycles.

This is all memory, which behaves different than storage. Memory is a finite bucket that eventually gets full. At that point, it begin to page out to disk, which will quickly make an NVMe drive a bottleneck. And remember: Before a single customer account has been set up, the control panel eats some memory, as does the operating system and the database engine on top of it. Ignore these base amounts, and your math will, to put it politely, be rosy.

And then there’s inodes. That’s usually the quiet killer. A user can have gigabytes of free space and still run out of file entries. This can happen because of a full mailbox with many separate message headers or an exploded WordPress cache directory. Inode exhaustion doesn’t look like a disk full error. It will look like a permission denied message, which confuses both the support agent and the customer. If you plan for inode density, you accept that small files multiply far more quickly then you’d expect.

One unpredictable factor is that there’s no way to accurately capture in a spreadsheet what support capacity actualy looks like. If you don’t take into account the human cost, yes, you can fit three hundred accounts on a machine. But when it’s migration day (or when half those sites tank from a core update), your team drowns in tickets. Your support bandwidth protects your reputation far more effectively than any hardware spec will ever do.

Oversell is a great way to market your service; it’s a terrible way to plan if you consider it a target. A sensible oversell policy requires the understanding that not every customer will need her share at once. That assumption holds true for storage until you have a few large backup files sitting in staging areas. Either calculate overhead before applying your oversell multipliers or discover you’ve been selling a commodity you don’t possess.

These trade-offs are reflected in the different server profiles, for which the tool provides some default settings. An enterprise NVME node is not at all the same as a micro VPS. One may have high RAM and less support. The other might limit on CPU queues despite having more cores. Knowing what will be your limiting factor can help you know if you should optimize limits of software or upgrade your hardware.

Ultimately, then, density planning comes down to restraint. Adding another server is far simpler than migrating three hundred pissed-off clients whose sites has started timing out. You should of had enough headroom so that spikes aren’t crises. The math provides your ceiling. A good host design hovers several floors beneath it.