Clusterward runs as SaaS. There’s nothing to install – all you need is a Scaleway project, an IAM key and a repository with a Dockerfile. This guide takes you from the demo appointment to your first application with a database, domain and alert channel.
Everything Clusterward creates is created in your own Scaleway project. So create a project in advance that belongs to Clusterward alone, and generate an IAM key in it. You won’t need a domain until step five, or a repository with a Dockerfile until step four. With a provisioned cluster, the whole process takes about thirty minutes, most of which is spent waiting for Scaleway.
A dedicated project for Clusterward, so that costs and permissions are cleanly separated.
With the permissions from the table below; “Test” checks them before saving.
Or a ready-made image in a registry, or a Helm chart.
At Cloudflare, if you want records to be created automatically; otherwise you create the record yourself.
In the demo, we look at your use case: which applications, how many customers, which databases. Then we set up your workspace: its own control plane database, its own data key, its own backup bucket and your address under clusterward.app. Your first administrator receives an email invitation, sets their own password and sets up mandatory 2FA with an authenticator app on first sign-in. A checklist with the next steps is then waiting on the dashboard.
Thirty minutes, live on your use case, with your questions about operations and pricing.
Address, invitation for the first administrator, a thirty-day trial with two clusters.
On first sign-in, with any TOTP app; without a second factor, there’s no access.
Under Infrastructure → Provisioning, you create a provisioning profile: name, project ID and the project’s IAM key. Clusterward checks the key against Scaleway immediately, every permission on its own, refuses it when a required permission is missing, stores it encrypted and never displays it again. “Test” reports per product what the key is allowed to do and fetches the project name from the console. During setup, the cockpit guides you through the IAM application and permission sets and checks each set individually. If a permission is missing, you see it here – not halfway through provisioning.
In the Scaleway console under IAM, with the policies from the table below, for this project only.
Copy the access key and secret key; Scaleway shows the secret only once.
The cockpit shows the permissions per product; Private Networks is a separate set.
The wizard under Clusters → Provision asks for the profile, region, node type, number of nodes and the address range allowed to reach the Kubernetes API; “Add my IP” enters your current address. Clusterward creates the Private Network, Public Gateway, cluster and node pool, installs ingress-nginx with proxy protocol, cert-manager, metrics-server and Reflector, creates a private registry and swaps the admin token for a restricted identity. The tracker shows every step with its duration. If you already have a Kapsule cluster, import its kubeconfig instead.
Region Paris or Amsterdam, node type, count, API address range. Proxy protocol is preset.
Paste the kubeconfig; the token is verified with a read request and stored encrypted.
The cluster page shows nodes, pods, utilization, add-ons with their versions and the load balancer.
Under Applications, you create a project and a build for it: repository, branch, path to the Dockerfile, image name and tag, and the build source – Kaniko in the cluster or GitHub Actions. For a private repository, you store an access token, encrypted and write-only. Then an environment on the cluster, such as “production”, and in it a service of type Application that points to the build. Environment variables go into the encrypted editor or come from a template.
Branch, Dockerfile, image name; the name is derived once from the application name and stays fixed.
An environment is a namespace on exactly one cluster; the service gets a port, resources and scaling.
In the editor or via a template; multi-line values such as keys stay intact.
If the application needs a database, first provision a managed instance on the cluster page – PostgreSQL or MySQL, with a private endpoint only. On the service page, “Create database” then creates the database, role and password in one step, already assigned; you copy the connection details into the variables. For the domain, enter the host on the Domains card: if it’s in a registered Cloudflare zone, the record is created automatically; otherwise you create it yourself. The TLS strategy stays on “auto”.
Choose the engine, name and the cluster’s network; the instance never has a public endpoint.
Name derived from the domain, password generated, connection details ready to copy.
Register the Cloudflare zone under DNS first; then the record is created on its own.
“Deploy” starts the build and rollout in the background; the deployment row shows build, registry check, rollout and health check. As soon as the pods are ready and the certificate is issued, the host responds. The Instances card shows pods with utilization and logs. Finally, under System → Notifications, you create a Slack, Teams or email channel and subscribe to failed deployments, unhealthy pods and expiring certificates.
Immediate response, progress in the deployment row; you can cancel while the build is running.
Certificate via Let’s Encrypt within minutes; behind the Cloudflare proxy, immediately.
“Send test” checks delivery; alerts arrive once per event, with an all-clear.
The profile’s IAM application needs these policies. The first seven are required and apply to the one project, the rest are optional; you grant ProjectReadOnly and IAMManager at the organization level. “Test” in the cockpit shows per product whether the key is sufficient. Two pitfalls from real-world operations: VPC does not cover Private Networks, and without Observability the dashboard shows no database metrics. For Object Storage and Secret Manager, better enter keys of their own.
| Product | Policy | Used for |
|---|---|---|
| Kubernetes | KubernetesFullAccess | Clusters, node pools, API access list |
| VPC | VPCFullAccess | The VPC the private network lives in |
| Private Networks | PrivateNetworksFullAccess | Separate set, not included in VPC |
| Public Gateway | VPCGatewayFullAccess | Outbound access for nodes without a public IP |
| IPAM | IPAMFullAccess | Addresses on the private network for nodes and databases |
| Managed Databases | RelationalDatabasesFullAccess | Instances, databases, users, backups |
| Container Registry | ContainerRegistryFullAccess | Registry for your images, pulled by the nodes |
| Block Storage | BlockStorageFullAccess | Optional: volume snapshots and restores |
| Observability | ObservabilityFullAccess | Optional: database metrics on the dashboard |
| Secret Manager | SecretManagerFullAccess | Optional: only if the key also serves a secret store |
| Project | ProjectReadOnly | Optional, organization: project name in the cockpit |
| IAM | IAMManager | Optional, organization: a registry-only push key per cluster |
The wizard creates the network, gateway, cluster and pool secure by default: nodes without public IPs, API access only from your address range, base components in tested versions. Every resource is tagged with the cluster ID, an aborted run can be retried, and teardown removes exactly what was created.
Go to Cluster provisioningAn existing Kapsule cluster is registered via its kubeconfig. Clusterward verifies the token, stores it encrypted and initially only reads. The setup card detects add-ons that are already running, along with their versions; you mint the restricted operator identity with one click. Teardown stays locked for connected clusters.
Migrating existing setupsWith the first service, the framework is in place. More environments such as staging are set up in minutes, colleagues get roles scoped to applications, and if you roll out the same stack for many customers, you describe it once as a tenant pipeline.
Persistent files belong on volumes with snapshots, and later you maintain the Kubernetes version and add-ons via cluster updates. Terms that were new in this guide are explained in the glossary.
Once the first application is running: Logs & monitoring shows logs, utilization and uptime checks.
A ready-made application to try out: WordPress from the app catalog.
Can’t find your question? Write to us – we usually reply on the same business day.
Ask a questionIn the demo, we go through these six steps on your Scaleway project and set up your workspace right away.
