A server with ten mostly static sites can behave differently from a server with one busy store. Site count is a licensing and inventory concept, not a reliable hardware-sizing formula. Start with the application paths, services and jobs you must support, then measure their combined behavior. The goal is enough headroom for normal work and predictable recovery, not the smallest idle-memory screenshot.
List demand that overlaps
Include uncached PHP requests, database work, search, image processing, scheduled jobs, mail filtering and backups. Consider when they overlap rather than adding unrelated peaks as though they always happen together—or assuming they never do.
Traffic shape matters. A small number of long-running requests can occupy workers while CPU remains moderate. A burst of compute-heavy requests can saturate CPU quickly. Distinguish requests served from cache from requests that execute the full application.
Build an example memory budget
Suppose a hypothetical 8 GiB host needs 3 GiB for measured base services and operating headroom. The remaining 5 GiB is a provisional application budget, not a guarantee of safe demand. Estimate representative worker memory, database variation and other concurrent jobs before allocating it.
Do not multiply PHP memory_limit by a customer count and call the result measured use. That limit is a per-script ceiling. Conversely, a low idle footprint does not represent the memory needed during imports or image processing. Measure representative work and leave room for spikes.
Read CPU and memory together
A CPU quota and a vCPU count are different concepts. Provider CPU sharing, application behavior and storage latency affect practical performance. Compare response time and errors with repeated CPU, memory and I/O observations rather than using one load average as a verdict.
The commands below offer a read-only baseline. They do not generate load. Use authorized application requests and repeat observations during known busy windows. If a tool is missing, consult your managed-server policy before installing packages.
uptime
free -h
vmstat 1 5
ps -eo user,pid,pcpu,pmem,comm --sort=-pcpu | head -n 15Include storage and recovery space
Database exports, temporary uploads, logs, retained update packages and account backups consume space beyond live website files. Track inodes as well as bytes. A filesystem can refuse new files even when its block-usage view looks acceptable.
Storage latency can make a host appear slow without CPU saturation. Keep off-server backups and a documented restore process. A larger disk is not automatically faster, and a second directory on the same failing disk is not an independent recovery destination.
Capacity is not latency
Free storage can coexist with slow writes. Compare application response and storage pressure rather than assuming a filesystem with spare bytes has no I/O bottleneck.
Set a review threshold before customers suffer
Define conditions that trigger investigation: repeated application errors, sustained queueing, persistent swapping, low disk headroom or a backup window interfering with interactive traffic. First identify waste or a fault; then decide whether tuning or resizing is appropriate.
For EzePanel, license account capacity is separate from hardware capacity. Use the installed server-health evidence and application results to plan growth. Revisit the budget when changing PHP runtimes, adding mail services or onboarding a materially different workload.
Use workload groups to budget RAM for multiple websites
Group websites by behavior: mostly cached content, frequently uncached PHP, database-heavy work and scheduled jobs. Measure representative memory and request concurrency for the relevant periods. Ten quiet websites can require less capacity than one busy application, so site count alone is an unreliable sizing rule.
Budget shared services and recovery headroom before allocating the remainder to application workers. Account limits and plan labels do not create more hardware. Review whether backup windows or mail activity overlap the busiest web period, and use the resulting evidence to decide between tuning, workload separation and a larger VPS.
Where to go next
Sources & further reading
Official documentation for the topics in this guide. Check current vendor requirements before a purchase or server change.
