Der häufigste Wettbewerber von Clusterward ist kein Produkt, sondern der eigene Stack aus Terraform, Helm-Charts, GitHub Actions und einem Wiki. Er ist kostenlos in der Lizenz und teuer in allem anderen. Dieser Vergleich zeigt, was der Eigenbau leistet, was er kostet und wo er tatsächlich die bessere Wahl ist.
Gemeint ist die übliche Lösung eines Teams, das Kubernetes auf Scaleway selbst betreibt: Terraform oder die Konsole für den Cluster, Helm-Charts oder Kustomize für die Anwendungen, GitHub Actions für Builds und Rollouts, cert-manager und external-dns für Zertifikate und Records, ein Skript pro Kunde für das Onboarding, ein Wiki für alles, was nicht automatisiert ist. Jede Komponente ist Open Source und für sich gut. Die Arbeit steckt im Zusammenbau, in der Pflege und im Wissen, das nur in wenigen Köpfen liegt. Clusterward ersetzt nicht die Komponenten, sondern den Zusammenbau: Es rendert Standardobjekte auf denselben Cluster, mit Prüfungen und Sicherheitsnetzen, die im Eigenbau selten jemand nachbaut.
Keine Stundensätze, nur die Aufgaben. Rechnen Sie selbst, wie viele Tage im Jahr davon bei Ihnen anfallen und wer sie macht, wenn die eine Person im Urlaub ist.
| Aufgabe | Eigenbau | Clusterward |
|---|---|---|
| Cluster sicher anlegen | Terraform-Modul schreiben und pflegen, Härtung als eigene Schritte | Assistent, sicher ab Werk, wiederholbar |
| Anwendung deployen | Chart pro App, Workflow pro Repo, Secrets per Hand | Service mit Build, Variablen verschlüsselt, Registry-Prüfung |
| Datenbank pro Service | Instanz in der Konsole, CREATE DATABASE per psql, Passwort im Chat | Ein Klick auf der Service-Seite, private Instanz |
| Domain und Zertifikat | external-dns, cert-manager, Issuer, Rate-Limits im Blick behalten | Host eintragen, Record und Zertifikat automatisch, Warnung 14 Tage vorher |
| Neuer Kunde | Skript oder Runbook, kennt eine Person | Pipeline, bestellbar aus der App, Rollback inklusive |
| Kunde kündigt | Löschen und hoffen, dass jemand vorher gesichert hat | Dump und Archiv, dann Abbau, Abbruch ohne Sicherung |
| Kubernetes-Upgrade | Konsole, Changelogs lesen, Add-ons prüfen | Zielversionen, Kompatibilität, Add-on-Drift im Cockpit |
| Zugriff und Nachweis | Kubeconfigs verteilen und einsammeln | Rollen, Pflicht-2FA, Audit-Log |
| Neuer Kollege | Wiki lesen, Zugänge sammeln, ein bis zwei Tage | Rolle zuweisen, Projekte freischalten |
Was der Eigenbau kann, wenn jemand es baut, und was Clusterward mitbringt, ohne dass jemand es baut.
| Funktion | Eigenbau | Clusterward |
|---|---|---|
| Private Nodes, API-Allowlist | Möglich, muss man wissen | Voreinstellung |
| Registry-Prüfung vor dem Rollout | Selten | Immer |
| Restart ohne Rebuild | Per kubectl rollout | Ein Klick |
| Datenbank mit Rolle und Default-Privilegien | Per Hand, oft vergessen | Eingebaut |
| Wildcard-Zertifikat per DNS-01 | cert-manager, Issuer, Reflector konfigurieren | Registrieren, fertig |
| Tenant-Onboarding mit Rollback | Skript, meist ohne Rollback | Pipeline mit Kompensationen |
| Offboarding mit Backup | Wenn es jemand baut | Abbruch ohne Sicherung |
| Volumes mit Snapshot vor dem Löschen | Selten | Eingebaut |
| Alarme nur bei Übergängen | Alertmanager tunen | Eingebaut, mit Entwarnung |
| Audit-Log jeder Änderung | Git-Log, wenn alles in Git ist | Jede Aktion mit Person |
| Multi-Cloud | Ja | Nein, nur Scaleway |
| Beliebige Kubernetes-Objekte | Ja | Nur, was Clusterward rendert |
| Frühere Version per Klick | Wenn jemand das alte Tag kennt | Ja, exaktes Image per Digest |
| Datenbank-Backup mit Wiederherstellung | Skript, selten getestet | Ja, neben der laufenden Datenbank |
| Export der Konfiguration | Verteilt über Repos und Wikis | JSON-Datei, ohne Geheimnisse |
Es gibt Teams, für die der Eigenbau die richtige Wahl bleibt. Drei Fälle, in denen wir das in der Demo auch sagen.
Operatoren, Service Meshes, eigene CRDs, Objekte, die Clusterward nicht rendert: Der Eigenbau kann alles, Clusterward nur, was es kennt. Beides auf demselben Cluster geht, aber dann pflegen Sie zwei Wege.
Clusterward ist auf Scaleway gebaut und bleibt es. Wer AWS, Hetzner oder On-Premise braucht, findet hier keine Abstraktion.
Ein Team mit zwei bis drei Leuten, die Kubernetes gern betreiben und die Zeit dafür haben, braucht keine Control Plane. Der Eigenbau ist dann kein Risiko, sondern ihr Handwerk.
Kubeconfig importieren; Clusterward liest erst einmal nur und erkennt vorhandene Add-ons.
Dasselbe Dockerfile als Build, Variablen in den Editor, Rollout neben dem alten Chart.
Datenbank importieren oder adoptieren, Host umstellen, Zertifikat kommt automatisch.
Wenn die letzte Anwendung umgezogen ist; das Terraform bleibt als Dokumentation.
Wie ein Cluster sicher ab Werk entsteht, steht unter Cluster-Provisioning; die Regeln für Datenbanken, die im Eigenbau meist fehlen, unter Managed Datenbanken.
Der Vergleich mit einem gekauften Produkt steht unter Clusterward vs. Qovery. Wer heute mit Skripten arbeitet, findet den Umzugsweg auch unter Migration.
Preise, Cluster, Nutzer und Datenhoheit im Vergleich.
Zu Clusterward vs. QoveryKapsule-Cluster sicher ab Werk, mit Private Network und Gateway.
Zu Cluster-ProvisioningRollen, Pflicht-2FA, Audit-Log und IP-Allowlist.
Zu Sicherheit & ZugriffNicht unbedingt. Terraform hat Ihren Cluster angelegt; Clusterward bindet ihn per Kubeconfig an und übernimmt den Betrieb darauf: Deployments, Datenbanken, Domains, Onboarding, Alarme. Das Terraform bleibt, als Dokumentation oder für den nächsten Cluster. Ersetzt wird der Teil, der täglich Arbeit macht.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenBringen Sie Ihr Terraform, Ihre Charts und Ihr Wiki mit. Wir zeigen, was davon Clusterward übernimmt, und sagen ehrlich, wo Sie beim Eigenbau bleiben sollten.
