Incus und OCI – warum ich (noch) nicht umsteige

Incus kann seit einiger Zeit OCI-Container starten – also Docker-Images direkt mit incus launch docker:.... Das klingt nach der großen Vereinheitlichung: System-Container, VMs und Docker-Images aus einem Werkzeug. Aber in der Praxis bleibe ich vorerst beim klassischen Docker-Compose-Setup.

## Was Incus mit OCI kann Zunächst braucht man Zugriff auf ein Repository, ich nehme hier einfach docker.io CODEBLOCK0

Der Befehl dann ist verblüffend einfach:

incus launch docker:alpine my-alpine

Incus holt das Image von Docker Hub, legt einen Container an und startet ihn – fertig. Auch docker:debian, docker:ubuntu oder docker:nginx funktionieren. Das Image wird ins Incus-eigene Storage-Backend importiert und wie ein System-Container behandelt.

Feature	Incus OCI	Docker
Image-Pull	incus launch docker:...	docker pull
Container starten	incus launch	docker run
Shell	incus exec	docker exec
Netzwerk	Incus-Netzwerke	Docker-Netzwerke
Volumes	Incus-Storage	Docker-Volumes
Multi-Container	manuell	Compose

Das Problem: Meine Docker-Setups sind nie einfach

Wenn ich Docker nutze, dann nicht für einzelne Container. Meine Compose-Dateien sehen so aus:

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    environment:
      - DATABASE_URL=postgres://...
    volumes:
      - app-data:/data
    networks:
      - internal

  db:
    image: postgres:16
    volumes:
      - pg-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready"]
    networks:
      - internal

  redis:
    image: redis:7-alpine
    networks:
      - internal

  backup:
    image: myapp-backup:latest
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - pg-data:/pgdata:ro
    profiles:
      - manual

networks:
  internal:

volumes:
  app-data:
  pg-data:

Drei Dienste, die sich ein internes Netzwerk teilen, gegenseitige Abhängigkeiten mit Healthchecks, benannte Volumes, Profile – und das ist noch ein überschaubares Beispiel. Meine produktiven Compose-Dateien haben oft 8–12 Dienste, mehrere Netzwerke, env-file-Referenzen und komplexe Healthcheck-Ketten.

Was Incus OCI nicht kann

Incus startet einzelne OCI-Container – aber es gibt kein Äquivalent zu Docker Compose. Keine deklarative Multi-Container-Definition, keine automatische Netzwerk-Verkabelung, kein depends_on, keine Healthcheck-Orchestrierung. Jeder Container müsste per Skript oder von Hand nacheinander angelegt und vernetzt werden.

# So sähe es mit Incus aus – für jedes Service manuell
incus launch docker:postgres:16 pg-db \
  --config limits.memory=512MiB

# Netzwerk manuell anlegen
incus network create mynet --type=bridge

# Jeden Container dem Netzwerk hinzufügen
incus network attach mynet pg-db

# Kein depends_on, keine Healthcheck-Koordination

Das ist nicht nur umständlich – es ist fehleranfällig. Ein `docker compose up -d` macht aus einer Datei in Sekunden ein laufendes Gesamtsystem. In Incus müsste ich mir das selbst bauen.

Was fehlt (noch)

Incus' OCI-Support ist ein guter erster Schritt für Single-Container-Workloads. Wer einfach eine Nginx-Instanz oder einen kleinen Testcontainer braucht, kann das schon heute nutzen. Aber für echte Compose-artige Multi-Container-Setups fehlt:

• Eine deklarative Manifest-Datei (analog zu compose.yaml)
• Automatische Vernetzung mehrerer Container
• Abhängigkeitsauflösung mit Healthchecks
• Einheitliches Volume-Management
• Profile und Umgebungsvariablen auf Set-Ebene

Mein Workflow heute

Ich betreibe Incus für System-Container und VMs – das macht Incus hervorragend. Für Docker-Workloads bleibt es bei Docker Compose in einer Incus-VM oder noch schlanker in einer LXC. Das ist kein Schönwetter-Entwurf, sondern der pragmatische Weg: Incus für Infrastruktur, Docker Compose für Applikations-Stacks.

Wo ich kann, nutze ich direkte Installationen in einer LXC, aber einige Dienste kommen mit einer vorgefertigten und sauber orchestrierten docker-compose daher (mailcow z.Bsp.) ... das will man nicht händisch nachbauen.

Sobald Incus eine echte Compose-Alternative bietet, werde ich umsteigen. Bis dahin sind beide Werkzeuge nebeneinander die richtige Wahl.

Fazit

Incus OCI ist technisch spannend, aber für komplexe Multi-Container-Setups noch nicht reif. Wer wie ich mehrfach Docker-Compose-Stacks mit 5+ Diensten betreibt, wartet besser ab, bis die Orchestrierungsebene nachgereicht ist. Bis dahin: Incus für System-Container, Docker Compose für komplexe App-Stacks – und das ist okay.