Tools

Tools: Docker Security Best Practices for Self-Hosters in 2026

2026-04-18 0 views admin
Tools: Docker Security Best Practices for Self-Hosters in 2026

Prerequisites

1. Never Run Containers as Root

2. Use Read-Only Filesystems

4. Manage Secrets Properly

5. Scan Your Images

6. Isolate Your Docker Networks

7. Keep Docker and Images Updated

8. Limit Container Capabilities

9. Configure Logging and Monitoring

10. The Compose Security Checklist

Troubleshooting

Conclusion Docker makes self-hosting feel effortless. Pull an image, write a compose file, run docker compose up -d, and you have a production service in minutes. That's exactly how I built the entire ByteGuard stack — Ghost, Nginx Proxy Manager, and Uptime Kuma on a single Hetzner VPS. But here's what most "how to self-host X" guides never tell you: the defaults are not secure. Docker out of the box runs containers as root, puts every container on the same network, exposes ports to the entire internet, and gives containers more Linux capabilities than they need. If you hardened your VPS at the OS level but left Docker wide open, you locked the front door and left the windows up. This post covers 10 Docker security practices I use on the same Hetzner box that runs this blog. Every snippet is real, every recommendation is tested. Before you start, you should have: This is the single highest-impact change you can make. By default, the process inside a Docker container runs as root — UID 0. If an attacker exploits a vulnerability in your application and escapes the container, they land on the host as root. Game over. The fix is straightforward. In your docker-compose.yml, set the user field: This tells Docker to run the Ghost process as UID 1000 instead of root. The container still starts, Ghost still works — but a compromised process now has unprivileged access. A few things to watch for: A container with a writable filesystem lets an attacker drop binaries, modify config files, install tools, and persist across restarts. Remove that option entirely: With read_only: true, the container's root filesystem is mounted read-only. The container can only write to explicitly mounted volumes and tmpfs mounts. If an attacker gets code execution, they can't modify the application, can't install packages, can't drop a reverse shell binary into /usr/local/bin. The tmpfs mount for /tmp gives the application a writable scratch space in memory — many apps need this for temporary files, PID files, or socket files. It disappears on container restart, so nothing persists. Most self-hosted applications work fine with read-only filesystems once you identify which directories actually need writes. Ghost needs /var/lib/ghost/content. Uptime Kuma needs /app/data. NPM needs its data and letsencrypt directories. Everything else can be locked down. Without resource limits, a single misbehaving container can consume all available RAM and CPU, taking down every other service on your VPS. This isn't theoretical — a memory leak, a log file growing without bounds, or a fork bomb in a compromised container will OOM-kill your entire host. Here's what each limit does: For reference, here's what the ByteGuard stack actually uses on our Hetzner CPX22 (8 GB RAM): Note: Set limits based on observation, not guesswork. Run docker stats for a few days to see what your containers actually consume, then set the limit at roughly 1.5x the peak. Secrets in Docker stacks are one of those things everyone knows they should handle correctly and almost nobody does. Here's the hierarchy from worst to best: Worst — hardcoded in docker-compose.yml: This password is in your compose file, probably in a git repo, possibly public. The .env file keeps secrets out of the compose file. But it's still plaintext on disk. Lock it down: Add .env to your .gitignore and .dockerignore so it never ends up in a repo or inside an image. Note: Environment variables set this way are visible via docker inspect. Anyone with access to the Docker socket can read every environment variable in every running container. Best for single-host self-hosting: The .env approach with proper file permissions is honestly fine for most self-hosters. Docker Secrets (the swarm-mode feature) adds encryption and mounts secrets as files inside containers, but it requires swarm mode — overhead most single-server setups don't need. A locked-down .env file is the pragmatic choice. Every time you pull a Docker image, you're running code that someone else built. You trust that ghost:5 is safe because it's an official image — but official images contain operating system packages, and those packages have CVEs. Docker Scout (built into Docker CLI): This scans the image and lists known CVEs by severity. Trivy (open source, more thorough): Pin your image versions. This is as much a security practice as a reliability one: Pinned versions mean you choose when to update. latest means Docker pulls whatever the maintainer pushed most recently — and if that image has a supply-chain compromise, you've auto-deployed it. Docker's default bridge network puts every container on the same subnet. Any container can reach any other container by IP. If an attacker compromises one service, they pivot to everything else without touching the external network. Create purpose-specific networks and only connect containers that need to talk to each other: Only the reverse proxy exposes ports. Ghost doesn't need port 2368 open to the internet — NPM proxies traffic to it internally. Bind to localhost when you need host access: Warning: Docker manipulates iptables directly, which means UFW and firewalld rules don't apply to Docker-published ports. You can have a perfectly configured firewall and Docker will punch right through it. Binding to localhost is the reliable fix. internal: true creates a network with no outbound internet access. Use this for backend services that have no reason to make outbound connections. Docker itself — the engine, containerd, runc — has had serious CVEs. CVE-2024-21626 (runc container escape) and CVE-2024-23651 (BuildKit race condition) are recent examples where an unpatched Docker installation was directly exploitable. Update the Docker engine: Update your images manually: Watchtower automates image updates: The convenience is real, but so is the risk: Watchtower will auto-deploy a broken update at 4 AM while you're asleep. For a personal blog, that's probably fine. For anything you can't afford downtime on, update manually. At minimum, pin major versions (ghost:5 not ghost:latest) so you get patch updates but not breaking major bumps. Linux capabilities split root's power into pieces like NET_BIND_SERVICE (bind to ports below 1024), SYS_ADMIN (mount filesystems), and NET_RAW (use raw sockets). Docker grants about 14 capabilities by default. Most containers don't need most of them. Drop everything and add back only what's required: Warning: Never mount the Docker socket (/var/run/docker.sock) into a container unless you absolutely must. Access to the Docker socket is equivalent to root access on the host. If you must mount it (Watchtower requires it), treat that container as part of your trusted computing base. If a container gets compromised and you have no logs, you'll never know. Docker's default logging driver (json-file) writes to JSON files on the host — until those files grow unbounded and fill your disk. Configure log rotation: This caps each container's log at 30 MB total. You can also set this globally in /etc/docker/daemon.json: Add health checks so you monitor application health, not just port availability: This pings Ghost's API every 30 seconds. If it fails three times, Docker marks the container as unhealthy. Uptime Kuma can then alert you based on health status rather than just TCP connectivity. Watch container events for anything unexpected: On a self-hosted VPS where you're the only operator, any container event you didn't initiate is worth investigating. Here's everything above condensed into a checklist for every new service you deploy: A fully hardened compose service looks like this: Compare that to the typical self-hosting tutorial compose file — image, ports, volumes, done. The difference is about 15 lines of YAML and a dramatically smaller attack surface. Container won't start after adding user: "1000:1000" Container crashes with read_only: true cap_drop: ALL breaks the application Docker bypasses UFW — port is open despite firewall rules Health check keeps failing Docker security isn't a separate project — it's a layer in the same stack you're already building. If you hardened your Linux VPS with SSH keys, firewalls, and automatic updates, these ten practices are the natural next step: lock down the containers that actually run your services. Start with the three highest-impact changes: The stack powering this blog — the same one from Post #1 — runs with these practices in place. It's not paranoia. It's the difference between self-hosting and self-pwning. If you're setting up a new Docker stack and need a VPS, I run all my projects on Hetzner — here's how the three major providers compare. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

