Your cluster stays, your repositories stay, your domains stay. Clusterward connects the existing cluster, takes over one application at a time and imports databases and buckets with a pause instead of an outage. For a tenth of the price.
Qovery and Clusterward do similar things: they roll out applications from Git to Kubernetes and manage databases, domains and environments. The difference lies in price, cloud and data ownership. So a migration does not mean rebuilding, it means taking over: the Kapsule cluster is registered via kubeconfig, each application is created as a service with a build, environment variables are copied, the database is imported into a private managed instance by a job, buckets are copied and DNS is switched over. One application at a time, with Qovery as a fallback, until the last one has moved.
Import the kubeconfig, verified and encrypted. Or create a new cluster with private nodes.
Repository, branch, Dockerfile: the same build as on Qovery, built with Kaniko or GitHub Actions.
Environment variables go into the encrypted editor; multi-line values stay intact.
A job copies schema and data into a private managed instance; the application is paused in the meantime.
Objects from the old bucket into a dedicated one with its own key, repeatable.
Add the host to the service, the record and certificate are created, then DNS points to the new ingress.
Every step is a cockpit feature, not a one-off migration script.
A Kapsule cluster is registered via its kubeconfig; the token is verified before it is stored. Clusterward installs nothing without asking; you view add-ons and update them deliberately.
The import runs as a job in the cluster, checks the source, scales the application down to zero instances, copies, and starts it again. A non-empty target asks for confirmation instead of overwriting.
Objects are copied from any reachable S3 bucket, with progress display and cancellation. Copy and overwrite, never delete; a second run is idempotent.
As long as DNS points to Qovery, everything keeps running there. You switch over host by host and can go back until you cancel Qovery. If the records already sit in a Cloudflare zone, Clusterward adopts them and switches them itself at go-live instead of creating second ones.
Register Cloudflare zones, records are created automatically, certificates per host or as a wildcard. A host behind the Cloudflare proxy is detected.
According to its price list, Qovery Business costs $2,999 per month for three clusters and twenty users. Clusterward Team costs €299 for ten clusters and unlimited users.
The same cluster, the same namespaces, server-side apply instead of Terraform.
The same build, built by Kaniko in the cluster or by GitHub Actions.
External charts go into the template library and are pinned to a version.
Nothing is moved, only reconnected.
The model is familiar. The terms differ in only a few places.
| Qovery | Clusterward | Difference |
|---|---|---|
| Organization / Project | Workspace / application | The workspace has its own database and key |
| Environment | Environment | A namespace on exactly one cluster |
| Application | Service with a build | Build and image belong to the application, not to the service |
| Managed Database | Managed database | Scaleway instance, private only, one database per service |
| Custom Domain | Domain on the service | Record created automatically, TLS per domain or wildcard |
| Lifecycle Job | Pipeline building block | Onboarding per customer instead of per deployment |
| Secret | Secret on the service | Write-only, optionally in Scaleway Secret Manager |
| Advanced Settings | Networking card | Timeouts, rate limits, CORS, basic auth, with a default per field |
| API token | API token | With role, scope and expiry date |
| Terraform Export | No export needed | Objects live in your cluster and project |
Read the full comparison, with tables and the areas where Qovery is stronger, under Clusterward vs. Qovery. How the database import works in detail is described under Managed databases.
An existing cluster is all you need for the first step; the Getting started guide takes you from the workspace to the first deployment. The plans are listed under Pricing.
Pricing, clusters, users and data sovereignty compared.
Go to Clusterward vs. QoveryGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsPostgres and MySQL connected privately, one database per service.
Go to Managed databasesCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionBring your Qovery setup. We connect your cluster and move the first application together.
