Ihr Cluster bleibt, Ihre Repositories bleiben, Ihre Domains bleiben. Clusterward bindet den bestehenden Cluster an, übernimmt Anwendung für Anwendung und importiert Datenbanken und Buckets mit Pause statt Ausfall. Für ein Zehntel des Preises.
Qovery und Clusterward tun Ähnliches: Sie rollen Anwendungen aus Git auf Kubernetes aus und verwalten Datenbanken, Domains und Umgebungen. Der Unterschied liegt im Preis, in der Cloud und in der Datenhoheit. Eine Migration heißt deshalb nicht Neuaufbau, sondern Übernahme: Der Kapsule-Cluster wird per Kubeconfig registriert, jede Anwendung als Service mit Build angelegt, Umgebungsvariablen kopiert, die Datenbank als Job in eine private Managed-Instanz importiert, Buckets kopiert, DNS umgestellt. Anwendung für Anwendung, mit Qovery als Fallback, bis die letzte umgezogen ist.
Kubeconfig importieren, geprüft und verschlüsselt. Oder einen neuen Cluster mit privaten Nodes anlegen.
Repository, Branch, Dockerfile: derselbe Build wie bei Qovery, gebaut mit Kaniko oder GitHub Actions.
Umgebungsvariablen in den verschlüsselten Editor, mehrzeilige Werte bleiben intakt.
Ein Job kopiert Schema und Daten in eine private Managed-Instanz; die Anwendung pausiert währenddessen.
Objekte aus dem alten Bucket in einen eigenen mit eigenem Schlüssel, wiederholbar.
Host am Service eintragen, Record und Zertifikat entstehen, dann zeigt DNS auf den neuen Ingress.
Jeder Schritt ist eine Cockpit-Funktion, kein Sonderskript für den Umzug.
Ein Kapsule-Cluster wird über seine Kubeconfig registriert; das Token wird vor dem Speichern geprüft. Clusterward installiert nichts ungefragt, Add-ons zeigen Sie an und aktualisieren Sie bewusst.
Der Import läuft als Job im Cluster, prüft die Quelle, setzt die Anwendung auf null Instanzen, kopiert, und startet sie wieder. Ein nicht leeres Ziel fragt nach, statt zu überschreiben.
Objekte werden aus jedem erreichbaren S3-Bucket kopiert, mit Fortschritt und Abbruch. Kopieren und überschreiben, nie löschen; ein zweiter Lauf ist idempotent.
Solange DNS auf Qovery zeigt, läuft dort alles weiter. Sie stellen pro Host um und können zurück, bis Sie Qovery kündigen. Liegen die Records schon in einer Cloudflare-Zone, übernimmt Clusterward sie und stellt sie beim Go-live selbst um, statt zweite anzulegen.
Cloudflare-Zonen registrieren, Records automatisch, Zertifikate pro Host oder als Wildcard. Ein Host hinter Cloudflare-Proxy wird erkannt.
Qovery Business kostet laut Preisliste 2.999 $ im Monat für drei Cluster und zwanzig Nutzer. Clusterward Team kostet 299 € für zehn Cluster und unbegrenzt viele Nutzer.
Derselbe Cluster, dieselben Namespaces, Server-Side-Apply statt Terraform.
Derselbe Build, gebaut von Kaniko im Cluster oder von GitHub Actions.
Externe Charts landen in der Template-Bibliothek und werden versioniert gepinnt.
Nichts wird umgezogen, nur neu verbunden.
Das Modell ist vertraut. Die Begriffe unterscheiden sich an wenigen Stellen.
| Qovery | Clusterward | Unterschied |
|---|---|---|
| Organization / Project | Workspace / Anwendung | Der Workspace hat eigene Datenbank und Schlüssel |
| Environment | Umgebung | Eine Namespace auf genau einem Cluster |
| Application | Service mit Build | Build und Image gehören zur Anwendung, nicht zum Service |
| Managed Database | Managed Datenbank | Scaleway-Instanz, nur privat, eine Datenbank pro Service |
| Custom Domain | Domain am Service | Record automatisch, TLS pro Domain oder Wildcard |
| Lifecycle Job | Pipeline-Baustein | Onboarding pro Kunde statt pro Deployment |
| Secret | Secret am Service | Nur schreibbar, wahlweise im Scaleway Secret Manager |
| Advanced Settings | Netzwerk-Karte | Timeouts, Rate-Limits, CORS, Basic Auth mit Standard pro Feld |
| API-Token | API-Token | Mit Rolle, Anwendungsbereich und Ablaufdatum |
| Terraform Export | Kein Export nötig | Objekte liegen in Ihrem Cluster und Projekt |
Den vollen Vergleich mit Tabellen und den Stellen, an denen Qovery stärker ist, lesen Sie unter Clusterward vs. Qovery. Wie der Datenbank-Import im Detail läuft, steht unter Managed Datenbanken.
Für den ersten Schritt reicht ein bestehender Cluster; der Leitfaden Erste Schritte führt vom Workspace bis zum ersten Deployment. Die Tarife stehen auf Preise.
Preise, Cluster, Nutzer und Datenhoheit im Vergleich.
Zu Clusterward vs. QoveryGit, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsPostgres und MySQL privat angebunden, eine Datenbank pro Service.
Zu Managed DatenbankenIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenBringen Sie Ihr Qovery-Setup mit. Wir binden Ihren Cluster an und ziehen die erste Anwendung gemeinsam um.
