Docker VPS Hosting on KVM with NVMe

Docker containers share the kernel of the machine they run on. That is why the virtualization under your VPS matters more for Docker than for almost anything else.

On a container-based VPS (OpenVZ or LXC), your "server" is itself a container on the provider's kernel. Running Docker inside it means nesting containers, and whether that works depends on things the provider controls: the host kernel version, which kernel modules are loaded, how cgroups are delegated, whether nesting is enabled at all, and whether overlay filesystems and iptables rules are permitted. Some providers disable Docker on these plans entirely; others allow it with workarounds that break on the next host update.

Devoster VPS plans are KVM virtual machines. You boot your own Linux kernel, so Docker Engine installs from Docker's official repository the same way it would on a physical server: cgroups, namespaces, the overlay2 storage driver and Docker's iptables rules all work without asking anyone. Ubuntu 24.04 and Debian 12 are both available as images and both are supported by Docker Engine.

Docker's default storage driver on current Linux is overlay2. It stacks read-only image layers under a thin writable layer per container, and it needs the backing filesystem under /var/lib/docker to be ext4, or xfs formatted with ftype=1. Run docker info after installing and check that the storage driver line says overlay2.

NVMe helps Docker where it hurts most: extracting image layers on docker pull, the random small reads and writes of databases in volumes, and builds that touch thousands of small files. Disk space is a separate question, and it fills from places people don't watch:

• Old images and build cache. Every pull of a new tag keeps the old one until you prune. docker system df shows the split; docker image prune and docker builder prune reclaim it.
• Container logs. The default json-file log driver does not rotate. A chatty container can fill a disk on its own.
• Database volumes. These are the data you actually care about, and they grow steadily.

Set log rotation once, in /etc/docker/daemon.json, then restart Docker:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

The pattern that holds up on a public server: one reverse proxy publishes ports 80 and 443 and handles TLS, everything else stays on the internal Compose network, data lives in named volumes, and image tags are pinned. Here is the shape of it with Caddy, an app and Postgres:

name: myapp
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
  app:
    image: ghcr.io/you/myapp:1.4.2
    restart: unless-stopped
    env_file: .env
    expose: ["3000"]
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:17
    restart: unless-stopped
    env_file: .env
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      retries: 10
volumes:
  caddy_data:
  db_data:

The Caddyfile is two lines (app.example.com and reverse_proxy app:3000), and Caddy fetches and renews the certificate itself. Note that the app and database use expose, not ports: nothing but the proxy is reachable from outside. For a complete real-world version of this pattern, see how we deploy n8n with Postgres and Caddy in the n8n self-hosting tutorial.

The Docker daemon itself is light; what you size for is the sum of your containers at their busiest, plus the page cache your databases lean on. Databases and JVM or Node.js services set the floor far more than the number of containers does.

One habit that saves a plan size: build images in CI and pull them on the server. Compiling a frontend or installing dependencies inside docker build on a small VPS is often the single biggest memory and CPU spike the box ever sees. For running several separate sites on one Docker host, our guide to hosting multiple websites on one VPS covers isolation and routing.

Do the general hardening first, as in our VPS security hardening checklist: SSH keys only, a default-deny firewall, automatic security updates. Then the Docker-specific points, which catch people who did everything else right:

• Published ports bypass UFW. Docker writes its own iptables rules for ports:, so a port you publish is reachable from the internet even if UFW says deny. Publish only the proxy; use expose for the rest, or bind to 127.0.0.1:port when you need host access.
• The docker group is root. Anyone who can talk to the Docker socket can mount the host filesystem. Add only trusted users, and never mount /var/run/docker.sock into an internet-facing container unless you understand exactly what that container can then do.
• Pin image tags and update deliberately. latest plus an unattended pull is how a breaking change arrives at 3 a.m. Read release notes, then bump the tag.
• Keep secrets out of images. Pass them through an .env file with chmod 600 or Docker secrets, not baked into a Dockerfile.

Every Devoster VPS includes nightly backups of the whole server, with the last 3 days kept, plus one snapshot you can take yourself from the panel (panel snapshots expire after 7 days). Those cover "roll the whole machine back": a botched upgrade, a deleted volume, a broken OS update. Take a snapshot right before docker compose pull on anything important.

They are not a replacement for application-level backups. A whole-server backup taken while a database is writing is not the same as a clean dump, and 3 days of history won't help if you notice a problem in week two. Dump databases on a schedule (pg_dump, mysqldump), archive any volumes that hold files, and copy both off the server.

• You want autoscaling or high availability across machines. A single VPS is a single point of failure. If an outage of one server is unacceptable, you need several nodes and an orchestrator, or a managed container platform.
• You don't want to run a server. Devoster VPS plans are unmanaged. Docker upgrades, OS patches, TLS and backups are yours. If you just want to push code and have it run, a PaaS fits better.
• You need a GPU. These plans are CPU-only.
• Your data must stay in Europe or Israel. Devoster VPS servers are in Utah, USA.
• It is one WordPress site. Containerizing a single WordPress install adds work without much benefit; Devoster's web hosting is simpler for that.

Otherwise, compare all eight Devoster VPS plans; Starter is where most Compose stacks land.