VPS for Docker: how to size it and set it up

How much RAM a Docker VPS needs

Docker itself adds very little overhead; what counts is the sum of the containers you run. Databases, search engines and anything written in Java or Node with many workers use the most memory. Size the server by the stack, with some headroom for updates and spikes:

• 1–2 GB: one or two lightweight containers, such as a static site, a small API or a VPN
• 4 GB: a typical stack of a web app, a database and a reverse proxy, or tools like n8n or a WordPress container stack
• 8 GB or more: several apps with their own databases, an online shop, monitoring stacks or search engines

Choosing a VPS for Docker

Pick a KVM-based VPS: it runs its own kernel, so Docker works out of the box. Older container-based virtualisation (such as OpenVZ) can block Docker, so avoid plans that don’t say KVM or full virtualisation. Choose a current Ubuntu LTS or Debian image unless you have a reason not to.

Disk speed matters for databases, so NVMe is a plus, and RAM per dollar matters for bigger stacks. According to the providers’ pages, Hostinger uses NVMe and AMD EPYC on all VPS plans, Contabo offers very high RAM and storage for the price, and OVHcloud includes unlimited traffic and anti-DDoS. The table below compares current plans; our server finder suggests a spec for your project.

Install Docker Engine and Compose

Use Docker’s official repository rather than an old distribution package. The steps on Ubuntu or Debian are: update the system, add Docker’s GPG key and apt repository, then install docker-ce, docker-ce-cli, containerd.io and the docker-compose-plugin. Docker’s documentation has the exact commands for your distribution.

Then check it works with “docker run hello-world”, and define each app in a compose.yaml file so you can start the whole stack with “docker compose up -d”. Keeping the compose files in a git repository makes it easy to rebuild the server later.

A reverse proxy in front of your containers

Don’t publish every app on its own port. Run one reverse proxy that listens on ports 80 and 443, gets HTTPS certificates automatically and forwards each domain or subdomain to the right container over an internal Docker network.

Caddy is the simplest option: a few lines in a Caddyfile per site, with Let’s Encrypt certificates handled for you. Traefik reads labels from your containers and configures routes on its own, which is handy when you add and remove services often. Either way, only the proxy exposes ports to the internet; databases stay on the internal network.

Volumes, backups and security

Containers are disposable; your data is not. Store databases and uploads in named volumes or bind mounts, and back them up off the server on a schedule. For databases, dump them with their own tools (pg_dump, mysqldump) rather than copying live files. A provider snapshot before big upgrades is a useful extra, not a replacement.

• Never expose the Docker socket (/var/run/docker.sock) to the internet or to containers you don’t fully trust; access to it equals root on the host
• Don’t open the Docker API over TCP without TLS
• Remember that published ports can bypass ufw firewall rules; bind internal services to 127.0.0.1 or keep them unpublished
• Use SSH keys, disable password logins and keep the host and images updated