Describe once what a new customer needs: database, domain, buckets, workload. Clusterward runs the pipeline per tenant, with progress, retry, rollback and an offboarding that backs up first and tears down second.
A tenant pipeline is an ordered list of steps that Clusterward runs for every new tenant. The steps are building blocks: a database on an instance, a domain with record and certificate, one or more buckets with their own key, an environment with an application or container, a Helm workload. Each building block publishes values on a variable bus, such as the database URL or hostname, which later steps only resolve at execution time. The designer checks the order, onboarding runs in the background, and every step can be retried or rolled back.
Add and order building blocks; the designer rejects broken sequences.
The wizard only asks for the customer details and the declared inputs.
Database names, hosts, service names and buckets are checked live for collisions.
Each step saves its resources immediately; waiting times block nothing.
Host, service, database and buckets appear on the tenant page with live status.
An onboarding that today lives in scripts, tickets and people’s heads becomes data everyone on the team can read.
Each building block is a step with prerequisites and outputs. Database, domain, bucket, environment and workload can be combined freely and created inline in the designer.
Workloads use ${db.main.url} or ${domain.app.host}. The values are only read at execution time; the database password never appears in the run.
The wizard resolves the exact specification and checks every artifact name against the instance, the domains and the buckets. A conflict blocks the start; an inconclusive check only warns.
A failed step is retried without recreating anything that came before. Rollback runs the compensations in reverse: database gone, records gone, services torn down.
First back up every database and archive non-empty buckets, then tear down. Nothing is deleted without a secured dump.
Your application orders onboarding and offboarding via a documented protocol; Clusterward polls it, fulfills the requests and reports the status back.
A line KEY=secret:value in an environment building block’s env template becomes a write-only secret of the service – in the Scaleway Secret Manager if you want, in the service’s folder.
Before the first rollout, a workload building block creates chart secrets: generated keys, wizard inputs or database passwords. The values read them as ${secret.NAME}.
Environment building blocks carry the service’s network settings with them: timeouts, retries, rate limits, CORS and basic auth.
Environment building blocks have a “Volumes (optional)” section in the designer: name, mount path, size, storage class and snapshot schedule per disk, created with each customer’s service, which then runs exactly one instance. Rollback and offboarding snapshot every disk before it is deleted.
The “Inputs” card shows what a customer was onboarded with. “Edit inputs…” changes a value and first shows every line of the service values that changes.
When the pipeline gains an input later, existing tenants see it marked new and set it like the others. Optional inputs left empty stay empty.
A domain step takes the ingress class of the workload or environment step that serves its host – so the record points at exactly that load balancer. You pick the class once from a list, on the serving step; only for a host no step serves does the domain step pick it itself.
Workload and environment steps have an “Uptime checks” list: host, path, expected status and interval. The checks are created right after the first healthy rollout – a new customer is watched from the very start.
Every bucket of the bucket step has a “Back up nightly” box, on by default. Untick it for buckets whose content can be rebuilt.
The tenant list shows which chart version each tenant runs on, or how many commits its application is behind the branch. The “behind version” tile filters the ones waiting for an update.
“Update to the newest version…” in a tenant’s menu pins its chart services to the newest version and rolls them out – for that tenant only. That way you try an update on one customer before the rest follow.
Every row of the tenant list shows its services’ health and the last 24 hours of its uptime checks as a bar. The tiles above filter the list, and Retry, Open site, Edit inputs and Offboard sit right in the row.
One namespace per tenant, pinned at creation, never recomputed from the name.
Application from a build, container image or Helm chart with values from the bus.
Dotenv template with bus values and freshly generated secrets per occurrence.
Record, ingress and certificate; a Cloudflare proxy is detected.
Each building block creates its resources idempotently and knows its compensation for the rollback.
| Component | Creates | Publishes | Rollback |
|---|---|---|---|
| Database | Database and owner role on an instance | name, user, password, host, port, url | Drop |
| Domain | Record, ingress, certificate; ingress class from the serving step | host, url | Delete its own records |
| Bucket | 1..n buckets, each backed up nightly if wanted, optionally a key | access_key, secret_key | Delete empty buckets and keys |
| Environment | Namespace and a service from a build or image, optionally with volumes and uptime checks | Service and host | Volume data (after a snapshot), undeploy, namespace, environment |
| Workload | Helm release from the template library, optionally with uptime checks | Service and host | Uninstall and delete |
| HTTP check | Nothing; waits for a healthy response | Nothing | Nothing |
The building blocks use the same functions as the cockpit: the database is created as described under Managed databases, the host as under DNS & certificates, the bucket as under Object Storage.
If you run many customers, the SaaS vendors page shows the way from the first cluster to an orderable pipeline.
Postgres and MySQL connected privately, one database per service.
Go to Managed databasesZones at Cloudflare or Scaleway DNS, automatic records, managed wildcard certificates.
Go to DNS & certificatesBuckets with their own IAM key and bucket policy per application.
Go to Object StorageIn a live run, a pipeline with a database, domain and container workload finished in under a minute. The duration depends on certificate issuance and application startup; verification steps wait patiently and can be deliberately skipped while DNS is still propagating.
Can’t find your question? Write to us – we usually reply on the same business day.
Ask a questionBring your current runbook. In the demo, we rebuild it as a pipeline and run the first tenant.
