Clusterward creates your Scaleway Kapsule cluster with a private network, a gateway and locked-down API access, installs the ingress controller and cert-manager, and shows every step with its duration in the cockpit.
Cluster provisioning is the wizard Clusterward uses to create a Kapsule cluster, network included, in your Scaleway project. You choose a provisioning profile (the project’s IAM key), a region, the node type and the CIDR range that may reach the Kubernetes API. From that, Clusterward creates a Private Network, a Public Gateway with masquerade, the cluster with Cilium and a node pool without public IPs, fetches the kubeconfig, replaces the admin token with a dedicated, restricted identity and installs the base components. Every resource created is tagged with the cluster ID, so that a rerun picks it up and a teardown removes exactly those resources.
A provisioning profile is the verified IAM key of a Scaleway project.
The Private Network and the Public Gateway with masquerade come first.
Kapsule with Cilium, bound to the private network, API ACL set.
Node pool of the chosen type with public IPs disabled.
Kubeconfig fetched, restricted identity minted, admin token discarded.
Ingress controller, cert-manager, Reflector and a private registry namespace.
The decisions that otherwise live in a Terraform module or a runbook are defaults here.
One profile per Scaleway project: the IAM key is verified before saving, stored encrypted and never displayed again. “Test” shows the permissions per product.
Nodes without public IPs, the Kubernetes API only from your CIDR, outbound traffic via the gateway. None of it needs to be hardened after the fact.
Every resource carries the cluster ID as a tag. A restart picks up existing parts; the teardown deletes exactly what was created and nothing else.
Nodes, pods, capacity and utilization from metrics-server, problematic pods after a grace period, load balancers with their Scaleway mapping.
A ServiceAccount with a ClusterRole that may manage workloads but cannot write cluster RBAC or CRDs. Rotatable and revocable from the cockpit.
On creation, a private Container Registry namespace is created in the cluster’s project, because pull permissions follow the project. A push key that may only use this registry is created as well: builds in the cluster push with it and never hold the profile’s key.
When you create a profile, the cockpit guides you through the IAM application and permission sets, with a copy button. On saving, every set is checked; a missing one is named before anything is saved.
A help article explains what Clusterward creates and reads with the key, how it is stored encrypted and how you rotate or revoke it.
The API access card shows which addresses can reach the Kubernetes API and lets you allow your own with one click – without the Scaleway console.
ingress-nginx or Envoy Gateway, with the proxy protocol for real client addresses.
Let’s Encrypt issuers for HTTP-01 and DNS-01, ready for wildcards.
Mirrors wildcard secrets into every namespace automatically.
Kapsule’s CNI, the foundation for the optional NetworkPolicies.
Every resource is created in your Scaleway project and remains your property. Clusterward only holds the IDs.
| Resource | Setting | Why |
|---|---|---|
| Private Network | Dedicated network per cluster | Databases and nodes talk privately |
| Public Gateway | Masquerade active | Outbound traffic without public node IPs |
| Kapsule cluster | Cilium, API ACL restricted to your CIDR | NetworkPolicies and a locked-down API |
| Node pool | public_ip_disabled | No attack surface from outside |
| Registry namespace | Private, named after the cluster | Pull permissions follow the project |
| Operator identity | ServiceAccount + ClusterRole | No admin token in circulation |
Once the cluster is up, you roll out applications via Deployments. A private managed database attaches to the same network in one click, as described under Managed databases.
You maintain the Kubernetes version, node pools and add-ons later without the console via Cluster updates. What the first cluster looks like in practice is shown in the Getting started guide. Node capacity for a specific purpose that comes and goes is created by pool claims.
Kubernetes version, node pools and add-ons from the cockpit.
Go to Cluster updatesRoles, mandatory 2FA, audit log and IP allowlist.
Go to Security & accessGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsAn IAM key of the target project with full access to Kubernetes, VPC, Private Networks, Public Gateways, IPAM, Managed Databases and Container Registry. On Scaleway, Private Networks is a separate permission set; VPC alone is not enough. Optionally add Block Storage for volume snapshots, Observability for database metrics and IAM Manager for the registry push key. “Test” shows per product what the key is allowed to do. On saving, the cockpit checks every set individually and names a missing one before anything is saved.
Can’t find your question? Write to us – we usually reply on the same business day.
Ask a questionTogether, we create a Kapsule cluster in your Scaleway project and roll out the first application on it.
