DockerSecuritySelfHosting
title: Docker Security Hardening for Self-Hosting type: technique created: 2026-05-16 last_updated: 2026-05-16 related: ["Playradar", "radar/techniques/TelegramBotOnCloudRun"] sources: ["https://danlevy.net/docker-security-tips-for-self-hosting/"] radar_quadrant: Techniques radar_ring: Assess radar_position: center
A collection of defensive practices for securing self-hosted Docker services. Unlike managed cloud deployments, self-hosting transfers full security responsibility to the administrator across every layer: secrets, networking, access control, and monitoring.
Pin container images to specific versions or digests rather than :latest. Use Dependabot or Renovate to receive update notifications, and test upgrades in a dedicated maintenance window before applying to production.
Never hardcode secrets into images or commit them to Git. Generate cryptographically strong values with openssl rand. Storage options by trust level:
| Option | Notes |
|---|---|
| Docker Secrets | Native, swarm-native, no external dependency |
| 1Password / Bitwarden | Password manager integration |
| HashiCorp Vault | Full secrets management, higher operational cost |
| macOS Keychain | Replaces .env files on developer machines |
Canary tokens placed in .env files, CI variables, and password managers act as tripwires: if a secret is exfiltrated and used, the token fires an alert. Source: canarytokens.org.
Bind exposed ports to 127.0.0.1 rather than 0.0.0.0 to prevent external exposure. Use custom Docker networks to isolate services from each other; containers on separate custom networks cannot communicate unless explicitly linked. Avoid publishing ports at all when a reverse proxy handles external traffic.
Note: Docker has documented limitations where same-L2-network hosts can bypass localhost bindings in certain versions. Country-based blocking via UFW reduces noise but is not a security boundary.
Drop all Linux capabilities at the compose level, then add back only what is required:
cap_drop:
- ALL
security_opt:
- no-new-privileges=true
cap_add:
- NET_BIND_SERVICE # only if neededDetermine required capabilities by running the container with all dropped and reading the error output, or consulting community-maintained examples.
Mounting docker.sock into a container grants it full Docker API access — equivalent to root on the host. Avoid it. If a container requires Docker API access (e.g., Watchtower, Portainer), place docker-socket-proxy in front and restrict the API surface to the minimum required endpoints. Read-only socket mounts do not prevent API calls through the socket.
All external-facing services should sit behind a reverse proxy (Nginx, Caddy, Traefik) with HTTPS termination. Basic authentication on admin routes adds a second factor before application-level auth. Nginx Proxy Manager simplifies multi-domain management for home server setups.
The author describes this as "the most important and most overlooked step." Security measures that are not tested should not be trusted.
| Tool | Purpose |
|---|---|
| nmap | Scan external-facing ports from an external network |
| lsof / ss / netstat | Verify open ports and connections locally |
| inotifywait / fswatch | Monitor file changes for unauthorized access |
| glances | Real-time system resource and process overview |
Scan from a different network (mobile hotspot, VPS) periodically to verify firewall rules are enforcing as expected, not just as configured.
No single measure is sufficient. The article advocates stacking: network isolation + capability dropping + reverse proxy authentication + canary tokens + active monitoring. Each layer reduces risk independently; together they require an attacker to defeat multiple controls.
Docker Security Hardening for Self-Hosting sits in the Assess ring of the Techniques quadrant, at center position. First exposure via danlevy.net on 2026-05-16; no hardening practices applied to date. The article provides a concrete, actionable checklist across six layers (secrets, networking, capabilities, socket protection, reverse proxy, monitoring). Center position reflects broadly applicable practices — relevant to any self-hosted Docker deployment — with low adoption friction since partial adoption delivers value. Zero personal implementation is the gap between this and inner Assess.
