Scaling a VPS is usually a resize and a reboot. The decisions worth making are which resource to add, whether to scale up or out, and whether the problem is capacity at all, because a great deal of scaling is buying headroom for an inefficiency.
Find out what is actually short
Before adding anything, measure. The three resources fail differently and the fixes are not interchangeable.
Memory exhausted means processes are being killed and the machine is swapping. This one causes outages rather than slowness, and it is usually the right thing to add.
CPU saturated means real work is happening. Find out what before buying more. One expensive query or one badly-behaved process often accounts for most of it.
Disk full is rarely genuine growth. Logs without rotation, backups written locally, package caches. Clearing those is a permanent fix; adding disk schedules the same conversation.
Managing VPS resources goes over reading the numbers.
Fix the cheap things first
Three changes routinely buy more headroom than a resize, and cost nothing.
Caching. A cached page never starts the application at all. On a database-backed site this is usually the largest single gain available.
The database. One missing index can dominate CPU on an otherwise idle server. Slow query logging finds it in an afternoon.
Images and static files. Serving oversized images consumes bandwidth and CPU on every request.
If none of those apply and the server is genuinely at capacity, scale.
Up or out
Scaling up: a bigger server, is simpler and usually right. No architectural change, and one machine to maintain.
Scaling out: more servers, adds real complexity: a load balancer, shared session storage, a strategy for files that were previously local, and a database that is now the shared bottleneck.
Scale up until the ceiling is genuinely reached. Scaling out for redundancy is a legitimate separate reason, but it is a different project and should be recognised as one.
Resizing is not always symmetrical
Adding CPU and memory is usually straightforward: resize, reboot, done in minutes.
Disk frequently cannot shrink. Many providers allow growing a volume and not reducing it, which means an oversized instance commits you to paying for it indefinitely.
That asymmetry is the argument for starting smaller than you think and resizing when the data says to.
Before you resize
Take a snapshot, expect a reboot, and do it outside your busiest period.
After the resize, confirm the operating system actually sees the new resources: a grown disk often needs the filesystem expanded before the space is usable, and it is easy to conclude the resize failed when only that step is missing.
Then check the application uses it
This is the step people skip, and it is why a resize sometimes appears to change nothing.
Databases, PHP process managers and application servers have their own configured limits, set when the machine was smaller. Doubling the server's memory does not tell any of them to use it, those numbers are in configuration files and stay where they were.
Review them after every resize. A larger machine running a configuration sized for the old one performs identically, and the money is spent for nothing.
For deciding when to do it rather than how, How to Plan Server Capacity and When to Scale deals with finding your real ceiling.
Growing storage specifically is three steps rather than one, and the provider only does the first. How to Add or Resize a Disk on a VPS explains the other two.
Measure across a week, not during the incident
A decision made from the worst ten minutes of a month buys capacity for a situation that happens rarely.
sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | tail -5
sar -r -f /var/log/sa/sa$(date -d yesterday +%d) | tail -5
vmstat 60 60 | awk 'NR>2 {print $4, $15, $16}' | tail
What matters is which single resource reaches its ceiling first and how often. A machine at 90 per cent memory for an hour each night has a different answer from one at 60 per cent all day with brief processor peaks.
Collect a week before deciding. It is the difference between buying the right resource and buying a larger version of everything, which is how a modest problem becomes a permanent cost.
A second machine needs the application to be ready
Moving from one larger server to two smaller ones sounds equivalent and is not, because several things silently assume there is only one.
Sessions. Stored on local disk, a visitor served by the other machine is logged out. They have to move to a shared store.
Uploads. Written locally, half the files exist on one machine only. They need shared storage or an object store.
Scheduled jobs. Copied to both machines, everything runs twice, including anything that sends mail or charges a card.
Each is small on its own and none is optional. Establish them before the second machine exists, not while traffic is arriving at both. Scheduling jobs with cron and systemd timers deals with the third.
What actually happens during the change
Providers describe resizing as a click, and the operational detail is what determines the outage.
Adding memory or processors is frequently possible while running; anything that reduces them is not. Disk growth needs the partition and filesystem extended inside the machine afterwards, which is a separate step with its own risk.
lsblk df -h / free -m; nproc
Take a snapshot immediately before, schedule it for the quietest hour you have, and read those three commands afterwards to confirm the machine received what you paid for. A resize that silently did nothing is common enough to check for rather than assume.
When the ceiling is not on this machine
Some slow sites are not short of anything locally, and resizing changes nothing at all.
curl -s -o /dev/null -w 'ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/
ss -tn state established | wc -l
time getent hosts api.example.com
A machine with idle processors, free memory and a slow response is waiting on something external: a database on another host, a payment or shipping API, a name lookup, or a third-party script.
The test is simple. If load is low while responses are slow, more capacity is the wrong purchase. Telling whether a slow site is the server or the site walks through separating them.