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. Bring your own cloud: everything Clusterward creates lives in your own Scaleway account.
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. For workloads with needs of their own, pool claims create node pools on demand.
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 and Uptime Kuma come 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 – with an editor, saved queries, diagnostics and every query in the audit log – and changes data only if you allow it, after a preview. Clusterward backs up buckets every night with Object Lock and tests the restore monthly.
Every host gets a DNS record and a certificate – automatically in zones at Cloudflare or Scaleway DNS, 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. The compliance page shows ISO 27001 checks and supplies the reports for your audit. The dashboard gathers what needs you right now, shows the last 24 hours and, under Infrastructure → Monitoring, the capacity of every project. AI assistants such as Claude, Cursor or VS Code answer operations questions by your rights and may deploy if you allow it.
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.
The infrastructure follows demand too: if a customer needs nodes of their own or a scanner needs computing capacity for an hour, pool claims create a matching node pool and release it again.
If you do not bring an application of your own, start with a blueprint from the app catalog: WordPress or Uptime Kuma, with a disk, snapshots and a certificate.
What operations back up and record becomes evidence: the S3 backups copy every bucket locked at night and test the restore, and the compliance page brings checks, reports and the access review together for your ISO 27001 audit.
Clusterward replaces neither Scaleway nor your developers. It takes over the work in between that otherwise lives in scripts, wikis and people’s heads. Scaleway provides the data centres and hardware, in your own account – Clusterward is software.
| Task | Scaleway | Clusterward | Your team |
|---|---|---|---|
| Data centres and hardware | Runs them | – | – |
| 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 |
| Bill for resources | Bills you directly | Adds no mark-up | Pays Scaleway |
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.
The console manages individual services. Clusterward knows how they relate: which database, which bucket and which domain belong to which service and customer. That makes possible deployments with health checks, customer pipelines, backups before deletion and an audit log covering everything.
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.
