Docker Hardened Images sind frei: Was Selbsthoster jetzt davon haben
Stand: 20. Juni 2026, 14:30 Uhr CEST. Docker macht die eigenen Docker Hardened Images inzwischen als freien Community-Katalog nutzbar. Fuer Selfhoster und kleine Produktiv-Stacks ist das keine Marketing-Kleinigkeit, sondern ein praktischer Sicherheitsgewinn: mehr Transparenz, weniger Angriffsflaeche und ein klarer Weg weg von beliebigen latest-Images.
Der interessante Punkt ist nicht nur, dass Docker hier wieder ein neues Produkt verkauft. Wichtig ist etwas anderes: Der Katalog ist als Apache-2.0-Open-Source-Teil frei verfuegbar, laeuft auf Docker Hub / dhi.io und kommt mit den Sicherheitsmerkmalen, die man sich bei Basis-Images schon lange wuenscht, aber selten komplett bekommt.
Was Docker jetzt wirklich anbietet
Docker trennt die Hardened Images inzwischen klar in drei Stufen:
- Community: frei und offen unter Apache 2.0
- Select: fuer erweiterte Compliance und SLA-Ansprueche
- Enterprise: fuer volle Anpassung, strengere Vorgaben und Enterprise-Betrieb
Fuer die meisten Leser ist vor allem die Community-Stufe spannend. Die DHI-Dokumentation nennt dafuer genau die Dinge, die bei normalen Basis-Images oft fehlen:
- SBOMs fuer saubere Komponenten-Sicht
- SLSA Build Level 3 Provenance
- cryptographische Signaturen
- voll sichtbare CVE-Daten
- Drop-in-Adoption ohne grosse Umbauten
Die Images basieren auf den vertrauten Fundamenten Alpine und Debian. Das ist wichtig, weil man dadurch nicht auf eine exotische Sonderwelt wechseln muss.
Warum das fuer Selbsthoster relevant ist
Im Homelab oder auf einem VPS laufen oft genau die Dinge, die spaeter nerven: Datenbanken, kleine Backends, Worker, Admin-UIs, Reverse Proxies, Medienwerkzeuge. Viele dieser Container beginnen mit einem simplen Basis-Image. Genau dort entsteht aber ein grosser Teil der Sicherheitslast.
Die gute Nachricht:
- Weniger Pakete im Image bedeuten meist weniger Angriffsflaeche.
- Eine sichtbare SBOM erleichtert das Pruefen.
- Signaturen und Provenance machen die Herkunft nachvollziehbarer.
- Wer eh mit Docker Compose arbeitet, muss den Workflow oft kaum aendern.
Docker beschreibt den Ansatz selbst als minimal, verifizierbar und produktionsreif. Fuer Selbsthoster ist das der entscheidende Punkt: Man bekommt nicht nur ein kleineres Image, sondern auch mehr Vertrauen in die Lieferkette.
So nutzt du DHI praktisch
Der Einstieg ist bewusst unspektakulaer. Du meldest dich mit deinem Docker-Account bei der DHI-Registry an:
docker login dhi.io
Danach kannst du Images wie im normalen Docker-Alltag ziehen, zum Beispiel:
docker pull dhi.io/python:3.13
Oder du setzt ein DHI-Image direkt in einem Compose-Stack ein, wenn fuer deinen Dienst ein passender DHI-Tag existiert:
services:
app:
image: dhi.io/python:3.13
Der eigentliche Umstieg ist also oft kein Projekt, sondern eher eine Zeile im Setup. Der groesste Haken ist nicht die Technik, sondern die Auswahl: Nicht jeder Dienst hat sofort ein passendes Hardened-Image.
Was an dem Ansatz stark ist
Docker hat hier drei Dinge kombiniert, die zusammen mehr sind als die Summe ihrer Teile:
- Vertrauen
- Signaturen, SBOM und Provenance machen die Herkunft sichtbarer.
- Praxis
- Alpine und Debian bleiben bekannte Grundlagen.
- Skalierung
- Der Community-Katalog ist breit genug, dass der Nutzen nicht bei ein paar Showcase-Images endet.
Damit wird aus einem reinen Sicherheitsprodukt ein brauchbarer Standard fuer echte Workloads. Das ist der Punkt, an dem sich DHI von vielen "hardened" Marketing-Seiten unterscheidet.
Was kostenlos ist und was nicht
Fuer private Nutzer und viele kleine Teams reicht die freie Stufe bereits weit:
- Community ist frei nutzbar und offen unter Apache 2.0.
- Der volle Katalog ist laut Docker ohne Paywall verfuegbar.
- Zusatztarife kommen erst ins Spiel, wenn man harte SLAs, FIPS/STIG-Varianten oder mehr Anpassung braucht.
Kostenpflichtig wird es also erst dann interessant, wenn du:
- regulaer mit Compliance-Vorgaben arbeitest
- feste CVE-Reaktionszeiten brauchst
- Images selbst anpassen willst
- oder Extended Lifecycle Support benoetigst
Fuer den typischen Selbsthoster ist das eher Randthema. Da zaehlt vor allem: Gibt es das passende Image, und laesst es sich im eigenen Stack sauber testen?
Typische Stolpersteine
Beim Umstieg solltest du ein paar Dinge im Hinterkopf behalten:
- Registry-Zugriff: DHI sitzt nicht einfach nur auf Docker Hub, sondern nutzt
dhi.io. Das bedeutet: einmal sauber einloggen und den Zugriff im Build-/Deploy-Workflow mitdenken. - Debugging: Viele minimalen Images sind deutlich schlanker als klassische Community-Varianten. Eine Shell im Container ist nicht immer vorhanden.
- Kompatibilitaet: Auch wenn die Basis vertraut ist, sollte ein produktiver Dienst erst in einer Testumgebung umgestellt werden.
- Nicht blind ersetzen: Nicht jede Anwendung braucht sofort DHI. Manchmal ist ein gut gepflegtes offizielles Image noch die pragmatischere Wahl.
Gerade der letzte Punkt ist wichtig: Sicherheit ist nicht nur die Frage, ob etwas gehaertet ist. Sie ist auch die Frage, ob der Betrieb danach noch sauber funktioniert.
Und was ist mit MCP-Servern?
Docker dehnt den Hardened-Ansatz inzwischen auch auf den MCP-Stack aus. Fuer Leser, die bereits mit KI-Tools, lokalen Agenten oder Docker-basierten Tooling-Workflows arbeiten, ist das interessant, weil sich der gleiche Gedanke dort fortsetzt: weniger unnoetige Oberflaeche, mehr nachvollziehbare Bausteine.
Das ist kein Nebenthema mehr. Wer heute Container, Tools und Agenten zusammen betreibt, will nicht drei verschiedene Sicherheitslogiken pflegen. Genau da wird ein gehaerteter Standard-Katalog spannend.
Fazit
Docker Hardened Images sind fuer Selbsthoster vor allem deshalb interessant, weil sie einen Sicherheitsstandard liefern, der im Alltag wirklich nutzbar ist. Kein Sonderweg, kein proprietaeres Format, sondern ein frei zugaenglicher, verifizierbarer Katalog auf bekannter Linux-Basis.
Wenn du ohnehin Docker Compose, VPS oder kleine Produktions-Stacks betreibst, lohnt sich der Blick auf den DHI-Katalog sofort. Nicht jedes Projekt muss umgestellt werden. Aber wenn es ein passendes Hardened-Image gibt, ist es oft der bessere Startpunkt als ein zufaelliges Community-Image.