Sizing a VPS when moving from shared hosting

The right VPS size comes from your current usage, not guesswork. Read your cPanel graphs for CPU, memory, disk and bandwidth, then map them to vCPUs, RAM, storage and data transfer. Start near cPanel’s own baseline for a control‑panel server, enable caching, and plan to scale in Virtualizor rather than buying the biggest plan.

This picks up from a cPanel account you can log in to on your current host.

Before you start

• You will size against real numbers from cPanel. In cPanel you can see bandwidth history, disk footprint and (on most shared platforms) CloudLinux Resource Usage. These are the foundations of your plan.
• Decide if you will run cPanel on your VPS. cPanel has clear system requirements: for AlmaLinux 9 and Ubuntu 24.04 LTS the minimum is 2 GB RAM with 20 GB disk, with 4 GB RAM and 40 GB disk recommended. Installation and upgrades also need an extra 5 GB of working space in /usr/local/cpanel. These are floors, not targets.
• OS choice for cPanel: AlmaLinux 9 or Ubuntu 24.04 LTS. AppArmor on Ubuntu is supported. SELinux must not be used for cPanel.
• Understand why a panel needs more RAM than shared hosting: on shared, the provider runs the database and mail stack for many customers. On a VPS with cPanel you run your own web server, PHP‑FPM, MariaDB, Exim, Dovecot and cPanel’s daemons such as tailwatchd and chkservd. These consume memory even when your site is idle.
• If you enable extras such as ClamAV for antivirus, add more memory. cPanel notes that with ClamAV you should plan at least about 3 GB total RAM.
• Do not oversize disk and expect to shrink later. Shrinking virtual disks in place is unsafe and often unsupported. Plan conservatively and grow later.
• On KVM a vCPU is a schedulable thread, not a dedicated physical core. Leave headroom if you have bursts.
• Caching matters. Page caching and persistent object caching such as Redis or Memcached reduce the CPU, PHP worker and database load you need to provision for.

Step 1: Read your current resource use in cPanel

Most shared cPanel servers run CloudLinux. Its Resource Usage plugin (LVE) is the primary place to translate your current limits and peaks into VPS CPU and RAM.

• CPU: In the LVE interface, find your CPU usage over time. CloudLinux expresses CPU SPEED as a percentage of one core. 100% is roughly one core, 200% roughly two cores. If you see “CPU Usage X/200 (%)”, your account could burst to around two cores on that server.
• Memory, I/O, IOPS, processes: Note your typical and peak usage. Spikes here can inform your RAM target and whether to use caching.
• Entry Processes (EP): This is the number of concurrent new entries into your account’s limits, typically HTTP or PHP requests. Sustained EP faults indicate concurrency pressure and inform PHP worker count and vCPU sizing.
• Bandwidth: In cPanel go to Metrics → Bandwidth. This shows daily and monthly transfer totals and peaks. Use this to choose a monthly data transfer allowance.
• Disk: In cPanel go to Files → Disk Usage, and also check “Database Disk Usage” in the right‑hand sidebar. Add files, mailboxes and databases to get your current footprint.

Step 2: Convert CPU graphs into a vCPU count

Map your CloudLinux CPU percent to vCPUs on the VPS. Use SPEED as the anchor: 100% means about one core, 200% about two, and so on. Look at your typical and peak usage:

• If you average around 30–70% with peaks below 120%, 1–2 vCPUs is a sensible start.
• If you often sit near 150–220% or hit that region during busy periods, plan for 2 vCPUs and use caching to lower peak pressure. Consider 3–4 vCPUs only if you see sustained higher use and concurrency.
• Check EP faults. Many EP faults suggest you need more PHP workers and possibly another vCPU to keep latency down.

Remember: a vCPU on KVM is a scheduled thread. If your traffic is spiky, add a small margin rather than running at the limit.

Step 3: Set a RAM floor for a control‑panel VPS

Because you will run the whole stack, start from cPanel’s system requirements, not from your shared account’s RAM cap.

• AlmaLinux 9 and Ubuntu 24.04 LTS: minimum 2 GB RAM, 20 GB disk; recommended 4 GB RAM, 40 GB disk.
• Reserve RAM for services: web server, PHP‑FPM, MariaDB (now the default SQL server for new cPanel installs), Exim, Dovecot and cPanel’s own daemons. If you enable mail scanning with ClamAV or search indexing, add more memory again.

A good starting point for most cPanel VPS builds is 4 GB RAM with 1–2 vCPUs, rising if your database or PHP workload is heavier. You can raise RAM later in Virtualizor without data loss.

Step 4: Plan database memory with InnoDB in mind

New cPanel installations use MariaDB by default. MariaDB and MySQL store most data in the InnoDB buffer pool, which is typically set to about 50–75% of system memory. On a small VPS this can dominate memory use if you are not careful.

• If your site is read‑heavy or runs large queries, prioritise RAM for the buffer pool within that 50–75% guideline, then size PHP workers to fit the remainder.
• Do not over‑allocate the buffer pool on a small VPS. Leave enough memory for PHP‑FPM, web server, mail and cPanel services or you will swap.

Step 5: Plan PHP workers from measured memory

Each PHP‑FPM child processes a single request. The setting pm.max_children caps the simultaneous requests per pool. The correct value comes from your available RAM and the real resident size (RSS) of a PHP worker on your stack, not from a guess.