services: ghost: image: ghost:5 user: "1000:1000" volumes: - ghost_data:/var/lib/ghost/content services: ghost: image: ghost:5 user: "1000:1000" volumes: - ghost_data:/var/lib/ghost/content services: ghost: image: ghost:5 user: "1000:1000" volumes: - ghost_data:/var/lib/ghost/content services: uptime-kuma: image: louislam/uptime-kuma:1 read_only: true tmpfs: - /tmp volumes: - kuma_data:/app/data services: uptime-kuma: image: louislam/uptime-kuma:1 read_only: true tmpfs: - /tmp volumes: - kuma_data:/app/data services: uptime-kuma: image: louislam/uptime-kuma:1 read_only: true tmpfs: - /tmp volumes: - kuma_data:/app/data services: ghost: image: ghost:5 deploy: resources: limits: memory: 512M cpus: "1.0" pids_limit: 100 services: ghost: image: ghost:5 deploy: resources: limits: memory: 512M cpus: "1.0" pids_limit: 100 services: ghost: image: ghost:5 deploy: resources: limits: memory: 512M cpus: "1.0" pids_limit: 100 # DON'T DO THIS environment: - database__connection__password=mysecretpassword123 # DON'T DO THIS environment: - database__connection__password=mysecretpassword123 # DON'T DO THIS environment: - database__connection__password=mysecretpassword123 # docker-compose.yml environment: - database__connection__password=${GHOST_DB_PASSWORD} # docker-compose.yml environment: - database__connection__password=${GHOST_DB_PASSWORD} # docker-compose.yml environment: - database__connection__password=${GHOST_DB_PASSWORD} # .env GHOST_DB_PASSWORD=a-real-strong-password-here # .env GHOST_DB_PASSWORD=a-real-strong-password-here # .env GHOST_DB_PASSWORD=a-real-strong-password-here chmod 600 .env chown root:root .env chmod 600 .env chown root:root .env chmod 600 .env chown root:root .env docker scout cves ghost:5 docker scout cves ghost:5 docker scout cves ghost:5 # Install curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # Scan trivy image ghost:5 # Install curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # Scan trivy image ghost:5 # Install curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # Scan trivy image ghost:5 # Don't do this — you get whatever "latest" means today image: ghost:latest # Do this — you know exactly what you're running image: ghost:5.118.0 # Don't do this — you get whatever "latest" means today image: ghost:latest # Do this — you know exactly what you're running image: ghost:5.118.0 # Don't do this — you get whatever "latest" means today image: ghost:latest # Do this — you know exactly what you're running image: ghost:5.118.0 services: ghost: image: ghost:5 networks: - frontend nginx-proxy-manager: image: jc21/nginx-proxy-manager:latest networks: - frontend ports: - "80:80" - "443:443" uptime-kuma: image: louislam/uptime-kuma:1 networks: - monitoring networks: frontend: driver: bridge monitoring: driver: bridge internal: true services: ghost: image: ghost:5 networks: - frontend nginx-proxy-manager: image: jc21/nginx-proxy-manager:latest networks: - frontend ports: - "80:80" - "443:443" uptime-kuma: image: louislam/uptime-kuma:1 networks: - monitoring networks: frontend: driver: bridge monitoring: driver: bridge internal: true services: ghost: image: ghost:5 networks: - frontend nginx-proxy-manager: image: jc21/nginx-proxy-manager:latest networks: - frontend ports: - "80:80" - "443:443" uptime-kuma: image: louislam/uptime-kuma:1 networks: - monitoring networks: frontend: driver: bridge monitoring: driver: bridge internal: true ports: - "127.0.0.1:3001:3001" # Only accessible from the host ports: - "127.0.0.1:3001:3001" # Only accessible from the host ports: - "127.0.0.1:3001:3001" # Only accessible from the host sudo apt update && sudo apt upgrade docker-ce docker-ce-cli containerd.io sudo apt update && sudo apt upgrade docker-ce docker-ce-cli containerd.io sudo apt update && sudo apt upgrade docker-ce docker-ce-cli containerd.io # Pull new versions docker compose pull # Recreate containers with new images docker compose up -d # Clean up old images docker image prune -f # Pull new versions docker compose pull # Recreate containers with new images docker compose up -d # Clean up old images docker image prune -f # Pull new versions docker compose pull # Recreate containers with new images docker compose up -d # Clean up old images docker image prune -f services: watchtower: image: containrrr/watchtower volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - WATCHTOWER_CLEANUP=true - WATCHTOWER_SCHEDULE=0 0 4 * * * services: watchtower: image: containrrr/watchtower volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - WATCHTOWER_CLEANUP=true - WATCHTOWER_SCHEDULE=0 0 4 * * * services: watchtower: image: containrrr/watchtower volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - WATCHTOWER_CLEANUP=true - WATCHTOWER_SCHEDULE=0 0 4 * * * services: ghost: image: ghost:5 cap_drop: - ALL cap_add: - CHOWN - SETUID - SETGID security_opt: - no-new-privileges:true services: ghost: image: ghost:5 cap_drop: - ALL cap_add: - CHOWN - SETUID - SETGID security_opt: - no-new-privileges:true services: ghost: image: ghost:5 cap_drop: - ALL cap_add: - CHOWN - SETUID - SETGID security_opt: - no-new-privileges:true services: ghost: image: ghost:5 logging: driver: json-file options: max-size: "10m" max-file: "3" services: ghost: image: ghost:5 logging: driver: json-file options: max-size: "10m" max-file: "3" services: ghost: image: ghost:5 logging: driver: json-file options: max-size: "10m" max-file: "3" { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } services: ghost: image: ghost:5 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:2368/ghost/api/admin/site/"] interval: 30s timeout: 10s retries: 3 start_period: 30s services: ghost: image: ghost:5 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:2368/ghost/api/admin/site/"] interval: 30s timeout: 10s retries: 3 start_period: 30s services: ghost: image: ghost:5 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:2368/ghost/api/admin/site/"] interval: 30s timeout: 10s retries: 3 start_period: 30s docker events --filter type=container docker events --filter type=container docker events --filter type=container □ Container runs as non-root (user: field or USER in Dockerfile) □ Filesystem is read-only (read_only: true + explicit volume mounts) □ Memory and CPU limits set (deploy.resources.limits) □ PID limit set (pids_limit) □ Capabilities dropped and selectively added (cap_drop: ALL) □ no-new-privileges enabled (security_opt) □ Secrets in .env with 600 permissions, not in compose file □ Image version pinned (tag, not :latest) □ Image scanned for CVEs (docker scout or trivy) □ Container on a purpose-specific network, not default bridge □ Only necessary ports exposed, bound to 127.0.0.1 if host-only □ Log rotation configured (max-size + max-file) □ Health check defined □ Docker socket NOT mounted (unless required and justified) □ Container runs as non-root (user: field or USER in Dockerfile) □ Filesystem is read-only (read_only: true + explicit volume mounts) □ Memory and CPU limits set (deploy.resources.limits) □ PID limit set (pids_limit) □ Capabilities dropped and selectively added (cap_drop: ALL) □ no-new-privileges enabled (security_opt) □ Secrets in .env with 600 permissions, not in compose file □ Image version pinned (tag, not :latest) □ Image scanned for CVEs (docker scout or trivy) □ Container on a purpose-specific network, not default bridge □ Only necessary ports exposed, bound to 127.0.0.1 if host-only □ Log rotation configured (max-size + max-file) □ Health check defined □ Docker socket NOT mounted (unless required and justified) □ Container runs as non-root (user: field or USER in Dockerfile) □ Filesystem is read-only (read_only: true + explicit volume mounts) □ Memory and CPU limits set (deploy.resources.limits) □ PID limit set (pids_limit) □ Capabilities dropped and selectively added (cap_drop: ALL) □ no-new-privileges enabled (security_opt) □ Secrets in .env with 600 permissions, not in compose file □ Image version pinned (tag, not :latest) □ Image scanned for CVEs (docker scout or trivy) □ Container on a purpose-specific network, not default bridge □ Only necessary ports exposed, bound to 127.0.0.1 if host-only □ Log rotation configured (max-size + max-file) □ Health check defined □ Docker socket NOT mounted (unless required and justified) services: myapp: image: myapp:1.2.3 user: "1000:1000" read_only: true tmpfs: - /tmp volumes: - app_data:/data environment: - SECRET_KEY=${APP_SECRET_KEY} networks: - backend deploy: resources: limits: memory: 256M cpus: "0.5" pids_limit: 50 cap_drop: - ALL security_opt: - no-new-privileges:true logging: driver: json-file options: max-size: "10m" max-file: "3" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s timeout: 10s retries: 3 start_period: 15s networks: backend: driver: bridge internal: true services: myapp: image: myapp:1.2.3 user: "1000:1000" read_only: true tmpfs: - /tmp volumes: - app_data:/data environment: - SECRET_KEY=${APP_SECRET_KEY} networks: - backend deploy: resources: limits: memory: 256M cpus: "0.5" pids_limit: 50 cap_drop: - ALL security_opt: - no-new-privileges:true logging: driver: json-file options: max-size: "10m" max-file: "3" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s timeout: 10s retries: 3 start_period: 15s networks: backend: driver: bridge internal: true services: myapp: image: myapp:1.2.3 user: "1000:1000" read_only: true tmpfs: - /tmp volumes: - app_data:/data environment: - SECRET_KEY=${APP_SECRET_KEY} networks: - backend deploy: resources: limits: memory: 256M cpus: "0.5" pids_limit: 50 cap_drop: - ALL security_opt: - no-new-privileges:true logging: driver: json-file options: max-size: "10m" max-file: "3" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s timeout: 10s retries: 3 start_period: 15s networks: backend: driver: bridge internal: true - A Linux VPS with Docker and Docker Compose v2 installed (here's how I set mine up) - Basic familiarity with docker-compose.yml syntax - SSH access to your server (hardened, ideally) - A running Docker stack you want to secure (even a single container counts) - File permissions on volumes. If your volume data was created by root, a non-root container can't write to it. Fix this with chown 1000:1000 on the host directory before switching. - Some images expect root. Official Nginx, for example, needs root to bind to port 80. Inside a compose stack where a reverse proxy handles external traffic, your backend containers don't need to bind privileged ports at all. - Rootless Docker mode goes further — the Docker daemon itself runs without root. This is a bigger architectural change and adds complexity around networking and storage drivers. For most self-hosters, running containers as non-root (the user: field) gives you 90% of the security benefit with 10% of the friction. - memory: 512M — the container gets killed if it tries to use more than 512 MB of RAM. Docker sends a SIGKILL, not a gentle shutdown. - cpus: "1.0" — the container can use at most one CPU core. Prevents a single container from starving everything else. - pids_limit: 100 — caps the number of processes inside the container. This is your fork bomb insurance. - cap_drop: ALL removes every capability. - cap_add gives back only what the application needs. You find out which ones by dropping all and reading the error messages. - no-new-privileges: true prevents any process inside the container from gaining additional privileges through setuid binaries. One of the highest-value single lines you can add. - Cause: The volume data is owned by root and the non-root user can't write to it. - Fix: Run sudo chown -R 1000:1000 /path/to/volume on the host before restarting. - Cause: The application tries to write to a directory that isn't mounted as a volume or tmpfs. - Fix: Check the container logs (docker logs <container>) for "read-only file system" errors. Add the needed path as a tmpfs mount or a named volume. - Cause: The app needs specific Linux capabilities you haven't added back. - Fix: Start with cap_drop: ALL, then add capabilities one at a time based on the error messages. Common ones: CHOWN, SETUID, SETGID, NET_BIND_SERVICE. - Cause: Docker manipulates iptables directly, bypassing UFW/firewalld. - Fix: Bind ports to localhost (127.0.0.1:3001:3001 instead of 3001:3001), or configure Docker to respect iptables by setting "iptables": false in /etc/docker/daemon.json (but this breaks Docker networking unless you add manual rules). - Cause: The health check command runs inside the container, which may not have curl installed. - Fix: Use wget -q --spider instead of curl, or for minimal images use a language-native health endpoint check. - Run containers as non-root — eliminates the most dangerous default. - Isolate your networks — stops lateral movement between services. - Scan your images — catches known vulnerabilities before they're running in production.

🏷️ Tags

toolsutilitiessecurity toolsdockersecuritypracticeshostersprerequisites

More from Tools

Tools: Complete Guide to Anthropic Cybersecurity Skills: 754 playbooks de seguridad para agentes IA

Tools: Complete Guide to Anthropic Cybersecurity Skills: 754 playbooks de seguridad para agentes IA

2026-04-20 0
Tools: Docker for Beginners: Containerize Your App in 30 Minutes

Tools: Docker for Beginners: Containerize Your App in 30 Minutes

2026-04-20 0
Tools: Complete Guide to Docker Compose Explained: Multi-Container Stacks (2026)

Tools: Complete Guide to Docker Compose Explained: Multi-Container Stacks (2026)

2026-04-20 0
Tools: Essential Guide: Cheapest VPS $5/Month: What You Really Get

Tools: Essential Guide: Cheapest VPS $5/Month: What You Really Get

2026-04-20 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views