Docker on a VPS: A Practical Guide to Production

Docker changed the way people install software on a server: no more conflicting packages, no more "it works on my machine". On an NVMe VPS, a container isolates the application, gets replaced with one command, and describes itself in a file you can version. The catch is doing it properly and knowing where the data lives.

What Docker actually buys you on a VPS

A container is not a virtual machine. It shares the host kernel and ships only the application and its libraries. That means tens of megabytes where a VM would need a full operating system, a start in about a second, and enough headroom to run three services on a 1 vCPU plan.

Three situations justify the effort:

• Your dependencies pile up. A Node app, a PostgreSQL database and a reverse proxy have different needs and different upgrade rhythms. Isolating them keeps one version bump from breaking the other two.
• You want identical environments. The same image runs on your laptop and on the server, with the same library versions.
• You are preparing for the next step. When a second server shows up, the same definition runs again without a manual rebuild.

A static brochure site or a single PHP application is easier to run with nginx and PHP-FPM installed straight on the system. Docker adds a daemon, a network layer and gigabytes of images: worth it for several services, not as a résumé line.

Installing Docker without wrecking the system

Use the official repository, not the distro package

The package shipped with Ubuntu or Debian is often older than Compose v2. The official script curl -fsSL https://get.docker.com | sh sets up the repository, the engine and the Compose plugin in one pass. Read it before running it: you do this once, so know what it touches.

Three checks before you go further

Then confirm the service is running and that Compose is the plugin rather than the old Python binary:

• systemctl is-active docker should answer active.
• docker compose version should print a 2.x version.
• docker run --rm hello-world should finish without an error.

One detail: putting a user in the docker group hands them root, because they can mount any host directory into a container. On a server one person administers, use sudo docker.

A first stack: app, database, proxy and TLS

Three services, one internal network

The minimum viable stack fits in a single compose.yaml: a reverse proxy that terminates TLS, the application, and the database on a named volume. Only ports 80 and 443 are published; the database exposes nothing, and the containers reach each other by service name on a dedicated network. Day-to-day commands stay the same:

• docker compose up -d starts the stack in the background.
• docker compose ps shows the real state of each service and its ports.
• docker compose logs -f app follows the logs of the one service you care about.

Do not publish the database on 0.0.0.0: an SSH tunnel does the same job without exposing the service.

Certificates: domain first, TLS second

Let's Encrypt verifies that the domain points at your machine: create the A record toward the dedicated IPv4 included with every plan, then request the certificate. Two common approaches: certbot in webroot mode with a volume shared between the proxy and the renewal job, or a proxy that handles ACME itself, such as Caddy. Confirm the renewal is scheduled and tested: a certificate that expires after ninety days is still the most avoidable outage in this business.

Volumes and backups: what survives the container

Containers are disposable by design. A named volume is not: it holds your data and outlives an image rebuild. Code goes into the image; uploads and database files go into a declared volume.

But a volume is not a backup. The plans include automatic backups, which cover a server failure or a mistake at machine level. That does not replace an application-consistent export: a raw copy of the data directory taken mid-write can be unusable. For PostgreSQL, docker compose exec db pg_dump -U app app redirected to a host file gives you something readable.

Two habits: a daily cron export, and one copy kept off the server. A backup you never restored is a hypothesis.

Resource limits: the container that starves the server

By default a container takes all the memory it can find. On a 1 GB plan, one memory leak is enough to trigger the kernel's out-of-memory killer, and it does not always pick the victim you would have picked.

• Set ceilings. mem_limit and cpus in the compose file, or the deploy.resources.limits block in Compose v2. A memory ceiling keeps the failure local and predictable.
• Watch real usage. docker stats shows CPU, memory and I/O per container, live.
• Rotate the logs. The json-file driver grows without bound by default; a max-size and max-file policy keeps a chatty application from filling the NVMe disk in three weeks.
• Tell the app. A JVM or a Node process must be told about the ceiling, or it will size its heap against host memory and get killed before it ever slows down.

Keep an eye on disk space too: old images accumulate with every deploy. docker image prune clears orphaned images, but never run docker system prune --volumes without reading the list of what is about to disappear.

Security: five habits that matter

• Never mount /var/run/docker.sock into a container. Whoever controls the daemon controls the whole machine, disks included.
• Run the app unprivileged with the user directive, and mount the filesystem read-only where you can.
• Pin image versions instead of riding latest: you decide when the update happens, not the registry.
• Mind the firewall. Docker writes its own iptables rules, so a published port bypasses UFW. Use the DOCKER-USER chain to filter what actually gets in.
• Rebuild regularly. An image untouched for six months carries six months of missing patches.

The 24/7 supervision and the 99.9% SLA cover infrastructure: the machine, the network, the hypervisor. What runs inside your containers stays your responsibility. No serious host can guarantee someone else's code.

Which VPS plan fits a Docker stack?

The Docker daemon, the overlay2 storage layer and the images all consume memory and disk before the first request arrives. Here is where the five plans land, at public prices in US dollars per month and in dirhams before tax:

The 1 GB plan is honest for a proxy and a single service, provided you accept that the daemon and images already take a slice. At 2 GB, an app with its database has room; beyond that you buy headroom for peaks and image rebuilds. Every plan includes a dedicated IPv4, unlimited bandwidth, root access, automatic backups, a firewall and DDoS protection, and upgrading needs no painful migration.

FAQ

Do I have to use Docker to host an app on a VPS?

No. A single application with nginx and its runtime installed on the system is easier to diagnose. Docker pays off once you run several services or fight conflicting dependencies.

Does Docker run properly on a 1 GB VPS?

Yes, for a proxy and a light service: the daemon, images and OS already use part of that memory.

Do the automatic backups cover Docker volumes?

They protect the machine and its disk, not application-level consistency. Add a scheduled, tested logical dump of the database, kept off the server.

Do I need Kubernetes for a few containers?

No, and it is a poor trade on one server: the orchestrator costs resources and attention while giving you nothing until you have several machines. Compose is enough, and still readable six months later.

Next step

Start with a tiny stack, put it in production, then add services as the need proves itself. Open Vista VPS plans are delivered in under 15 minutes after ordering from the New York datacenter — a Rabat datacenter is announced but not open yet. Compare plans in the offers and pricing and read the NVMe VPS page before you start.