Docker auf Debian installieren: docker.io oder docker-ce?

29.07.2026

Docker auf Debian: das Distributions-Paket docker.io oder docker-ce aus dem Docker-Repository? Beide Wege Schritt für Schritt, die Unterschiede ehrlich verglichen, mit klarer Empfehlung für die Entwicklung.

Inhaltsverzeichnis

Methode 1: docker.io aus den Debian-Quellen
Methode 2: docker-ce aus dem Docker-Repository
Der ehrliche Vergleich
Was nimmst du wann?
Stolpersteine
Fazit

Für Docker auf Debian gibt es zwei Installationswege, und beide sind mit einer Zeile erklärt: apt install docker.io nimmt das Paket aus den Debian-Quellen, apt install docker-ce das Paket aus dem Repository von Docker selbst. Beide liefern eine funktionierende Docker Engine. Trotzdem ist die Wahl keine Geschmacksfrage, denn dahinter steckt dieselbe Frage wie bei Terraform-Providern: Es geht nicht nur darum, was du installierst, sondern wer es dir liefert, in welcher Version und in welchem Takt.

Vorweg die kurze Antwort: Für die Entwicklung nimm docker-ce. Warum, und wann docker.io trotzdem die richtige Wahl ist, klärt der Rest dieses Beitrags.

Methode 1: docker.io aus den Debian-Quellen

Der Weg der kurzen Wege, ganz ohne fremde Paketquellen:

sudo apt update
sudo apt install docker.io
sudo systemctl enable --now docker
docker version

Antworten Client und Server bei docker version, läuft die Installation.

Was du damit bekommst: ein Paket, das Debian selbst pflegt. Es kommt aus dem normalen main-Archiv, wird vom Debian-Sicherheitsteam versorgt und folgt den Debian-Konventionen, unter anderem zerlegt Debian das Ganze in eigene Pakete wie docker.io, docker-cli, containerd und runc.

Der Preis dafür ist das Debian-Tempo: Die Version friert mit dem Release ein und bekommt danach im Wesentlichen nur noch Sicherheits-Fixes. Konkret liefert Debian 13 „Trixie” die Engine 26.1, während aktuell Version 29 der Stand ist. Das ist kein Versehen, sondern genau das Stabilitätsversprechen, für das man Debian auf Servern einsetzt.

Methode 2: docker-ce aus dem Docker-Repository

Der zweite Weg fügt das offizielle Repository von Docker hinzu, so wie es die Docker-Dokumentation beschreibt:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) \
  signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

Das ist sichtbar mehr Arbeit: GPG-Schlüssel hinterlegen, Paketquelle eintragen, erst dann installieren. Dafür bekommst du die aktuelle Engine direkt vom Hersteller, und mit ihr das komplette moderne Toolset: docker compose und docker buildx als Plugins in aktueller Version, dazu containerd.io passend abgestimmt. Jedes apt upgrade bringt ab jetzt neue Docker-Releases, sobald sie erscheinen.

Der ehrliche Vergleich

Kriterium	docker.io	docker-ce
Gepflegt von	Debian-Community	Docker Inc.
Version	friert mit dem Release ein, Trixie: 26.1	aktuell, derzeit 29
Updates	Sicherheits-Fixes im Debian-Takt	neue Releases sofort per apt
Compose und Buildx	separat, teils ältere Stände	als aktuelle Plugins dabei
Einrichtung	eine Zeile, keine Fremdquelle	Fremd-Repository plus GPG-Schlüssel

Zwei Punkte aus der Tabelle verdienen einen zweiten Blick.

Der Feature-Rückstand ist real, nicht kosmetisch. Ein Beispiel aus dem Beitrag zur Docker Architektur: Seit Engine 29 ist der containerd image store bei Neuinstallationen der Standard, mit Multi-Platform-Images und einheitlichem Unterbau Richtung Kubernetes. Die Engine 26 aus den Debian-Quellen kann das zwar zuschalten, bleibt aber im alten Standard und generell auf dem Funktionsstand von gestern. Wer Features wie aktuelle Buildx-Fähigkeiten oder neue Compose-Syntax aus Tutorials nachvollziehen will, scheitert mit einer drei Major-Versionen alten Engine regelmäßig an Kleinigkeiten.

