Running Docker on a budget VPS

Why Docker on a small VPS at all

The case for Docker has nothing to do with machine size. Reproducible deploys mean the image you tested is byte-for-byte the image you run; rollbacks are just starting the previous tag; and the container that works on your laptop works identically in production.

On a small VPS those properties matter more, not less. When resources are tight you can't afford a mystery — 'it works on my machine' debugging burns exactly the time and memory you don't have. One image, everywhere, ends that class of problem.

Memory is the budget

On a budget VPS, RAM is the resource that runs out first, and Docker will cheerfully let one container starve the rest unless you say otherwise. Set an explicit memory limit on every container so a leak becomes one restarted service instead of a frozen server.

Add a modest swap file as a safety net — not to run from, but to survive brief spikes without the kernel killing processes at random. And prefer slim or alpine images: a smaller base means less memory, faster pulls and a smaller attack surface.

• Set --memory limits per container
• Use slim base images
• One process per container

Compose for the whole stack

One docker-compose.yml describing your app and its reverse proxy turns the whole stack into a single file you can read, version and reproduce. Bringing the server back from nothing becomes one command instead of a half-remembered ritual.

Keep the file boring and explicit: pinned image tags, restart policies, memory limits. Everything the server runs should be visible in that one file — if it isn't in Compose, it doesn't exist.

services:
  app:
    image: ghcr.io/you/app:latest
    restart: unless-stopped
    mem_limit: 512m

Keep the database out of the container

Running PostgreSQL or MySQL in Docker on a tiny box is where budget setups go to die. Databases want steady memory, careful storage and real backups — exactly the things a small VPS with containers competing for RAM can't promise. One OOM kill during a write and you're restoring from hope.

Use a managed database instead and let the VPS do what it's good at: running your stateless app. State belongs elsewhere — on Anested Cloud, managed PostgreSQL, MySQL and MongoDB start free, and your containers just get a connection string.

Updates without downtime drama

The update routine is short: pull the new image, restart the service, and let a health check confirm the new container actually answers before you walk away. If it doesn't, restarting the previous tag is your rollback — seconds, not an evening.

Before bigger changes — new major versions, Compose file rewrites — take a snapshot of the VPS first. It's the cheapest insurance you can buy: if the upgrade goes sideways, you restore the whole machine to the moment before you touched it.