Forem: byte-guard

Docker Security Best Practices for Self-Hosters in 2026

byte-guard — Sat, 18 Apr 2026 11:29:06 +0000

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.

Prerequisites

Before you start, you should have:

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)

1. Never Run Containers as Root

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:

services:
  ghost:
    image: ghost:5
    user: "1000:1000"
    volumes:
      - ghost_data:/var/lib/ghost/content

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:

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.

2. Use Read-Only Filesystems

A container with a writable filesystem lets an attacker drop binaries, modify config files, install tools, and persist across restarts. Remove that option entirely:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - kuma_data:/app/data

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.

3. Set Resource Limits

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.

services:
  ghost:
    image: ghost:5
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    pids_limit: 100

Here's what each limit does:

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.

For reference, here's what the ByteGuard stack actually uses on our Hetzner CPX22 (8 GB RAM):

Service	Typical RAM	Suggested Limit
Ghost	~350 MB	512M
Nginx Proxy Manager	~120 MB	256M
Uptime Kuma	~80 MB	256M

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.

4. Manage Secrets Properly

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:

# DON'T DO THIS
environment:
  - database__connection__password=mysecretpassword123

This password is in your compose file, probably in a git repo, possibly public.

Better — .env file:

# docker-compose.yml
environment:
  - database__connection__password=${GHOST_DB_PASSWORD}

# .env
GHOST_DB_PASSWORD=a-real-strong-password-here

The .env file keeps secrets out of the compose file. But it's still plaintext on disk. Lock it down:

chmod 600 .env
chown root:root .env

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.

5. Scan Your Images

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):

docker scout cves ghost:5

This scans the image and lists known CVEs by severity.

Trivy (open source, more thorough):

# Install
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Scan
trivy image ghost:5

Pin your image versions. This is as much a security practice as a reliability one:

# 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

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.

6. Isolate Your Docker Networks

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:

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

Key patterns:

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:

ports:
  - "127.0.0.1:3001:3001"  # Only accessible from the host

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.

7. Keep Docker and Images Updated

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:

sudo apt update && sudo apt upgrade docker-ce docker-ce-cli containerd.io

Update your images manually:

# Pull new versions
docker compose pull

# Recreate containers with new images
docker compose up -d

# Clean up old images
docker image prune -f

Watchtower automates image updates:

services:
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 4 * * *

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.

8. Limit Container Capabilities

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:

services:
  ghost:
    image: ghost:5
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETUID
      - SETGID
    security_opt:
      - no-new-privileges:true

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.

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.

9. Configure Logging and Monitoring

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:

services:
  ghost:
    image: ghost:5
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

This caps each container's log at 30 MB total. You can also set this globally in /etc/docker/daemon.json:

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

Add health checks so you monitor application health, not just port availability:

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

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:

docker events --filter type=container

On a self-hosted VPS where you're the only operator, any container event you didn't initiate is worth investigating.

10. The Compose Security Checklist

Here's everything above condensed into a checklist for every new service you deploy:

□ 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)

A fully hardened compose service looks like this:

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

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.

Troubleshooting

Container won't start after adding user: "1000:1000"

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.

Container crashes with read_only: true

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.

cap_drop: ALL breaks the application

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.

Docker bypasses UFW — port is open despite firewall rules

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).

Health check keeps failing

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.

Conclusion

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:

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.

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.

How to Harden Your Linux VPS in 10 Minutes

byte-guard — Sun, 12 Apr 2026 12:55:49 +0000

The moment you spin up a fresh Linux VPS, the clock starts ticking. Within hours — sometimes minutes — your IP shows up in scanner logs and bots begin trying default credentials, common SSH usernames, and known web exploits. I've watched a brand-new server log over four thousand brute-force SSH attempts in its first 24 hours of life.

Most of those attacks are stoppable in 10 minutes of work. Here's the no-fluff checklist I run on every new VPS — the same one I used when I built byte-guard.net itself.

What You'll Need

A fresh VPS running Ubuntu 22.04+ or Debian 11+ (most steps work on any modern distro)
Root SSH access — ideally a just-provisioned server, before you've done anything else
10 minutes
An SSH key on your local machine (we'll generate one if you don't have it)

Note: these commands assume apt-based distros. If you're on Rocky, Alma, or RHEL, swap apt for dnf and ufw for firewalld — the principles are identical.

Step 1 — Update Everything

Bots love unpatched systems. The first thing to do on any new server is apply outstanding updates:

apt update && apt upgrade -y

This pulls down the package index and installs every available update. On a fresh VPS this typically takes 1-2 minutes.

Step 2 — Create a Non-Root User

You should never SSH in as root for daily work. If your root account gets compromised, you've handed an attacker complete control. A regular user with sudo access gives you the same power but keeps an audit trail and adds a small barrier between mistakes and disaster.

adduser amine
usermod -aG sudo amine

Replace amine with your username. adduser will prompt you for a password — make it strong (a passphrase from pwgen -s 32 1 is excellent), but you'll mostly be using SSH keys after the next step.

Step 3 — Set Up SSH Key Authentication

