Clusterward builds your image, verifies it in the registry and rolls it out with a health check on your Kapsule cluster. Environment variables are stored encrypted in the cockpit, and a restart activates them without a new build.
A deployment in Clusterward is the rollout of a service to an environment on one of your Scaleway Kapsule clusters. A service is either an application from Git (Clusterward builds the image from your repository), a ready-made container image from your registry or a Helm chart from the template library. From the service, Clusterward generates the Deployment, the Kubernetes Service, an ingress with TLS, the autoscaler and the secret holding the environment variables, and writes them to the cluster via server-side apply. Deployments run in the background, and their progress is visible in the cockpit at any time.
Branch, Dockerfile and image name belong to the application’s build, not to the service.
Kaniko builds in the cluster and pushes to the cluster’s registry with a key that may only use the registry, or a GitHub Actions workflow takes over the build.
Before the rollout, Clusterward asks the registry whether the tag really exists.
Deployment, Service, ingress, secret and autoscaler are created or updated.
Only once the pods are ready is the rollout considered successful.
Everything a team otherwise maintains in its own pipelines, manifests and scripts is built into the cockpit.
From Git, a registry or a chart – always exactly the image you mean.
A service references a build of the application: branch, Dockerfile, image name and tag. Private repositories are cloned with a token stored encrypted.
Ready-made images from the registry or Helm charts from the central template library with a pinned version. Charts are versioned internally, without a Git connection.
GitHub Actions or any script triggers deploy and restart via bearer token and polls the status. The token carries a role, an application scope and an expiry date.
Before the rollout, Clusterward asks the registry what the tag currently points to and rolls out exactly that image by digest. New builds additionally get a fixed tag sha-<Commit>.
Change values without rebuilding, and without anyone reading them back.
Values are stored AES-encrypted in the cockpit and mounted as a Kubernetes Secret on deployment. Multi-line values such as PEM keys stay intact.
Secrets can no longer be read once saved; Helm charts get passwords as ${secret.NAME}. Rotations from Secret Manager restart the service on request.
You activate changed variables with a restart: Clusterward applies the current image with the new configuration, without building the image again.
Timeouts, retries, rate limits, CORS and basic auth for ingress-nginx or Envoy Gateway, each shown next to the controller’s default value.
See what is running, and go straight to the cause when something fails.
CPU and memory requests with optional limits, a fixed replica count or a HorizontalPodAutoscaler with a CPU target between minimum and maximum.
The service page shows the running pods with their utilization, the log of each pod and the history of all deployments with error text. The log viewer merges all instances by time, searches, filters errors and shows the previous run of a crashed container.
If a rollout fails, the link in the activity feed and in the notification leads straight to the logs – for a crash, to the previous run, where the cause is.
Bring back an earlier version without losing configuration or data.
“Restore this version…” in the deploy history rolls out exactly the image of an earlier healthy version – for Helm, the chart version and values. Configuration and data stay as they are.
A restart applies the current configuration to the image that is currently running and never undoes a restore. Deploy fetches the newest image.
The disks a chart creates are listed on the Helm service: with scheduled snapshots and restore.
Image builds run as a job in the cluster, without a Docker daemon and without a build server.
Alternatively, Clusterward starts a workflow_dispatch and waits for the result.
Objects are written declaratively; conflicts stay visible instead of being overwritten.
Helm services are installed and upgraded with the bundled Helm CLI.
A service’s source only determines where the image comes from. Ingress, TLS, secret and rollout are the same for all of them.
| Attribute | Git | Container | Helm |
|---|---|---|---|
| Source | Repository and Dockerfile | Image from the registry | Chart from the template library |
| Build | Kaniko or GitHub Actions | None | None |
| Image tag | From the build | Pinned on the service | From the chart |
| Environment variables | Encrypted secret | Encrypted secret | Values of the chart version |
| Restart without rebuild | Yes | Yes | Via upgrade |
| Autoscaling | Fixed or HPA | Fixed or HPA | As defined by the chart |
A deployment needs a cluster, a database and a hostname. Clusterward creates the cluster secure by default during Cluster provisioning, the database is created with one click on the service page via Managed databases, and the host gets its record and certificate via DNS & certificates.
If you roll out the same stack for many customers, you describe it once as a pipeline. The Tenant pipelines page shows how that works. All features are included in every plan; billing is by cluster only, see Pricing.
How to get back databases, volumes and earlier versions is shown in Backups & recovery.
Logs of all instances, utilization over 30 days and uptime checks on the service are described in Logs & monitoring.
Kapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningPostgres and MySQL connected privately, one database per service.
Go to Managed databasesCloudflare zones, automatic records, managed wildcard certificates.
Go to DNS & certificatesCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionIn the demo, we roll out an application from your repository to a Kapsule cluster together, including domain, certificate and database.
