Docker kenne ich. LXC auch? Ein ehrlicher Einstieg auf dem Debian-Server

22. April 2026

Warum LXC neben Docker sinnvoll sein kann – und wie man mit Incus auf Debian einsteigt.

Docker läuft seit Jahren auf meinem Debian-Server. LXC habe ich bisher nur aus Proxmox-Tutorials gekannt und ignoriert. Dieser Artikel erklärt ehrlich, wo die Werkzeuge sich unterscheiden, warum LXC neben Docker sinnvoll ist und wie man es mit Incus direkt auf Debian einrichtet – ohne Proxmox, ohne Canonical-Drama.

Ausgangslage: Docker läuft, LXC war bisher nur ein Begriff

Auf meinem Debian-Server im Homelab läuft seit Jahren Docker. Compose-Stacks für Traefik, Uptime Kuma, ein paar Bastelprojekte, GitLab CI-Runner – das übliche. Alles, was irgendwo ein docker-compose.yml hat, ist bei mir schnell aufgesetzt.

LXC habe ich bisher nur am Rand wahrgenommen. Meistens in Proxmox-Tutorials, wo Leute fröhlich zwischen "VM oder LXC?" wählen. Ich habe kein Proxmox – also habe ich das Thema jahrelang ignoriert, getreu dem Motto: "Ich habe Docker, was brauche ich noch einen zweiten Container-Stack?"

Nach einer Diskussion über genau diese Frage war ich neugierig genug, mir das endlich mal ernsthaft anzuschauen – direkt auf dem Debian-Server, ohne Proxmox im Spiel. Dieser Artikel ist der Einstieg: das Mental Model, das Setup mit Incus, und mein konkreter Plan für die nächsten Wochen. Der Praxisbericht mit den echten Learnings folgt später.

Warum überhaupt? Docker ist doch "ein Container"

Der erste Impuls ist: "Docker-Container ist doch auch ein Linux-Container, wozu also LXC?" Technisch stimmt das – beide nutzen dieselben Kernel-Primitives (cgroups, namespaces). Aber sie sind für unterschiedliche Probleme gebaut. Die Verwirrung kommt daher, dass das Wort "Container" für zwei sehr unterschiedliche Konzepte benutzt wird.

Ich wurde bisher nie richtig wach, weil meine Use-Cases bisher alle zufällig die App-Container-Philosophie getroffen haben. Sobald man aber einen Dienst betreibt, der sich eher wie ein echter Server verhält – mit mehreren Prozessen, systemd, Logrotate, Cronjobs – merkt man, dass Docker zwar geht, sich aber ständig im Weg steht.

Das Mental Model, das endlich sitzt

Kurzfassung

Docker = eine App, die per Image verpackt läuft. Ein Hauptprozess, ephemer, Image-zentriert, Config liegt im compose.yml.

LXC = ein Mini-Linux, das sich wie ein eigener Server anfühlt. Mehrere Prozesse, systemd, langlebig, du SSH-st rein und arbeitest wie auf einer VM – nur ohne den Virtualisierungs-Overhead.

Praktisch heißt das:

Docker denkt in Apps: Ein Container = ein Dienst = ein Image. Neustart wirft den State weg (sofern kein Volume). Update = neues Image ziehen und Container ersetzen. Reproduzierbarkeit und Portabilität sind die zentralen Stärken.
LXC denkt in Systemen: Ein Container = ein kleines Debian/Ubuntu/Alpine. Neustart behält den State wie bei einem echten Server. Update = apt upgrade innerhalb des Containers. systemctl, journalctl, Cron, alles da.

Die gleichen Kernel-Bausteine, komplett unterschiedliche Philosophien. Docker ist unterbau-kompatibel zu LXC, aber konzeptionell ein anderes Tier.

Warum Incus und nicht "nur" LXC?

Hier wird's kurz politisch. In der LXC-Welt gibt es drei Begriffe, die leicht verwirren:

