How to Size a VPS for Your Workload

Size a VPS by what your workload actually needs, with a little headroom, and resize when the numbers tell you to, not by guessing big out of fear. Most people either overpay for a box that sits half-idle or starve a cheap one until the app falls over. Both are avoidable. Right-sizing is a short, repeatable process, and getting it right is a big part of why self-hosting a fleet costs a fraction of managed cloud. Here is the method I use.

Start from a boring truth: RAM is usually your binding constraint, not CPU, and disk is cheaper than either. Size for memory first, watch the real numbers, and adjust.

Start with what your workload actually is

Before picking a plan, name the shape of the work. Different shapes want different boxes.

A typical web app plus database is memory-bound. The database wants RAM to cache its working set, the app runtime wants RAM per process, and CPU sits mostly idle between requests. Size for memory and you are fine. A background job system that crunches data or renders things is CPU-bound and wants cores. A media or file-heavy app is disk-bound and wants space and fast storage more than cores. Most portfolio apps are the first kind, which is why one modest box can hold several of them, the pattern behind one Postgres box under every app.

Write down your shape first. It decides which number you optimize.

How much CPU, RAM, and disk to start with

Concrete starting points, then measure.

For RAM, add up the baseline memory of each thing that runs: the database, the app runtime times the number of processes, the reverse proxy, any workers. Total it, then add roughly fifty percent headroom for spikes and caching. That headroom is not waste; it is what keeps the box from swapping under load, which is where performance falls off a cliff.

For CPU, most request-response apps are happy with a couple of cores because they spend their time waiting, not computing. Only reach for more cores if your work is genuinely compute-heavy. For disk, start with a comfortable multiple of your current data so you are not resizing storage every few months, and remember databases and logs grow quietly. Underprovisioning here is a common self-hosting mistake, one of several I catalog in self-hosting mistakes to avoid.

Measure before you resize

Guessing is how you overpay. Measuring is how you get it right. Put a monitoring stack on the box, or on a box watching it, so you can see real CPU, memory, and disk usage over normal traffic.

Look for the honest signals. Memory consistently near full with swap activity means you are RAM-starved: size up. CPU pinned at a hundred percent during normal load means you need cores. Plenty of free memory and low CPU across a full week means you overbought and can size down or pack another app onto the box. Those numbers turn sizing from a fear-driven guess into a decision, and standing up that visibility cheaply is exactly what I covered in self-host your monitoring instead of paying per host.

Right-sizing is easy because you own the box

Here is the part that makes this low-stakes: on a VPS, resizing is a plan change and a reboot, often a few minutes of downtime you schedule. You are not locked into your first guess. So do not overbuy out of fear that you will be stuck; you will not be.

That reversibility is a quiet advantage of the owned stack. You start reasonable, watch the numbers, and scale the box to the workload as it grows, paying for what you actually use instead of a fear premium. Compare that to managed platforms where capacity decisions get tangled in per-service pricing and you cannot cleanly consolidate, a difference I break down in PaaS versus a self-hosted VPS.

Pack, do not sprawl

The portfolio move is not one big box per app. It is a right-sized box holding several quiet apps, because most apps are idle most of the time and their peaks rarely line up. Size the box for the combined baseline plus headroom for the busiest one, and you get far better utilization than a fleet of near-empty single-app servers.

That packing is the difference between a hosting bill that scales with your app count and one that scales with your actual load. It is the core economics of running a portfolio solo, and it only works when you control the box.

I built my hosting stack, HostSSH, around this: pick a sensible box, watch the real numbers, pack apps until the metrics say add capacity, then resize in minutes. Right-sizing is not a one-time guess you have to nail. It is a small habit of measuring and adjusting, and owning the box is what makes that habit cheap.