Advertised RAM on budget VPS plans is a marketing number, not a capacity figure. A $5 plan sold as “4 GB” typically leaves you with 3.4 to 3.6 GB once the kernel, systemd, and provider-side agents are running; a container plan marketed as dedicated often shows 25% of its memory as steal or cgroup limit. Normalising price per gigabyte of usable memory is the fastest way to rank offers that look identical on a pricing card.
This method takes about five minutes per provider and produces one comparable number, so you can stop sorting plans by sticker price. It works on KVM, LXC, and OpenVZ. If you want to see the finished numbers in context, the budget VPS plan comparison table is a useful cross-check against your own results.
Step 1: Measure usable RAM, not advertised RAM
Deploy the plan and read the kernel directly. Ignore the control panel, which almost always repeats the marketing figure. Run:
free -m | awk '/Mem:/ {print $2, $7}'The first number is total memory the kernel sees. The second is available memory with caches counted as reclaimable. On a fresh install with no application running, available is the number you should record — it is what your services can actually claim. Compare it to the advertised size. A gap of 5–10% is normal and comes from kernel and systemd overhead. A gap above 20% means the provider is reserving memory for its own monitoring or virtualisation layer, and you are paying for it.
Two secondary readings catch plans that measure well but perform badly:
cat /proc/meminfo | grep -i swap— swap on SSD is not free RAM, but 512 MB of swap is worth roughly 200–300 MB of effective capacity for a light web workload. Count it at half value.vmstat 1 5— look at the steal column. Sustained steal above 1 turns advertised memory into memory you cannot rely on, because the host is swapping your pages out
Step 2: Subtract the mandatory baseline
Usable RAM is not the same as billable workload RAM. Every server carries a fixed cost before your application starts: the OS, SSH daemon, journal logging, provider agent, and your chosen stack’s runtime. Measure it once on a clean image and reuse the number across providers.
| Baseline layer | Debian 12 minimal | Ubuntu 24.04 + Docker | Ubuntu + control panel |
|---|---|---|---|
| Kernel + systemd | 180 MB | 190 MB | 200 MB |
| SSH, cron, journald | 60 MB | 70 MB | 80 MB |
| Provider agent | 20 MB | 25 MB | 30 MB |
| Docker daemon | — | 110 MB | 110 MB |
| Panel stack (Apache, MySQL, PHP) | — | — | 450–700 MB |
| Total baseline | ~260 MB | ~395 MB | ~870 MB |
This is where the cheapest plans quietly lose. A 1 GB container with a panel installed has roughly 130 MB of actual room for your site — not enough for MySQL plus PHP-FPM under any real traffic. The same 1 GB with a bare Debian image and Nginx serving static files has 740 MB, which runs comfortably.
Step 3: Build the normalised price
Use this formula, all figures in US dollars and megabytes:
effective_mb = usable_mb - baseline_mb
normalised = monthly_price / (effective_mb / 1024)Include every recurring cost in monthly_price: base plan, mandatory IPv4 if it is not bundled, backup add-on you actually need, and the amortised cost of an annual prepay divided by twelve. A promo price applies only to the months it covers — if the first year is $3 and year two is $9, use $6 as your planning figure.
Worked example: three plans at the same sticker price
All three cost $6 per month. All three advertise 2 GB.
| Plan | Advertised | Usable | Baseline (Docker) | Effective MB | $/GB effective |
|---|---|---|---|---|---|
| A — KVM, 4 vCPU, promo year 1 | 2048 MB | 1990 MB | 395 MB | 1595 | $3.85 |
| B — LXC, oversold node | 2048 MB | 1540 MB | 395 MB | 1145 | $5.36 |
| C — KVM, panel preinstalled | 2048 MB | 1950 MB | 870 MB | 1080 | $5.69 |
Plan A looks 40% cheaper per usable gigabyte than Plan C, and the two are the same hardware class — the difference is entirely the preinstalled panel and the memory the provider reserves. Plan B’s oversold node is worse still, and its steal time will widen the gap under load.
Where the metric misleads you
Price per usable gigabyte is the right first filter, not the whole decision. Three corrections matter:
- Memory is not the only constraint. A plan with 4 GB and 1 vCPU is worse value than 2 GB and 2 vCPU for a PHP site, because PHP-FPM workers are CPU-bound at modest memory. Run the same normalisation against cores using price per effective core.
- Small plans have a floor. Below about 3 USD per effective gigabyte, providers usually recover margin through IOPS caps or bandwidth metering. Check disk throughput before you congratulate yourself on the price.
- Renewal pricing resets the ranking. Repeat the calculation with year-two prices. The cheapest first-year plan is frequently the most expensive in year two, and that is the number that should drive a long-term commitment.
Running the audit across ten providers
Deploy the same minimal image on each candidate, record free -m available memory, and note the baseline for your intended stack. Ten servers at hourly billing costs a fraction of one month of overpaying, and the resulting table is directly comparable because every reading came from the same command on the same OS. Combine it with the plan-level pricing breakdown in the low-cost VPS hosting guides and you have both the measured memory and the real monthly bill in one place.
Store the numbers in a spreadsheet with columns for advertised RAM, usable RAM, baseline, effective RAM, price, and price per effective gigabyte. Rerun it whenever a plan renews. Oversold nodes drift, provider agents grow, and a plan that measured 3.85 in January can easily be 5.20 by December — usually without any visible change to the pricing page.