Die Vertrauensfrage stellt sich bei beiden, nur anders. Die Docker Engine ist in beiden Fällen freie Software unter Apache 2.0, ein Lock-in droht nirgends. Aber docker.io liefert dir die Debian-Community aus einem Archiv, dem dein System ohnehin schon vertraut, während docker-ce bedeutet, einem zusätzlichen Hersteller-Repository samt Schlüssel dauerhaft Update-Rechte auf deinem System einzuräumen. Das ist bei Docker Inc. ein überschaubares Risiko, aber es ist eine bewusste Entscheidung, keine Formalie. Genau deshalb lohnt es sich, beide Wege zu kennen, statt blind ein Setup-Skript zu kopieren.

Was nimmst du wann?

Für die Entwicklung: docker-ce. Auf der Maschine, auf der du Images baust, Compose-Stacks fährst und Tutorials nachbaust, zählt Aktualität: aktuelle Plugins, aktuelle Fehlerbehebungen, Parität mit CI-Umgebungen und mit Docker Desktop bei den Kolleginnen und Kollegen. Der einmalige Repository-Aufwand amortisiert sich mit dem ersten apt upgrade.

Für den konservativen Server: docker.io ist legitim. Wenn ein Debian-Server einfach ein paar Container betreiben soll und du Updates bewusst nur aus einer Quelle beziehen willst, ist das Distributions-Paket die ruhigere Wahl: ein Update-Kanal, ein Sicherheitsteam, keine Überraschungen durch neue Major-Versionen. Den Feature-Rückstand nimmst du dabei bewusst in Kauf.

Für Kubernetes-Knoten: keins von beiden. Kubernetes spricht direkt mit containerd, eine vollständige Docker-Installation hat auf einem reinen Cluster-Knoten nichts verloren. Auch das ergibt sich direkt aus der Architektur-Kette CLI, dockerd, containerd, runc.

Stolpersteine

Beide Pakete vertragen sich nicht. Wer von docker.io auf docker-ce wechselt, entfernt vorher die alten Pakete, sonst meldet apt Konflikte:

sudo apt remove docker.io docker-doc docker-compose \
  podman-docker containerd runc

Die Images und Volumes unter /var/lib/docker bleiben dabei erhalten, apt remove löscht keine Daten. Für den Ernstfall gilt trotzdem: Wichtige Volumes vor dem Wechsel sichern.

Docker ohne sudo. Nach beiden Installationswegen gehört dein Benutzer noch nicht zur Gruppe docker:

sudo usermod -aG docker $USER

Nach Ab- und Anmeldung funktioniert docker version ohne sudo. Sei dir dabei bewusst, dass die Gruppe docker faktisch Root-Rechte bedeutet: Wer Container starten darf, kann das gesamte Host-Dateisystem mounten.

Die Versionsfrage im Team. Uneinheitliche Engine-Versionen im Team sind eine unterschätzte Fehlerquelle („bei mir baut das Image aber”). Einigt euch auf einen Installationsweg, am einfachsten auf docker-ce, dann sind alle automatisch auf dem gleichen, aktuellen Stand.

Fazit

apt install docker.io installiert das von Debian gepflegte Paket: eine Quelle, Debian-Stabilität, aber eingefrorener Funktionsstand (Trixie: Engine 26, aktuell ist 29).
docker-ce aus dem Docker-Repository liefert die aktuelle Engine samt Compose- und Buildx-Plugins, kostet dafür eine bewusste Vertrauensentscheidung für ein Hersteller-Repository.
Für die Entwicklung ist docker-ce die richtige Wahl, für den konservativen Container-Server ist docker.io vertretbar, auf Kubernetes-Knoten gehört containerd direkt.
Beim Wechsel erst die alten Pakete entfernen; /var/lib/docker bleibt erhalten.
Egal welcher Weg: usermod -aG docker nicht vergessen, und im Team denselben Weg gehen.

Beide Wege führen zu freier Software, der Unterschied liegt im Vertriebsweg und im Takt. Wer beides kennt, entscheidet souverän, statt das erstbeste Setup-Skript zu kopieren. Und genau darum geht es: die eigene Plattform verstehen, von der ersten Paketquelle an.

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.