IncusOS ist die neue Variante von Incus, die noch einen Schritt weitergeht als Proxmox: Keine Shell auf dem Host, kein SSH, kein apt update. Alles wird über die REST-API gesteuert. Das klingt nach der Zukunft – aber auch nach einem Verlust von Kontrolle.
Was ist IncusOS?
IncusOS ist eine minimale Linux-Distribution, die ausschließlich dafür da ist, Incus-Container und VMs zu betreiben. Es gibt:
- Keine Shell auf dem Host
- Keinen Paketmanager
- Keinen Editor
- Keinen Zugriff auf das Dateisystem
Und das Wichtigste: IncusOS ist atomar. Das Betriebssystem wird als einheitliches Image ausgeliefert und kann nicht manuell verändert werden. Kein apt upgrade, kein manuelles Kopieren von Dateien, kein Konfigurationsfehler, der den Host unbrauchbar macht. Entweder das Image läuft, oder es läuft nicht. Dazwischen gibt es nichts.
Alles läuft über die API:
# Container starten
incus launch images:debian/12 webserver
# Container auflisten
incus list
# Backup erstellen
incus export webserver backup.tar.gzDer Host selbst ist eine Black Box. Man sieht ihn, aber man kann ihn nicht anfassen.
Der Vergleich zu Proxmox
| Aspekt | Proxmox | IncusOS | Incus (klassisch) |
|---|---|---|---|
| Shell auf Host | Ja | Nein | Ja |
| REST-API | Ja | Ja | Ja |
| Web-UI | Ja | Ja (Incus UI) | Ja |
| Paketmanager | Ja (apt) | Nein | Ja |
| Konfiguration | Dateien + API | Nur API | Dateien + API |
| SSH auf Host | Ja | Nein | Ja |
| Minimal-Image | Nein | Ja | Nein |
Proxmox ist ein vollwertiger Hypervisor mit Shell-Zugang. IncusOS geht noch weiter: Es ist eine Appliance, kein Server. Das ist konsequent – aber auch einschränkend.
Was mich reizt
Klarheit
Kein Verwirrspiel mit systemd-units, die man vergessen hat zu deaktivieren. Kein Skript, das aus Versehen auf dem Host läuft. Kein crontab, der irgendwo hängt. Der Host ist sauber, weil er nichts kann außer Incus.
Reproduzierbarkeit
Weil der Host leer ist, kann man ihn jederzeit neu aufsetzen und die Konfiguration über die API wiederherstellen. Kein "hast du vielleicht auf dem Host noch was manuell angepasst?" – es gibt nichts, was man manuell anpassen könnte.
Sicherheit
Kein SSH auf dem Host bedeutet: Kein Passwort, das erraten werden kann. Kein钥schlüssel, der gestohlen werden kann. Kein Dienst, der offen im Netzwerk lauscht. Die API ist der einzige Zugangspunkt.
Was mich stört
Kein Debugging
Wenn etwas schiefgeht, kann ich nicht einfach auf den Host schauen. Kein journalctl, kein dmesg, kein ps aux. Ich bin auf die API angewiesen – und wenn die API nichts zeigt, stehe ich da.
Kein Flexibilität
Was ist, wenn ich einen speziellen Daemon auf dem Host laufen lassen will? Ein Monitoring-Tool, ein Backup-Skript, ein eigener DNS- Server? Bei IncusOS geht das nicht. Der Host ist ein Appliance, keine Plattform.
Vendor Lock-in
IncusOS ist open source, aber es ist eine spezifische Lösung. Wenn Incus das Projekt einstellt oder die API ändert, habe ich ein Problem. Bei einem normalen Linux-Server mit Incus hätte ich immer noch den Host als Backup.
Meine Zweifel
Ich bin mir unsicher, ob ich mich darauf einlassen soll. Die Idee ist klug: Ein Host, der nichts kann außer das, wofür er da ist. Aber in der Praxis brauche ich manchmal doch die Shell. Wenn ich testen will, warum ein Container nicht startet. Wenn ich einen speziellen Netzwerk-Test machen will. Wenn ich einfach nur wissen will, was auf dem Host passiert.
IncusOS gibt mir dieses Gefühl nicht. Es ist wie ein Auto ohne Motorhaube – sauber, aufgeräumt, aber wenn der Motor hakt, kann ich nicht mal gucken.
Der Portabilitäts-Gedanke
Trotz all meiner Zweifel: Der Gedanke, alle meine Incus-Instanzen in eine IncusOS-VM zu migrieren, reizt mich. Denn dann wäre der komplette Stack – Host, Container, Konfiguration – in einer einzigen Datei verschachtelt. Die IncusOS-VM könnte ich von einem Server auf den anderen schieben, auf einem anderen Hypervisor starten, im Notfall auf einem anderen Rechner wiederherstellen.
Das wäre die ultimative Portabilität: Nicht mehr Incus auf einem Server, sondern Incus als Datei. Ein incus export der gesamten VM, und alles ist gesichert. Kein "auf dem Host läuft noch was", kein "da hast du vergessen, das zu konfigurieren". Alles drin.
Aber genau das ist auch das Risiko: Wenn die IncusOS-VM nicht mehr startet oder die API sich ändert, habe ich alle Eier in einem Korb.
Fazit
IncusOS ist die konsequenteste Lösung für Container-Hosting. Kein Ballast, kein Verwirrspiel, nur die API. Für alle, die Incus als Appliance betreiben wollen, ist es ideal.
Aber ich bleibe wahrscheinlich bei Incus auf einem normalen Server. Nicht weil IncusOS schlecht ist, sondern weil ich die Kontrolle über den Host schätze. Die Shell ist mein Sicherheitsnetz – und auf dieses Netz möchte ich nicht verzichten.