Use this formula once the site is running on a staging VPS: pm.max_children = floor(available_for_PHP / average_worker_RSS). Start low and raise carefully. Defaults as low as 5 can bottleneck busy sites. Setting it too high can exhaust RAM and trigger the OOM killer.

To measure PHP‑FPM worker RSS after you deploy. These commands are the same on AlmaLinux 9 and Ubuntu 24.04.

List PHP‑FPM worker processes with their RSS in kilobytes, then average it:

ps -o rss,cmd -C php-fpm | awk '/php-fpm: pool/ {sum+=$1; n+=1} END { if (n>0) printf "Average RSS per worker: %.1f MB\n", sum/(n*1024); else print "No workers found"; }'

This prints the average resident memory per worker in MB. Use it with the RAM you have reserved for PHP to compute a safe pm.max_children.

Step 6: Add swap for safety

Swap gives the kernel breathing room during updates and short bursts. cPanel’s guidance:

• 2 GB RAM or less: swap equals 2 × RAM
• 2–4 GB RAM: swap equals RAM
• 4 GB RAM or more: 4 GB swap

Create a swap file. These commands are the same on AlmaLinux 9 and Ubuntu 24.04.

Check current memory and swap so you know your baseline:

free -h

Create a 4 GB swap file with secure permissions, format it as swap, enable it, then make it persistent at boot:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Re‑check to confirm swap is active:

free -h

Step 7: Size disk and inodes with headroom

From cPanel’s Disk Usage and Database Disk Usage you have your current footprint for files, mail and databases. Start from that number and add:

• cPanel’s own recommended 40 GB system space, plus the extra 5 GB required for installation and upgrades in /usr/local/cpanel.
• Logs, mailboxes, MySQL data growth, and local backups if you keep any on the server.
• Inodes: if you use a single partition, cPanel advises at least 1,000,000 inodes plus about 50,000 per cPanel account. You can run out of inodes before GBs are used.

Do not plan to shrink a large virtual disk later. Industry documentation warns that in‑place shrinking is unsupported or risky, and tools like qemu-img require explicit acknowledgement of potential data loss. Provision a sensible size and grow later if needed.

Step 8: Estimate monthly data transfer

Use cPanel → Metrics → Bandwidth to read daily and monthly patterns. Look for the busiest months and the shape of traffic during peaks. Choose a bandwidth allowance that covers your busiest month with a margin for growth.

Step 9: Choose a starting Hostworld plan and keep scaling in mind

Bring it together:

• vCPU: map from CloudLinux SPEED. Most small to medium sites start well on 1–2 vCPUs if caching is enabled and EP faults are under control.
• RAM: start at 4 GB for a cPanel VPS running web, PHP and MariaDB. Increase if your LVE memory graphs were high, your database is large or you enable extras such as ClamAV.
• Disk: your cPanel Disk Usage + Database Disk Usage total, plus cPanel’s 40 GB system space and the extra 5 GB install/upgrade space, plus room for logs, mail and backups. Do not over‑provision with the idea of shrinking later.
• Bandwidth: pick based on cPanel’s Bandwidth graphs with a growth margin.

It is easier and safer to scale a VPS up later than to start needlessly large. In our Virtualizor panel you can increase CPU and RAM after deployment on KVM without data loss. That encourages you to start right‑sized, keep costs sensible, and avoid risky disk shrink operations later.

If you are ready to choose, see Linux VPS. We operate our own UK data centre in Maidenhead, Berkshire, and a US location in New York.

Step 10: Verify and tune on the VPS

After you migrate a copy of the site, check that your plan matches real use. These commands help you confirm and tune. The commands are the same on AlmaLinux 9 and Ubuntu 24.04.

See current RAM and swap so you can check headroom during a traffic burst:

free -h

Watch top processes by memory to confirm where RAM is going:

ps aux --sort=-%mem | head -n 15

Check the average PHP‑FPM worker RSS again after a few minutes of traffic. This informs pm.max_children as described earlier:

ps -o rss,cmd -C php-fpm | awk '/php-fpm: pool/ {sum+=$1; n+=1} END { if (n>0) printf "Average RSS per worker: %.1f MB\n", sum/(n*1024); else print "No workers found"; }'

Inspect the InnoDB buffer pool size to confirm it matches your plan. This prints the value in bytes:

mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

If you find that memory is tight, lower pm.max_children based on the measured RSS, reduce the InnoDB buffer pool a little within the 50–75% guideline, and enable or tighten caching. If CPU sits near 100% for long stretches, raise vCPUs in Virtualizor. If you need advice, please open a support ticket.

Step 11: Why the biggest plan is the wrong instinct

Your shared account’s LVE graphs, cPanel Bandwidth and Disk Usage already show your real peaks. cPanel’s own documentation sets the practical floor for panel‑based VPS sizing: about 2–4 GB RAM and around 40 GB disk, with 5 GB extra for upgrades. Start near that with 1–2 vCPUs, set PHP workers and database buffers based on measurements, enable caching, and grow as needed. In Virtualizor, scaling up CPU and RAM later is straightforward. Oversizing on day one costs more, hides configuration issues, and tempts unsafe attempts to shrink disks later.

What next

If you want a broader view of running and tuning a VPS with us, browse our VPS guides. If you are ready to proceed, pick a plan at Linux VPS and build against the sizing you calculated here.

Next step: deploy your VPS and install cPanel, then tune PHP‑FPM and MariaDB using the measurements above. If anything here does not line up with what you see, please open a support ticket and we will review your numbers with you.