Clusterward is the Kubernetes control plane between your code, your customers and your Scaleway project. This page shows how clusters, applications, data, networking, customers and security fit together – and why one cockpit for everything means less work than six tools.
A Kubernetes control plane, in Clusterward’s sense, is the layer above your clusters that defines how applications, databases, domains, secrets and customers come into being, and then operates them. You describe what should run; Clusterward creates it in your Scaleway project, rolls it out, backs it up and alerts you when something goes wrong. Scaleway runs Kubernetes’ own control plane.
The difference from a console: a console shows individual services. A control plane knows how things relate – which database belongs to which service, which domain points to which cluster, which customer owns which resources – and acts on that, when creating as well as when deleting.
One IAM key per Scaleway project, checked before it is saved.
Kapsule in a private network, nodes without public IPs, ingress and certificates.
From Git, an image, a Helm chart or the app catalog, with a database and domain.
Via pipeline: database, buckets, domain and workload per customer in a single run.
Logs, alerts, backups, upgrades and rollback – in the same cockpit.
Each area is useful on its own. The value comes from all of them knowing the same objects.
Kapsule clusters are created secure by default: private network, gateway, nodes without public IPs, API server reachable only from your addresses. You update node pools, the Kubernetes version and add-ons such as the ingress controller and cert-manager from the cockpit; every cluster has its own container registry.
A service comes from a Git repository with a build in the cluster or via GitHub Actions, from a ready-made image or as a Helm chart. Every rollout is confirmed by a health check and pinned by digest, and every earlier version can be brought back. WordPress comes ready to go from the app catalog.
Managed PostgreSQL and MySQL in a private network with one database per service, buckets with their own key, persistent volumes. Backups, snapshots and restores alongside the running database are part of it, as is importing existing databases and buckets. The SQL console queries them read-only, with every query in the audit log.
Every host gets a DNS record and a certificate – automatically with Cloudflare, and via wildcard for many subdomains. Ingress runs on nginx or Envoy Gateway, with timeouts, rate limits, CORS and basic auth per service, and a controller switch without downtime.
For SaaS vendors, every customer becomes a pipeline run: database, buckets, domain and application from a template, live in minutes. Your own application can order customers directly. Offboarding backs up first, then tears down in reverse order.
Mandatory 2FA, roles with application scope, API tokens for CI and an audit log of every change. Secrets can’t be read back and, if you wish, are stored in Scaleway Secret Manager. Logs from all instances, usage, uptime checks and alerts show what is happening in operations.
An example shows it best. A SaaS vendor gets a new customer. In one run, a tenant pipeline creates a database on the managed database instance, a bucket pair with its own key in Object Storage, a subdomain with record and certificate via DNS & certificates, and rolls out the application for the customer.
The credentials never pass through emails or tickets: the database password and bucket key go via the template straight into the service’s environment, and if you wish as unreadable secrets in Scaleway Secret Manager. Who created what is recorded in the audit log.
In operations, Clusterward knows the same relationships. If the customer’s site goes down, an uptime check reports it, and the link leads to the logs of all instances under Logs & monitoring. If the customer needs an earlier state, the database is restored from a backup alongside the running one, as described under Backups & recovery.
If the customer cancels, everything runs in reverse: database dump and bucket archive first, then the application, domain, buckets and database are removed – exactly the ones created for that customer, and no others. This knowledge of how things relate is the difference between a control plane and a collection of scripts.
Clusterward replaces neither Scaleway nor your developers. It takes over the work in between that otherwise lives in scripts, wikis and people’s heads.
| Task | Scaleway | Clusterward | Your team |
|---|---|---|---|
| Kubernetes control plane | Runs it | Uses it | – |
| Clusters, network, registry | Provides services | Creates securely, updates | Chooses size and region |
| Deployments | – | Builds, rolls out, checks, rolls back | Writes the code |
| Databases, buckets, volumes | Runs the services | Creates per service, backs up | Decides about data |
| DNS and certificates | Load balancers | Records, certificates, ingress | Owns the domains |
| Creating and tearing down customers | – | Pipeline, backup before teardown | Defines the template |
| Access and evidence | IAM | 2FA, roles, audit log | Assigns roles |
| Monitoring | – | Logs, usage, uptime, alerts | Responds to alerts |
Your applications are ordinary Deployments, Services and Helm releases – readable with any tool.
Kapsule, Managed Database, Object Storage, Secret Manager and Load Balancer in your own project.
Data centers in Paris, Amsterdam or Warsaw, with a European provider.
Everything keeps running without Clusterward; you export the configuration as a JSON file.
Can’t find your question? Write to us – we usually reply on the same business day.
Ask a questionIn the demo, we connect a Scaleway project, create a cluster, roll out an application and create a customer via pipeline.
