Zwanzig Kunden, zwanzig Stacks, ein Team. Clusterward rollt Anwendungen aus Git aus, legt Datenbank und Domain per Klick an und gibt jedem Kunden und jedem Freelancer genau den Zugriff, den er braucht.
Für Agenturen ist Clusterward das Cockpit, in dem alle Kundenprojekte auf Scaleway Kubernetes liegen. Jedes Projekt ist eine Anwendung mit Umgebungen, Services und Builds; Anwendungen lassen sich zu Gruppen ordnen, etwa pro Kunde. Ein Kunde oder Freelancer bekommt eine Rolle mit Anwendungsbereich und sieht nur seine Projekte. Deployments kommen aus Git, Datenbank und Domain entstehen auf der Service-Seite, Umgebungsvariablen liegen verschlüsselt im Cockpit. Ein Cluster trägt viele Projekte in getrennten Namespaces; wer Isolation braucht, bekommt einen eigenen Cluster im eigenen Scaleway-Projekt.
Anwendung mit Repository, Build und Umgebungen wie Staging und Produktion.
Entwickler bedienen, der Kunde sieht, der Freelancer nur sein Projekt.
Datenbank auf der Service-Seite erzeugen, Domain eintragen, Zertifikat kommt von allein.
Deployment aus Git mit Health-Check, Restart bei Konfigurationsänderung.
Der Kunde bekommt Lesezugriff auf sein Projekt und Alarme in seinen Kanal.
Der Betrieb, der sonst zwischen Hetzner-Kisten, Vercel-Accounts und einem Kubeconfig-Ordner verteilt ist.
Die Anwendungsübersicht ordnet Projekte in Gruppen, etwa pro Kunde, mit Health-Status und letztem Deployment pro Service. Reihenfolge und Zugehörigkeit gelten für das ganze Team.
Rollen vergeben pro Bereich eine Stufe; der Anwendungsbereich begrenzt einen Nutzer auf seine Projekte. Ein Kunde sieht sein Projekt, ein Freelancer deployt nur seins. Jede Aktion im Audit-Log.
Branch, Dockerfile und Image gehören zum Build. Gebaut wird im Cluster ohne Docker-Daemon oder mit GitHub Actions auf GitHub-Runnern, das Tag wird vor dem Rollout geprüft.
Auf der Service-Seite entsteht die Datenbank mit Rolle und Passwort in einem Schritt, der Host bekommt Record und Zertifikat. Verbindungsdaten zum Kopieren im Cockpit.
Wiederkehrende Variablensätze als Vorlage, beim Anlegen in das Projekt kopiert. Mehrzeilige Werte wie Schlüssel bleiben intakt.
Ein Kanal pro Kunde: fehlgeschlagene Deployments, kranke Pods und ablaufende Zertifikate landen im richtigen Slack- oder Teams-Kanal, einmal pro Ereignis.
Eine neue Kundenseite mit WordPress entsteht aus vier Feldern: eigene Datenbank, Festplatte mit täglichen Snapshots, Cron-Job und Zertifikat. Bis zur Einrichtung schützt ein Passwort den Installer.
Managed Kubernetes in EU-Rechenzentren, Kosten direkt bei Scaleway.
Image-Builds ohne Build-Server, wahlweise im Cluster oder auf GitHub.
PostgreSQL oder MySQL, privat angebunden, eine Datenbank pro Service.
Records automatisch bei Cloudflare oder Scaleway DNS, Zertifikate pro Host oder als Wildcard.
Eine Rolle vergibt pro Bereich eine Stufe, dazu kommt die Liste der freigegebenen Projekte.
| Person | Rolle | Sieht und darf |
|---|---|---|
| Projektleitung | Anwendungen verwalten | Alle Projekte, Nutzer einladen, löschen |
| Entwickler | Anwendungen bedienen | Seine Projekte deployen, Variablen ändern, Logs lesen |
| Freelancer | Anwendungen bedienen, ein Projekt | Nur das freigegebene Projekt |
| Kunde | Anwendungen ansehen, ein Projekt | Status, Deployments und Logs seines Projekts |
| Betrieb | Administrator | Cluster, Datenbanken, DNS, alles |
Wie ein Projekt vom Commit in den Cluster kommt, steht unter Deployments. Rollen, Anwendungsbereich und Audit-Log beschreibt Sicherheit und Zugriff.
Wer Kunden mit dem immer gleichen Stack ausstattet, etwa ein CMS pro Kunde, beschreibt ihn einmal als Pipeline, siehe Tenant-Pipelines. Was es kostet, steht auf Preise: zwei Cluster ab 99 € im Monat, Projekte und Nutzer unbegrenzt.
Wie eine WordPress-Seite aus dem App-Katalog entsteht, zeigt WordPress auf Kubernetes; welche Fallen es beim Eigenbau gibt, der Beitrag WordPress auf Kubernetes: Sieben Fallen.
Git, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsRollen, Pflicht-2FA, Audit-Log und IP-Allowlist.
Zu Sicherheit & ZugriffKunden-Onboarding als Bausteine, in unter einer Minute live.
Zu Tenant-PipelinesNein. Ein Cluster trägt viele Projekte in getrennten Namespaces; die meisten Agenturen fahren mit einem Cluster für alle kleineren Kunden und eigenen Clustern nur dort, wo ein Kunde Isolation oder ein eigenes Scaleway-Projekt verlangt. Ein eigener Cluster entsteht mit dem Provisioning-Profil des Kundenprojekts.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir legen eines Ihrer Projekte an, rollen es aus Git aus und richten den Zugriff für Kunde und Team ein.
