A 1GB or 2GB VPS runs out of memory faster than you’d think — a Docker build, a Node install, or Postgres doing a vacuum can spike usage past what’s physically there. Without swap, the kernel’s OOM killer picks a process to kill, and it’s not always the one you’d choose. Swap gives you a buffer instead of a hard wall.

Why small VPS instances need it

Cloud providers don’t add swap by default. A bare 1GB droplet has exactly 1GB to work with, full stop. Run npm install on a memory-hungry project, or let Postgres’s shared_buffers and connection overhead creep up, and you’ll hit that ceiling during totally normal operation — not under attack, not under unusual load, just during a deploy.

Swap doesn’t make your server faster. It means that when memory runs out, the kernel pages the least-used memory to disk instead of killing a process outright. That’s the difference between a deploy that’s slow for ten seconds and a deploy that kills your database mid-write.

1. Check what you have

free -h
swapon --show

If swapon --show returns nothing, you have zero swap.

2. Create the swap file

Size it based on RAM — for a small VPS, matching RAM 1:1 is a reasonable default, more than that has diminishing returns:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

chmod 600 matters — a world-readable swap file can leak sensitive data that got paged out (env vars, keys held in memory).

3. Make it permanent

The above doesn’t survive a reboot on its own. Add it to fstab:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verify with sudo swapon --show after a reboot, not just right after you ran the commands — fstab typos won’t show up until then.

4. Tune swappiness

The default swappiness value on most distros is tuned for desktops, where the kernel swaps fairly aggressively to keep disk cache warm. On a server, especially one running a database, you generally want the kernel to prefer RAM and only swap as a last resort — not use swap as a routine cache-eviction target, which adds latency to every query that touches swapped memory.

Check the current value:

cat /proc/sys/vm/swappiness

Set it lower for a server workload:

sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

A value of 10 means the kernel avoids swapping until memory pressure is real, rather than swapping opportunistically at low pressure. Don’t set it to 0 — on modern kernels that can disable swap use even when you genuinely need it as an emergency buffer, which defeats the purpose.

What swap doesn’t fix

Swap is a shock absorber, not a capacity upgrade. If your app’s steady-state memory usage is already close to your RAM, swap just means you’re running slowly off disk all the time instead of crashing — and disk-backed memory is orders of magnitude slower than RAM, which shows up as mysteriously sluggish everything, hardest to diagnose because nothing is technically failing.

If you find your server leaning on swap under normal, non-spike conditions (check with free -h during regular operation, not just during a deploy), that’s a signal to upgrade the box, not add more swap. Swap earns its keep during brief spikes — a build, a burst of traffic, a backup job — not as a permanent substitute for RAM you actually need.

The gotcha

On a VPS with an SSD-backed disk from most providers, swap thrashing is a lot less punishing than it used to be on spinning disks, but it still costs real latency and, on some providers, counts against disk I/O limits. Set a swap file, tune swappiness down, and treat sustained swap usage as a signal to resize the box — not as normal operation.