You sell software, not operations. Clusterward sets up the database, buckets, domain and workload for every new customer, monitors operations and cleanly tears everything down at offboarding. Your application can even order customers itself.
Clusterward is the control plane a SaaS vendor uses to run its customers on Scaleway Kubernetes. The per-customer stack is described once as a pipeline: a database on a private managed instance, a bucket pair with its own key, a host with record and certificate, a workload from your image or chart. Every new customer is one run of this pipeline, every customer its own namespace, every database its own role. Offboarding backs up first and then tears down. Your application orders customers directly through a provisioning source, without anyone opening the cockpit.
Once, in the designer: database, buckets, domain, workload, in the right order.
From the wizard, or automatically from your application via the provisioning source.
Names, hosts and buckets are checked live for collisions before anything is created.
Resources are created step by step, with passwords bound only at runtime.
Tenant page with hosts, deployments, backups and lifecycle, alerts via Slack or email.
Database dump and bucket archive into your backup bucket, then tear down in reverse order.
The operations work between “contract signed” and “customer at work”, as data instead of a runbook.
Database, domain, bucket, environment and workload are building blocks with prerequisites and rollback. Everyone on the team can read and change the pipeline in the cockpit.
Register your application as a provisioning source: Clusterward polls it for onboarding and offboarding requests, executes them and reports the status back. No inbound machine access required.
A wildcard certificate covers all customer subdomains, without hitting the Let’s Encrypt limit. A customer with their own domain gets their host from a single wizard input.
A dedicated database with its own role on a private instance, a dedicated bucket pair with its own key. A leaked password never reaches beyond a single customer.
Before anything is deleted, the dump and archive are in your backup bucket, verified. Without a backed-up dump, nothing is torn down.
Failed onboardings, unhealthy pods and expiring certificates reach your Slack or Teams channel, once per event.
Managed Kubernetes in EU data centers, private nodes, API allowlist.
PostgreSQL or MySQL, private network only, one database per customer.
S3 buckets per customer with their own IAM key and bucket policy.
Wildcard via DNS-01, mirrored into every customer namespace.
Every row is a building block of your pipeline. Which ones you combine is up to your product.
| Resource | Per customer | At offboarding |
|---|---|---|
| Namespace | Its own environment on the cluster | Removed |
| Database | Dedicated database and role | Dump, then drop |
| Buckets | Public and private, own key | Archive, then delete |
| Host | Subdomain with wildcard or custom domain | Record removed |
| Workload | Your image or chart with bus values | Undeploy and delete |
| Variables | Dotenv template with fresh secrets | Removed with the service |
How the building blocks work is explained under Tenant pipelines. The per-customer database follows the rules from Managed databases, the host those from DNS & certificates.
Every feature is included in every plan, customers and users are unlimited, and billing is by cluster only; see Pricing.
Customer onboarding from building blocks, live in under a minute.
Go to Tenant pipelinesPostgres and MySQL connected privately, one database per service.
Go to Managed databasesCloudflare zones, automatic records, managed wildcard certificates.
Go to DNS & certificatesCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionBring your stack. We rebuild it as a pipeline and create the first customer together.