LXC – die Low-Level-Userspace-Tools für Linux-Container. Gibt es ewig, funktioniert, ist aber spröde zu bedienen (lxc-create, lxc-start, XML-artige Configs).
LXD – der komfortable Daemon + CLI, den Canonical entwickelt hat. Tolles Tool, aber seit Canonical es 2023 unter eine CLA gestellt und näher an Ubuntu gekoppelt hat, hat die Community einen Fork gezogen.
Incus – der Community-Fork von LXD unter dem Dach der Linux Containers Project. Das ist aktuell die empfohlene Variante, speziell auf Debian. Es ist in Debian 12 (Backports) und Debian 13 direkt im Repo.

Wenn du also heute auf Debian LXC-Container betreiben willst: nimm Incus. Das native lxc-Paket reicht zwar prinzipiell, aber Incus gibt dir Storage-Pools, Netzwerke, Profile, Snapshots und eine saubere CLI aus einer Hand.

Setup: Incus auf Debian

Das Setup ist erfreulich unaufgeregt. Ich gehe hier von Debian 13 (Trixie) aus – auf Debian 12 (Bookworm) geht es genauso, man holt Incus dann aus den Backports.

# Als root oder mit sudo
apt update
apt install incus incus-ui-canonical

# Deinen User in die incus-admin-Gruppe aufnehmen,
# damit du ohne sudo arbeiten kannst:
adduser $USER incus-admin

# Neu einloggen, damit die Gruppenmitgliedschaft aktiv wird
newgrp incus-admin

Dann einmal interaktiv initialisieren. Für einen Homelab-Server passen die Default-Antworten fast immer – ich wähle nur bewusst den Storage-Backend aus:

incus admin init

# Die wichtigsten Fragen:
# - Storage pool: "dir" (einfach, /var/lib/incus) oder "zfs" (wenn du ZFS hast)
# - Network bridge: "incusbr0" mit automatischer NAT-Config — einfach Yes
# - Available over the network? No (es sei denn, du weißt was du tust)

Das war's. Der Daemon läuft, das Netzwerk ist eingerichtet, ein Storage-Pool ist da. Der erste Container ist jetzt ein Einzeiler:

# Debian-12-Container namens 'test' starten
incus launch images:debian/12 test

# Shell im Container öffnen
incus exec test -- bash

# Darin bist du als root in einem Mini-Debian:
root@test:~# apt update && apt install nginx -y
root@test:~# systemctl status nginx
root@test:~# exit

# Container auflisten
incus list

Wichtiger Unterschied zu Docker

Nach incus exec test -- bash bist du in einem lebendigen System. systemd läuft. apt funktioniert. Logs bleiben beim Neustart erhalten. Der Container fühlt sich genauso an wie eine kleine VM – nur dass incus start test in unter einer Sekunde durch ist und kaum RAM kostet.

Mein Plan: Was läuft bald in LXC?

Der spannende Teil: Wo wird LXC bei mir Docker ersetzen oder ergänzen? Nach allem was ich bisher gelesen habe, sind das meine drei Kandidaten für die nächsten Wochen:

Pi-hole / AdGuard Home. Aktuell läuft bei mir Pi-hole in Docker und tut, was es soll – aber die Kombi aus Port 53, Host-Networking und DNS-Henne-Ei beim Booten war schon mehrfach nervig. In einem LXC-Container mit eigener IP im Bridge-Netzwerk wäre das strukturell sauberer.
Ein GitLab Runner mit systemd-Workloads. Für CI-Jobs, die selbst Container bauen und systemctl-Tests ausführen (z.B. fürs Testen von Ansible-Rollen), ist LXC der natürlichere Ort als Docker-in-Docker-Geraffel.
Eine Spiel-Umgebung. Ein LXC-Container, in dem ich frei mit Paketen, Konfigs und Kernel-Modulen experimentieren kann, ohne den Host anzufassen. Nachher Snapshot wegwerfen, alles weg – das ist für Lernprojekte Gold wert.

