If you run containers at home, your base images are quietly accumulating CVEs you never asked for. 🔒 That changed in December 2025, when Docker made its entire catalog of over 1,000 Docker Hardened Images (DHI) free and fully open source under the Apache 2.0 license. For anyone doing docker hardened images self-hosting, this is one of the most impactful security upgrades of the year — zero cost, minimal effort.
This post walks you through what DHI actually is, why it matters for your homelab, and how to start migrating your stack today. Whether you are just getting started or already running a full stack on Proxmox, docker hardened images self-hosting is the easiest security win available right now.
🧱 What Are Docker Hardened Images?
Docker Hardened Images are minimal, security-focused base images maintained directly by Docker. They launched in May 2025 as a paid enterprise product and were open-sourced in December 2025. Compared to the standard community images most of us pull from Docker Hub, DHIs are fundamentally different in several ways:
- Rootless by default — every image runs as a non-root user out of the box 🛡️
- Distroless runtime — only what your app needs, nothing extra
- Near-zero CVEs — compared to 200+ in a typical
node:20community image - SBOM included — every image ships with a full Software Bill of Materials
- SLSA Level 3 provenance — cryptographic proof the image was built as claimed
- Built on Debian and Alpine — no vendor-specific Linux, no surprises
Docker claims DHI reduces vulnerabilities by up to 95% compared to traditional community images. That is not a marketing rounding error — you can verify it yourself with Docker Scout.
🔍 Check Your Current CVE Count (Before Migrating)
Before touching anything, scan a few images you actually use. If you’re new to containers, check out Docker for Beginners: Containers, Images, Volumes, Compose first.
bash
# Install Docker Scout if you haven't yet
docker scout version
# Scan a standard community image
docker scout cves postgres:16-alpine
# Scan the hardened equivalent
docker scout cves docker.io/dockerhardened/postgres:16-alpineThe difference is usually dramatic. A standard postgres:16-alpine might show 40–80 inherited CVEs from packages Postgres never touches. The hardened version typically shows fewer than 5, often zero.
🏠 Why Docker Hardened Images Self-Hosting Makes Sense
There is a common misconception that hardened images are for enterprise teams and compliance departments. In reality, docker hardened images self-hosting is arguably even more valuable at home, because homelabs rarely have a dedicated security team watching for vulnerabilities.
Think about what a typical homelab runs: a database, a password manager, a media server, reverse proxy, maybe Nextcloud or Bitwarden. Each of those pulls a base image that might not have been patched in months. Those inherited CVEs create real attack surface — especially if you expose any of these services externally.
If you are running self-hosted Bitwarden (Vaultwarden) or any like this, the idea that your password manager container carries dozens of unaddressed vulnerabilities is uncomfortable. With DHI, that concern is largely gone.
🔄 How to Migrate Your Stack
Migrating to docker hardened images self-hosting is a drop-in replacement in most cases. The hardened images live at docker.io/dockerhardened/ on Docker Hub.
Here’s a minimal Docker Compose migration example:
yaml
services:
# Before (community image)
# postgres:
# image: postgres:16-alpine
# After (hardened image)
postgres:
image: docker.io/dockerhardened/postgres:16-alpine
volumes:
- pgdata:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
redis:
image: docker.io/dockerhardened/redis:7-alpine
volumes:
- redisdata:/data
volumes:
pgdata:
redisdata:
secrets:
db_password:
file: ./secrets/db_password.txtAfter swapping images, verify nothing broke and re-scan to confirm CVE reduction:
bash
docker scout cves docker.io/dockerhardened/postgres:16-alpine
docker sbom docker.io/dockerhardened/postgres:16-alpine⚠️ One Critical Catch: Volume Permissions
Heads up: Since DHI images run rootless by default, if your existing data directories are owned by
root, the container will fail to write to them after migration.
Before migrating a service that has existing data, check what UID the hardened image uses:
bash
# Inspect the expected user
docker inspect docker.io/dockerhardened/postgres:16-alpine | grep -i userThen fix permissions on your data directory accordingly:
bash
# Example: if the hardened image expects UID 999
sudo chown -R 999:999 /path/to/your/dataThis is the single most common migration issue. Everything else is usually a clean drop-in. If you want to manage your containers through Portainer, the Getting Started with Portainer guide covers how to update and redeploy stacks from the UI without touching the CLI.
🔎 What About MCP Servers?
Docker also extended the DHI hardening methodology to MCP servers — the interface layer that AI assistants use to interact with external tools. Hardened versions of Grafana, MongoDB, GitHub, and others are already available. If you are experimenting with AI tooling on your homelab (like OpenClaw on a home server), this is worth knowing.
🎯 Free Tier vs. DHI Enterprise
For homelab purposes, the free Community tier covers everything:
| Feature | Free (Community) | DHI Enterprise |
|---|---|---|
| Full DHI catalog (1,000+ images) | ✅ | ✅ |
| Apache 2.0 license | ✅ | ✅ |
| SBOM + SLSA provenance | ✅ | ✅ |
| CVE remediation SLA (7-day) | ❌ | ✅ |
| FIPS/FedRAMP compliance | ❌ | ✅ |
| Image customization service | ❌ | ✅ |
Approach docker hardened images self-hosting step by step: start with the free tier, verify the CVE reduction, and only consider Enterprise if compliance becomes a requirement. For self-hosters, there is no reason to pay.
🚀 Conclusion
Docker hardened images self-hosting is no longer a “someday” thing — it is free, practical, and the images work as drop-in replacements for most standard Docker Hub pulls. The only real migration work is handling volume permissions for rootless containers, and even that is a one-time fix per service.
Start with one non-critical container — Redis or a logging tool like Dozzle — verify it works, then roll through the rest of your stack. If you are new to self-hosting and want to run everything on Proxmox, check the Proxmox VE 9.1 Installation Guide to get your foundation right before hardening the container layer.
Official resources:
Leave a Reply