Clusterward’s most common competitor isn’t a product, but your own stack of Terraform, Helm charts, GitHub Actions and a wiki. It’s free to license and expensive in every other way. This comparison shows what DIY delivers, what it costs and where it genuinely is the better choice.
We mean the usual setup of a team that runs Kubernetes on Scaleway itself: Terraform or the console for the cluster, Helm charts or Kustomize for the applications, GitHub Actions for builds and rollouts, cert-manager and external-dns for certificates and records, one script per customer for onboarding, and a wiki for everything that isn’t automated. Each component is open source and good in its own right. The work lies in assembling and maintaining them, and in the knowledge that lives in only a few heads. Clusterward doesn’t replace the components, it replaces the assembly: it renders standard objects onto the same cluster, with checks and safety nets that hardly anyone rebuilds in a DIY setup.
No hourly rates, just the tasks. Work out for yourself how many days a year they take up for you, and who does them when that one person is on vacation.
| Task | DIY | Clusterward |
|---|---|---|
| Creating a cluster securely | Write and maintain a Terraform module, hardening as separate steps | Wizard, secure by default, repeatable |
| Deploying an application | A chart per app, a workflow per repo, secrets by hand | Service with build, variables encrypted, registry check |
| Database per service | Instance in the console, CREATE DATABASE via psql, password in the chat | One click on the service page, private instance |
| Domain and certificate | external-dns, cert-manager, issuer, keeping an eye on rate limits | Enter the host, record and certificate created automatically, warning 14 days ahead |
| New customer | Script or runbook, known to one person | Pipeline, orderable from the app, rollback included |
| Customer cancels | Delete and hope someone made a backup first | Dump and archive, then teardown; aborts without a backup |
| Kubernetes upgrade | Console, read changelogs, check add-ons | Target versions, compatibility, add-on drift in the cockpit |
| Access and evidence | Hand out and collect kubeconfigs | Roles, mandatory 2FA, audit log |
| New colleague | Read the wiki, collect credentials, one to two days | Assign a role, grant access to projects |
What DIY can do if someone builds it, and what Clusterward brings without anyone having to build it.
| Feature | DIY | Clusterward |
|---|---|---|
| Private nodes, API allowlist | Possible, if you know how | Default |
| Registry check before rollout | Rarely | Always |
| Restart without rebuild | Via kubectl rollout | One click |
| Database with role and default privileges | By hand, often forgotten | Built in |
| Wildcard certificate via DNS-01 | Configure cert-manager, issuer and Reflector | Register, done |
| Tenant onboarding with rollback | Script, usually without rollback | Pipeline with compensations |
| Offboarding with backup | If someone builds it | Aborts without a backup |
| Volumes with snapshot before deletion | Rarely | Built in |
| Alerts only on transitions | Tune Alertmanager | Built in, with all-clear |
| Audit log of every change | Git log, if everything is in Git | Every action with the person behind it |
| Multi-cloud | Yes | No, Scaleway only |
| Any Kubernetes objects | Yes | Only what Clusterward renders |
| Earlier version in one click | If someone knows the old tag | Yes, exact image by digest |
| Database backup with restore | Script, rarely tested | Yes, alongside the running database |
| Configuration export | Spread across repos and wikis | JSON file, without secrets |
For some teams, DIY remains the right choice. Here are three cases where we say so in the demo, too.
Operators, service meshes, custom CRDs, objects Clusterward doesn’t render: DIY can do everything, Clusterward only what it knows. You can run both on the same cluster, but then you maintain two approaches.
Clusterward is built on Scaleway and will stay that way. If you need AWS, Hetzner or on-premises, you won’t find an abstraction layer here.
A team of two to three people who enjoy running Kubernetes and have the time for it doesn’t need a control plane. For them, DIY isn’t a risk, it’s their craft.
Import the kubeconfig; at first, Clusterward only reads and detects existing add-ons.
The same Dockerfile as a build, variables into the editor, rollout alongside the old chart.
Import or adopt the database, switch the host, and the certificate is issued automatically.
Once the last application has moved; the Terraform stays as documentation.
How a cluster is created secure by default is covered under Cluster provisioning; the rules for databases that DIY setups usually lack are under Managed databases.
The comparison with a commercial product is under Clusterward vs. Qovery. If you work with scripts today, you’ll also find the migration path under Migration.
Pricing, clusters, users and data sovereignty compared.
Go to Clusterward vs. QoveryKapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningRoles, mandatory 2FA, audit log and IP allowlist.
Go to Security & accessNot necessarily. Terraform created your cluster; Clusterward connects it via kubeconfig and takes over operations on it: deployments, databases, domains, onboarding, alerts. The Terraform stays, as documentation or for the next cluster. What gets replaced is the part that creates work every day.
Can’t find your question? Write to us – we usually reply on the same business day.
Ask a questionBring your Terraform, your charts and your wiki. We’ll show you what Clusterward can take over, and tell you honestly where you should stick with DIY.