Passwords get brute-forced. Ed25519 SSH keys don't, in any practical sense. If you don't have one yet, generate it on your local machine, not the server:

ssh-keygen -t ed25519 -C "your_email@example.com"

Why ed25519 over rsa? It's faster, smaller, and more modern. The default rsa 3072-bit key is also fine, but ed25519 is the current best practice.

Then copy it to the server, replacing the placeholder with your user and IP:

ssh-copy-id amine@your-server-ip

Now test it from a new terminal:

ssh amine@your-server-ip

You should log in without being asked for a password. If that works, you're ready to lock down SSH itself.

Step 4 — Lock Down SSH

This is the single biggest security win. Open the SSH server config:

sudo vim /etc/ssh/sshd_config

Find and change these lines (uncomment them if needed):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

What each does:

PermitRootLogin no — root cannot SSH in at all
PasswordAuthentication no — only SSH keys work, no passwords
PubkeyAuthentication yes — explicitly enable SSH keys (usually default but be explicit)
ChallengeResponseAuthentication no and UsePAM no — close fallback authentication paths

Don't close your current session yet. Test that you can log in via key from a new terminal first. If you've made a config mistake, you'll need that working session to fix it.

Save and reload SSH:

sudo systemctl reload sshd

Open a brand new terminal and SSH in as your user. If it works, your server is now key-only. Now you can safely close the old root session.

Step 5 — Set Up UFW (the Firewall)

ufw is Ubuntu's user-friendly firewall. It ships with most modern distros and just needs to be enabled with a sensible default policy:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Verify the rules:

sudo ufw status verbose

You should see only port 22 (SSH) open. If you're running a web server, also allow:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Don't allow ports you're not actually using. Every open port is a potential attack surface.

Step 6 — Install fail2ban

Even with key-only SSH, your logs will fill up with rejected brute-force attempts. fail2ban watches the auth log and bans IPs that repeatedly fail to authenticate:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Out of the box, the default config protects SSH. Check that the SSH jail is active:

sudo fail2ban-client status sshd

You should see something like:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

To tighten the defaults (out of the box: 5 attempts, 10-minute ban), create a local override:

sudo vim /etc/fail2ban/jail.local

Add:

[sshd]
enabled = true
maxretry = 3
findtime = 10m
bantime = 1h

Then reload:

sudo systemctl restart fail2ban

Three failed attempts in 10 minutes now earns a one-hour ban. Aggressive enough to deter bots, lenient enough that you can recover from your own typos.

Step 7 — Enable Unattended Upgrades

Security patches matter most when they actually get installed. Unattended upgrades automatically apply security updates so you don't have to remember to log in and apt upgrade:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Choose Yes when prompted. This installs a systemd timer that runs daily and applies security updates only — not feature upgrades, so you won't get surprise breaking changes.

Verify it's running:

sudo systemctl status unattended-upgrades

You should see active (running).

Step 8 — Sanity Check

Run these to verify everything is in place:

# SSH config — both should say "no"
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

# Firewall — should show only the ports you opened
sudo ufw status

# fail2ban — should show the sshd jail as active
sudo fail2ban-client status sshd

# Unattended upgrades — should be active
sudo systemctl is-active unattended-upgrades

If everything checks out, your VPS is hardened against the most common automated attacks.

Bonus — Change the SSH Port (Optional)

Moving SSH off port 22 doesn't add real security (it's security through obscurity), but it does massively cut log noise from drive-by scanners. Edit /etc/ssh/sshd_config:

Port 2222

Then update UFW:

sudo ufw delete allow OpenSSH
sudo ufw allow 2222/tcp
sudo systemctl reload sshd

Connect with ssh -p 2222 amine@your-server-ip. Add it to your ~/.ssh/config so you never type the port again:

Host my-vps
    HostName your-server-ip
    User amine
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Now you can just type ssh my-vps.

What This Does NOT Cover

10 minutes gets you the essentials. It does not cover:

Application-layer security — if you're running a web app, you still need to harden Nginx, your reverse proxy, your CMS, and so on
Intrusion detection — tools like AIDE or Wazuh for filesystem integrity and behavioral monitoring
Centralized logging — shipping logs to a separate server so an attacker who lands on the box can't quietly cover their tracks
Backups — hardening means nothing if you can't restore after an incident

I'll cover those in future posts. For now, you've blocked the overwhelming majority of automated attacks that hit any new VPS.

What's Next

If you're spinning up a VPS for self-hosting, check out the full build: How I Built byte-guard.net from Scratch on a Hetzner VPS. It uses every step in this post and adds Docker, a reverse proxy, and monitoring on top.

I also wrote a deep dive on Docker Security Best Practices — the container-level companion to this guide.

Quick recap — the 10-minute checklist:

apt update && apt upgrade
Create non-root user with sudo
SSH key auth set up
Root login + password auth disabled in sshd_config
UFW firewall enabled, only the ports you need
fail2ban watching the SSH jail
Unattended security updates running

Run this on every new server you build. After a few times you'll be doing it in closer to 5 minutes than 10.

Originally published on byte-guard.net