How to Install Docker Engine on a Netcup VPS or Root Server (And Fix the UFW Firewall Bypass)

Every Netcup VPS and Root Server is provisioned as a full QEMU/KVM hardware virtual machine with its own isolated Linux 6.8+ kernel, dedicated cgroupv2 hierarchy, and native overlay2 union filesystem support. Unlike shared-kernel LXC or OpenVZ virtual servers—where nested mount namespaces, custom sysctl network tunables, or ip_tables kernel modules frequently fail—KVM virtualization guarantees that dockerd and containerd operate identically to bare-metal hardware.

Before adding Docker’s upstream repository, purge any conflicting distribution-packaged container runtimes (docker.io, podman-docker, containerd, or the legacy Python v1 docker-compose script) and verify that the Ubuntu docker Snap package is not installed. Snap-packaged Docker runs inside a confined AppArmor mount namespace that breaks bind-mounts outside /home or /opt and triggers unscheduled daemon restarts whenever snapd refreshes.

Next, register Docker’s official GPG key inside /etc/apt/keyrings/docker.asc with world-readable 0644 permissions (chmod a+r) and configure the signed APT source list. Sourcing /etc/os-release variables ($ID and $VERSION_CODENAME) directly in the shell command ensures the exact repository stanza is generated cleanly whether your Netcup KVM node runs Ubuntu 24.04 LTS (noble) or Debian 12 (bookworm).

Finally, install docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin (which replaces the deprecated legacy builder with concurrent BuildKit caching), and docker-compose-plugin (which provides the native Go docker compose v2 subcommand). On multi-container hosts like a 4 GB VPS 500 G12.5 or 8 GB RS 1000 G12.5, this modern stack also lets you enforce per-container memory (mem_limit) and CPU (cpus) ceilings via cgroupv2.

# 1. Remove any conflicting distro packages
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y $pkg 2>/dev/null || true
done

# 2. Install prerequisites and register Docker's official GPG key
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
. /etc/os-release
sudo curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3. Add the official Docker APT repository
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. Install Docker Engine, CLI, containerd, Buildx, and Compose v2
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker --version && docker compose version

Docker version 27.3.1, build ce12230
Docker Compose version v2.29.7

By default, Docker’s json-file logging driver retains every line written to stdout and stderr indefinitely. On a busy production Nginx, Traefik, or Node.js container running on a Netcup VPS or Root Server, unrotated container logs stored under /var/lib/docker/containers/<container-id>/ can quietly accumulate 40+ GB of JSON text over a few months and crash PostgreSQL or MariaDB with ENOSPC (No space left on device). Setting "max-size": "10m" and "max-file": "3" with "compress": "true" caps each container’s log footprint at 30 MB.

Enabling "live-restore": true decouples running container processes (containerd-shim) from the management daemon (dockerd). When apt unattended-upgrades patches docker-ce overnight and restarts docker.service, your database, cache, and web containers remain up and serving traffic without dropping active TCP connections.

Setting "userland-proxy": false disables the legacy docker-proxy userland executable that Docker otherwise spawns for every single published port. Relying purely on Linux kernel netfilter hairpin NAT eliminates redundant user-space packet copying and saves 30–80 MB of RAM across multi-container Compose stacks.

Lastly, defining "default-address-pools" (172.20.0.0/14 carved into /24 subnets) prevents Docker from allocating massive /16 blocks (172.17.0.0/16 through 172.31.0.0/16) every time you run docker compose up, avoiding routing table collisions with corporate WireGuard, Tailscale, or OpenVPN tunnels.

cat << 'EOF' | sudo tee /etc/docker/daemon.json
{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  },
  "live-restore": true,
  "userland-proxy": false,
  "default-address-pools": [
    {
      "base": "172.20.0.0/14",
      "size": 24
    }
  ]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo docker info | grep -E "Storage Driver|Logging Driver|Live Restore"

 Storage Driver: overlay2
 Logging Driver: json-file
 Live Restore Enabled: true

This is the most common security vulnerability on self-hosted Linux servers: when you enable ufw (ufw default deny incoming) and then start a container with ports: - "5432:5432" or - "8080:8080", Docker modifies the kernel PREROUTING nat table and routes traffic through the FORWARD filter chain before UFW’s ufw-before-input (INPUT chain) is ever evaluated. As a result, port 5432 or 8080 becomes reachable from the entire public internet despite sudo ufw status reporting only ports 22, 80, and 443 as open!

Why does the Linux kernel process packets this way? When an external packet arrives on eth0 destined for a published container port, the nat PREROUTING chain rewrites the destination IP from your Netcup public IPv4 address to the container’s internal bridge IP (172.20.0.x). Because the destination IP is no longer the host itself, the kernel routes the packet down the FORWARD chain (DOCKER-USER → DOCKER) instead of the INPUT chain where UFW places its host rules.

To eliminate accidental database or admin-port exposure on Netcup, enforce a three-layer network defense: bind internal container ports explicitly to loopback (127.0.0.1:5432:5432) in compose.yaml, activate the Netcup SCP Hypervisor Stateful Firewall outside the VM (which filters packets on the host virtual switch before the guest kernel’s PREROUTING table even sees them), and lock down the DOCKER-USER chain.

Whenever you deploy a new Compose stack, always run sudo ss -tulnp on the host OS to audit active listening sockets. Only sshd (port 22) and your reverse proxy (nginx or caddy on ports 80 and 443) should ever bind to 0.0.0.0 or [::]; every application worker, Redis instance, and SQL database should either remain unexposed inside an internal Docker bridge network or bind strictly to 127.0.0.1.

• ▪ Layer 1 — Explicit Loopback Binding in compose.yaml: Always write 127.0.0.1:8080:8080 instead of 8080:8080 for backend services accessed through a host Nginx/Caddy reverse proxy.
• ▪ Layer 2 — Netcup SCP Hypervisor Stateful Firewall: In the Netcup Server Control Panel (servercontrolpanel.de → Network → Firewall), allow inbound TCP 22, 80, 443 and UDP 443, and set the default ingress policy to DROP. Because the SCP Firewall operates outside the VM on the host virtual switch, Docker’s guest iptables rules cannot bypass it!
• ▪ Layer 3 — DOCKER-USER Chain Lock in /etc/ufw/after.rules: Add explicit drop rules to the DOCKER-USER netfilter chain for traffic arriving on your public interface (eth0/ens3) targeting private RFC1918 container subnets.

# Always bind internal app ports strictly to 127.0.0.1:
docker run -d --name test-redis --restart unless-stopped -p 127.0.0.1:6379:6379 redis:7-alpine

# Audit all listening TCP/UDP sockets on your Netcup server:
# Ensure only sshd (22) and your reverse proxy (80/443) listen on 0.0.0.0 or [::]
sudo ss -tulnp

tcp   LISTEN 0      4096       127.0.0.1:6379      0.0.0.0:*    users:(("dockerd",pid=1120,fd=14))