Sie verkaufen Software, nicht Betrieb. Clusterward richtet für jeden neuen Kunden Datenbank, Buckets, Domain und Workload ein, überwacht den Betrieb und baut beim Offboarding sauber zurück. Ihre Anwendung kann Kunden sogar selbst bestellen.
Clusterward ist die Control Plane, mit der ein SaaS-Anbieter seine Kunden auf Scaleway Kubernetes betreibt. Der Stack pro Kunde wird einmal als Pipeline beschrieben: Datenbank auf einer privaten Managed-Instanz, Bucket-Paar mit eigenem Schlüssel, Host mit Record und Zertifikat, Workload aus Ihrem Image oder Chart. Jeder neue Kunde ist ein Lauf dieser Pipeline, jeder Kunde eine eigene Namespace, jede Datenbank eine eigene Rolle. Das Offboarding sichert zuerst und baut dann ab. Ihre Anwendung bestellt Kunden über eine Provisioning-Quelle direkt, ohne dass jemand das Cockpit öffnet.
Einmal im Designer: Datenbank, Buckets, Domain, Workload, in der richtigen Reihenfolge.
Aus dem Wizard oder automatisch aus Ihrer Anwendung über die Provisioning-Quelle.
Namen, Hosts und Buckets werden live auf Kollisionen geprüft, bevor etwas entsteht.
Ressourcen entstehen Schritt für Schritt, Passwörter erst zur Laufzeit gebunden.
Tenant-Seite mit Hosts, Deployments, Backups und Lebenszyklus, Alarme per Slack oder E-Mail.
Datenbank-Dump und Bucket-Archiv in Ihren Backup-Bucket, dann rückwärts abbauen.
Die Betriebsarbeit zwischen „Vertrag unterschrieben“ und „Kunde arbeitet“, als Daten statt als Runbook.
Datenbank, Domain, Bucket, Umgebung und Workload sind Bausteine mit Voraussetzungen und Rollback. Jeder im Team liest und ändert die Pipeline im Cockpit.
Registrieren Sie Ihre Anwendung als Provisioning-Quelle: Clusterward fragt Onboarding- und Offboarding-Anfragen ab, führt sie aus und meldet den Stand zurück. Kein eingehender Maschinenzugang nötig.
Ein Wildcard-Zertifikat deckt alle Kundensubdomains ab, ohne Let’s-Encrypt-Limit. Ein Kunde mit eigener Domain bekommt seinen Host aus einer Wizard-Eingabe.
Eigene Datenbank mit eigener Rolle auf einer privaten Instanz, eigenes Bucket-Paar mit eigenem Schlüssel. Ein geleaktes Passwort reicht nie über einen Kunden hinaus.
Bevor irgendetwas gelöscht wird, liegen Dump und Archiv verifiziert in Ihrem Backup-Bucket. Ohne gesicherten Dump wird nichts abgebaut.
Fehlgeschlagene Onboardings, kranke Pods und ablaufende Zertifikate erreichen Ihren Slack- oder Teams-Kanal, einmal pro Ereignis.
Managed Kubernetes in EU-Rechenzentren, private Nodes, API-Allowlist.
PostgreSQL oder MySQL, nur im privaten Netz, eine Datenbank pro Kunde.
S3-Buckets pro Kunde mit eigenem IAM-Schlüssel und Bucket-Policy.
Wildcard per DNS-01, in jede Kunden-Namespace gespiegelt.
Jede Zeile ist ein Baustein Ihrer Pipeline. Welche Sie kombinieren, entscheidet Ihr Produkt.
| Ressource | Pro Kunde | Beim Offboarding |
|---|---|---|
| Namespace | Eigene Umgebung auf dem Cluster | Entfernt |
| Datenbank | Eigene Datenbank und Rolle | Dump, dann Drop |
| Buckets | Öffentlich und privat, eigener Schlüssel | Archiv, dann Löschen |
| Host | Subdomain mit Wildcard oder eigene Domain | Record entfernt |
| Workload | Ihr Image oder Chart mit Bus-Werten | Undeploy und Löschen |
| Variablen | Dotenv-Vorlage mit frischen Geheimnissen | Mit dem Service entfernt |
Wie die Bausteine funktionieren, steht unter Tenant-Pipelines. Die Datenbank pro Kunde folgt den Regeln aus Managed Datenbanken, der Host denen aus DNS und Zertifikate.
Alle Funktionen sind in jedem Tarif enthalten, Kunden und Nutzer sind unbegrenzt, abgerechnet wird nur nach Clustern, siehe Preise.
Kunden-Onboarding als Bausteine, in unter einer Minute live.
Zu Tenant-PipelinesPostgres und MySQL privat angebunden, eine Datenbank pro Service.
Zu Managed DatenbankenCloudflare-Zonen, Records automatisch, Wildcard-Zertifikate verwaltet.
Zu DNS & ZertifikateIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenBringen Sie Ihren Stack mit. Wir bauen ihn als Pipeline nach und legen den ersten Kunden gemeinsam an.
