Tuning a $5 VPS So It Stays Fast: Swap, Worker Counts and Memory Budgets

Most sub-$6 VPS plans do not fail because the hardware is bad. They fail because the default configuration assumes more memory than the plan has. Three settings decide whether a cheap server feels responsive or locks up under load: swap size, application worker counts, and the memory you leave free. This is a configuration tutorial — every command below runs on a standard KVM Ubuntu 24.04 box.

Step 1: Measure what you actually have

On a freshly provisioned 1 GB plan, the kernel and systemd already consume 150–250 MB before you install anything. Check the real numbers first:

free -m — shows total, used, buff/cache and available memory.
swapon --show — confirms whether swap exists at all (often it does not on budget templates).
systemd-analyze blame | head -20 — finds services you never asked for.

On a 1 GB plan you can expect roughly 750–820 MB of “available” memory at idle. That is your true budget, not 1024 MB.

Step 2: Size swap for your plan tier

Swap is not a substitute for RAM, but a small, correctly configured swap file prevents the OOM killer from terminating your web server during a memory spike. A practical 2026 rule for budget plans:

Plan RAM	Recommended swap	swappiness
512 MB	1 GB	30
1 GB	2 GB	20
2 GB	2 GB	10
4 GB+	2–4 GB	10

Create it with fallocate -l 2G /swapfile, then chmod 600, mkswap, swapon. Add it to /etc/fstab so it survives reboot. Lower swappiness means the kernel prefers dropping cache over swapping — appropriate for a server, wrong for a desktop.

Step 3: Cap your application workers

This is where cheap plans most often break. PHP-FPM and Node both default to worker counts sized for a large server. A 1 GB box running the default 5 PHP-FPM children at ~60 MB each can consume 300 MB of your 800 MB budget on idle workers alone.

PHP-FPM: set pm = dynamic, pm.max_children = 4–6 on 1 GB, 8–12 on 2 GB. Match to RAM ÷ 60–80 MB.
Node.js: run a single process with a cluster size capped by --max-old-space-size=256 on 1 GB.
MySQL/MariaDB: set innodb_buffer_pool_size to 25–30% of RAM. Defaults on a cheap plan can exceed total memory.
Redis: set maxmemory and a maxmemory-policy allkeys-lru so it degrades instead of growing.

Step 4: Budget the memory explicitly

Write down an allocation before you deploy. A realistic 1 GB plan breakdown might be: OS 180 MB, web server 40 MB, PHP-FPM 300 MB, database 300 MB, Redis 60 MB, cache/buffers 100 MB. That leaves almost nothing — which is the point. When the numbers are visible you stop stacking services onto a plan that cannot hold them.

If your budget breakdown shows you need 1.4 GB on a 1 GB plan, the right move is a 2 GB plan, not aggressive tuning. Two-gigabyte plans cost only a few dollars more in 2026 and double your effective headroom — you can compare budget VPS plan tiers and their included RAM here before you decide.

Step 5: Verify under load

Configuration without measurement is guesswork. Before going live, confirm the server behaves:

Run htop and watch available memory for one minute of real traffic.
Check vmstat 1 for sustained si/so (swap in/out) above zero — any steady swapping means you are over budget.
Enable a free monitor (Netdata, or a cron running free -m to a log) and a Uptime Kuma check.
Restart the app and confirm the OOM killer has not fired: dmesg | grep -i oom.

What not to bother with on a budget plan

Skip server-side page caches stacked on top of each other, heavyweight control panels, and multiple databases for one app. Each adds 50–150 MB of overhead you can spend on workers instead. The goal on a cheap VPS is not a feature-complete stack — it is a lean one where every process earns its memory. For a full picture of what each budget tier can realistically hold, see the spec and price comparison on the homepage.