Was nicht wandert: alle Compose-Stacks, Traefik, die Bastelprojekte. Das bleibt in Docker. Config-as-Code, Git-Workflow, schnelles Ausrollen – dafür ist Docker da und da macht LXC keinen Sinn.

Docker in LXC? Kurz, klar, vermutlich nicht

Eine Frage, die früh aufkommt: Kann man nicht einfach Docker in einem LXC-Container laufen lassen? Ja, technisch geht das. Auf aktuellem Incus/Kernel sogar halbwegs schmerzfrei, wenn man die entsprechenden Security-Profile setzt (security.nesting=true).

Aber: Das ist eine Lösung für Fälle, in denen man sowieso schon Docker hat und zusätzlich Isolierung braucht – zum Beispiel in einer Multi-Mandanten-Umgebung oder einem CI-Runner. Im Homelab mit einem einzigen Admin ist das Overkill. Wenn du Docker willst, lass Docker auf dem Host laufen. Wenn du ein kleines Linux-System willst, nimm LXC. Beides zusammen nur, wenn du einen echten Grund dafür hast.

Wo Docker für mich klar bleibt

Damit der Artikel nicht zum LXC-Hype wird, hier die Gegenrichtung – Docker wird bei mir für diese Jobs nicht abgelöst:

Alles, was per Compose-Stack zusammengehört. Traefik + Uptime Kuma + Grafana, gemeinsames Netzwerk, ein up -d – LXC würde das nur verkomplizieren.
Alles, wofür es ein gutes offizielles Image gibt. Image ziehen, Volume mounten, fertig. Kein apt install, kein System-Tuning.
Alles, was Config-as-Code braucht. Mein Homelab-Git-Repo ist gleichzeitig die komplette Deployment-Definition. Das ist ein Setup, das ich mir über Jahre aufgebaut habe – da fasse ich nichts an.
CI/CD und reproduzierbare Builds. Da ist Docker schlicht der Standard.

Was ich weggelassen habe

Ehrliche Abgrenzung

Dieser Artikel ist bewusst ein Einstieg. Folgendes habe ich absichtlich nicht behandelt, obwohl man beim LXC-Thema schnell dort landet:

Proxmox. Ich habe kein Proxmox. Wer eines hat, bekommt vieles davon geschenkt über die GUI – aber der Artikel richtet sich an Leute mit einem nackten Debian-Server.
Unprivileged vs. privileged Containers, User-Namespaces. Incus macht standardmäßig das Richtige (unprivileged). Die Detail-Diskussion gehört in einen eigenen Artikel.
Backup-Strategie für LXC-Container. Kommt als Folgeartikel – vermutlich mit Restic, analog zu dem was ich für den Rest des Homelabs plane.
Performance-Benchmarks. Hätte den Artikel aufgebläht und ehrlich gesagt: Im Homelab ist der Unterschied egal. Auf Ressourcen-Effizienz gehe ich im Praxisbericht ein.

Fazit & wie's weitergeht

Nach der ersten Beschäftigung mit dem Thema ist für mich klar: Docker und LXC sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Jobs. Docker bleibt das Tool der Wahl für App-Deployments, Compose-Stacks und Config-as-Code. LXC füllt die Lücke für Services, die sich eher wie kleine Linux-Server verhalten, und für Experimentier-Umgebungen.

Dass das Ganze auf einem normalen Debian-Server mit Incus erstaunlich unaufgeregt läuft, war für mich die eigentliche Überraschung. Man braucht weder Proxmox noch die Ubuntu-Tooling-Schiene.

Als Nächstes: Ich ziehe Pi-hole von Docker nach LXC um, setze einen GitLab Runner in einem LXC-Container auf und lege mir eine Experimentier-Umgebung an. In ein paar Wochen folgt der Praxisbericht – mit Stolpersteinen, Learnings und einer ehrlichen Antwort auf die Frage: "Hat sich der zweite Container-Stack gelohnt?"

Bis dahin: incus launch images:debian/12 test und mal schauen, wie sich das anfühlt.