Uncloud – Ein Tool zum Deployen von Container-Apps über mehrere Server hinweg, ohne die Komplexität von Kubernetes

 (uncloud.run)
23 Punkte von GN⁺ 2025-12-06 | 1 Kommentare | Auf WhatsApp teilen
  • Uncloud ist ein Open-Source-Tool, mit dem sich containerisierte Webanwendungen auf mehreren Servern bereitstellen und skalieren lassen – ganz ohne Kubernetes
  • Der auf Docker Compose basierende Workflow bleibt erhalten und unterstützt Zero-Downtime-Deployments, automatisches HTTPS und serverübergreifende Skalierung
  • Ohne zentrale Control Plane werden die einzelnen Maschinen über ein WireGuard-basiertes P2P-Netzwerk verbunden, sodass der Cluster weiterläuft, selbst wenn einige Server offline sind
  • Enthält automatisches HTTPS über den Caddy-Reverse-Proxy, integrierte DNS-basierte Service Discovery und Load Balancing
  • Auch in hybriden Cloud- und On-Premises-Umgebungen auf dieselbe Weise einsetzbar, wodurch sich Kontrolle über die Infrastruktur und vorhersehbare Kosten sichern lassen

PaaS-ähnlicher Workflow

  • Bietet ein einfaches Deployment-Erlebnis wie Heroku oder Fly.io und bewahrt zugleich die vollständige Kontrolle über Server und Daten
    • Vorhersehbare Kostenstruktur statt Abrechnung pro Anfrage
    • Keine Vendor-Lock-in, Debugging mit Standard-SSH-Tools möglich
  • Docker-Compose-freundliche Struktur, mit der Build, Push und Deployment per einem Befehl ausgeführt werden
    • Keine Image-Registry erforderlich, Unterstützung für Zero-Downtime-Rolling-Deployments
    • Replikat-Skalierung über mehrere Maschinen hinweg möglich

Wartungsarmes Design

  • Keine Control Plane und kein Quorum-Management erforderlich, wodurch die Verwaltungs-Komplexität minimiert wird
  • Unterstützt sichere Kommunikation zwischen Maschinen ohne offene Ports
  • Automatische Service-Erkennung und automatische HTTPS-Ausstellung auf Basis von Let's Encrypt integriert

Funktionsweise

  • Statt eines komplexen Clusters basiert es auf einem einfachen Netzwerk von Maschinen und bietet eine stabile Infrastruktur ohne hohen Wartungsaufwand
  • Jede Maschine nimmt an einem WireGuard-Mesh-Netzwerk teil und führt automatische Peer-Erkennung sowie NAT-Traversal durch
    • Container erhalten eine eigene IP und können serverübergreifend direkt kommunizieren
  • Vollständig verteilte Architektur: Ohne zentralen Control-Node synchronisiert jede Maschine den Cluster-Zustand
    • Selbst wenn einige Maschinen offline sind, bleibt der Cluster betriebsfähig
  • Steuerung der gesamten Infrastruktur über eine Docker-ähnliche CLI
    • Deployment, Monitoring und Skalierung sind allein mit SSH-Zugriff auf eine einzelne Maschine möglich

Hauptfunktionen

  • Überall deploybar: Unterstützt alle Linux-Maschinen, darunter Cloud-VMs, dedizierte Server und On-Premises-Systeme
  • Automatisches HTTPS: Der integrierte Caddy-Reverse-Proxy übernimmt die TLS-Zertifikatsausstellung ohne Konfiguration und aktiviert HTTPS automatisch
  • Load Balancing: Verteilt Traffic auf Container-Replikate, die über mehrere Maschinen verteilt sind
  • Service Discovery: Das integrierte DNS verfolgt automatisch die Position von Services im Netzwerk
  • Infrastructure as Code: Der komplette App-Stack lässt sich mit bestehenden Docker-Compose-Dateien definieren
  • Kein Vendor-Lock-in: Cloud und eigene Hardware lassen sich frei kombinieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-06
Hacker-News-Kommentar

  • Hallo, ich bin der Entwickler. Danke fürs Teilen.
    Uncloud ist ein Container-Orchestrator ohne Control Plane. Vereinfacht gesagt ist es Docker Compose über mehrere Maschinen hinweg, ergänzt um ein automatisches WireGuard-Mesh, Service Discovery und HTTPS über Caddy. Jede Maschine synchronisiert den Cluster-Zustand per P2P mithilfe von Fly.ios Corrosion, sodass kein Quorum aufrechterhalten werden muss.
    Nachdem ich Kubernetes sowohl in Startups als auch in Unicorn-Unternehmen betrieben habe, wurde mir klar, dass die meisten Teams in Wirklichkeit nur Container auf ein paar Maschinen zuverlässig ausführen wollen und dafür lediglich Networking, Rollouts und HTTPS brauchen. Der operative Overhead von K8s ist dafür im Vergleich einfach zu hoch.
    Die wichtigsten Merkmale sind folgende:

    • verwendet die vertraute Docker-Compose-Spezifikation, ohne dass man eine neue DSL lernen muss
    • baut und pusht Docker-Images direkt auf die Maschinen, ohne externe Registry (unter Verwendung meines anderen Projekts unregistry)
    • bietet eine imperative CLI statt eines deklarativen Ansatzes, was das Debugging erleichtert
    • verbindet Cloud-VMs, Bare Metal und sogar Raspberry Pis hinter NAT
    • Speichernutzung unter 150 MB
      Projektlink: https://github.com/psviderski/uncloud
      • Ich finde, K8s kann bereits in kleinen Umgebungen Container gut betreiben, daher sehe ich keinen besonderen Grund, etwas anderes zu verwenden. Da auch schlanke Distributionen wie k3s einfacher geworden sind, empfinde ich keinen Bedarf für eine Alternative.
      • Die Idee ist cool, aber dass uc machine init intern curl | bash mit Root-Rechten ausführt, wirkt sicherheitstechnisch riskant. Ich würde es gern testen, aber wahrscheinlich nicht auf echten Maschinen laufen lassen.
      • Wirklich interessant. Ich werde es wohl bald ausprobieren können. Allerdings ist selbst nach dem Lesen der Doku nicht klar, wie man nach der Cluster-Einrichtung andere Engineers onboardet oder von einem CI/CD-Runner aus deployt. Mich interessiert insbesondere, wie man von einer neuen Maschine aus einem bestehenden Cluster beitritt.
      • Mich würde der Unterschied zu Kamal interessieren.
      • Mich interessiert, wie man innerhalb eines mit WireGuard aufgebauten privaten Netzwerks eine sichere Verbindung zu externen Diensten wie AWS RDS herstellt. Ich würde gern wissen, ob so etwas wie Tailscales AWS-RDS-Zugriff unterstützt wird.

  • Ich habe den Großteil meiner Karriere mit Kubernetes verbracht und frage mich, was genau die Vorteile einer Architektur ohne Control Plane sind. Für mich ist die Control Plane gerade die zentrale Funktion von K8s.
    Ein paar hundert Nodes und zehntausende Container sind in einem gemanagten Cluster dank automatischer Updates keine große Belastung. Ich frage mich, ob die Schmerzen, die Leute beim Self-Hosting von K8s erleben, der Hintergrund für solche Alternativen sind.

    • „Ein paar hundert Nodes, zehntausend Container“ fühlt sich für mich überhaupt nicht klein an. Ich bewege mich eher bei 2–5 Nodes und 10–30 Containern; in dieser Größenordnung ist K8s einfach zu schwergewichtig. Ich vermute, es gibt viele kleinere Unternehmen in genau dieser Situation.
    • Keine unhöfliche Frage. Der Vorteil ohne Control Plane ist, dass alles zu einer gleichberechtigten Peer-Struktur vereinfacht wird. Es gibt kein zentralisiertes „Cluster-Gehirn“, daher muss man sich weder um HA-Setups noch um etcd-Quorum-Probleme kümmern.
      Selbst bei Netzpartitionen kann jede Partition unabhängig weiterlaufen. Es ist eine Art Rückkehr zur Einfachheit früherer Chef-/Ansible-Zeiten, ergänzt um die Lehren aus K8s.
    • Natürlich versuchen Leute, K8s selbst zu hosten. So wie bei Backups gilt: Wenn man es nicht vorher übt, kann man es im Ernstfall nicht.
    • Aus Sicht kleiner und mittlerer Unternehmen sind zehntausend Container keineswegs wenig. Ich habe weniger als 10, brauche aber Hochverfügbarkeit (HA). Uncloud scheint sehr gut zu meinem Fall zu passen.
    • „Zehntausend Container sollen klein sein? Sind das nicht eher CI-Job-Zahlen? ;)“

  • Tolles Projekt. Ich werde es später auf jeden Fall ausprobieren.
    Wenn du nach einer einfacheren Alternative suchst, ist auch Kamal interessant. Das ist ein Tool, das von einem Unternehmen betrieben wird, das K8s und die Cloud vollständig hinter sich gelassen hat, und es ist in der Praxis erprobt.

  • Mich würde interessieren, ob es eine Funktion gibt, die beim Festlegen von Servern automatisch Server-Hardening durchführt.

  • Ich bin Docker-Swarm-Nutzer. Uncloud ist die erste Alternative, die ich wirklich interessant finde.
    Ich habe folgende Fragen:

    • Gibt es Pläne für Secrets-Unterstützung?
    • Kann man wie bei Swarm+Traefik URL-Rewrite-Regeln über Container-Labels definieren?
    • Wenn man zwei Compose-Stacks deployt, können Container aus unterschiedlichen Stacks dann netzwerkseitig miteinander kommunizieren?
    • Die Zuordnung von Domain und internem Port wird in der Compose-Datei als x-ports: app.example.com:8000/https definiert.
      Alternativ kann man über x-caddy: Caddyfile die Caddy-Konfiguration anpassen. Details dazu stehen in der offiziellen Dokumentation.
      Derzeit gibt es keine Netzwerkisolierung zwischen Stacks. Die entsprechende Diskussion läuft in GitHub Discussion #94.
      Mich würde interessieren, welches Verhalten du erwartest.
    • Die Secrets-Funktion wird in Issue #75 verfolgt. Eine Injektion über die Compose-Config ist möglich, aber es gibt noch keine verschlüsselte Speicherung.
      Die Antwort auf Frage 2 und 3 lautet „noch nicht“ bzw. „derzeit ja“. Die zugehörige Diskussion findet sich in Discussion #94.
      Aus der Perspektive eines Swarm-Nutzers würde mich interessieren, welche Schwächen oder Unbequemlichkeiten von Swarm Uncloud deiner Meinung nach verbessern könnte.

  • Wirklich ein tolles Projekt. Es lohnt sich auch, andere Tools mit ähnlicher Zielsetzung anzusehen.

    • Dokploy
    • Coolify
    • Kubero
      Falls du noch weitere kennst, wäre eine Ergänzung super.
    • Die Liste selbstgehosteter PaaS ist hilfreich.
      Ich habe kürzlich Coolify ausprobiert, und es wirkte etwas unausgereift. Derzeit nutze ich Dokku, hätte aber gern eine bessere UI für die Datenbankverwaltung.

  • Ich bin mit k3s zufrieden, freue mich aber über neue Versuche in dem Zwischenbereich zwischen Docker Compose und vollständigem K8s. Besonders die WireGuard-Integration finde ich spannend.

  • Wirklich ein tolles Tool. Danke für die Arbeit.
    Mich würde interessieren, wie die Zustandsreplikation im Backend funktioniert. CRDTs und Gossip-Protokolle werden erwähnt, aber die konkrete Implementierung bleibt unklar.

    • Die Zustandsreplikation basiert derzeit auf Corrosion.

  • Wenn nicht K8s, warum dann nicht Nomad?

    • Nomad ist auch gut, hat aber immer noch eine Control Plane.
    • Nomad hat eine recht steile Lernkurve. Uncloud hingegen ist für jemanden, der Docker und Compose kennt, nahezu sofort nutzbar.
    • Die Lizenz von HashiCorp verbietet es, eine modifizierte Version als SaaS anzubieten.
      Das heißt, die Nutzung ist außerhalb von Self-Hosting eingeschränkt; faktisch ist eine freie Bereitstellung als Dienst kaum möglich. Siehe dazu den vollständigen Lizenztext.

  • Zur Referenz teile ich noch zwei interessante P2P-Bausteine: