Clusterward is SaaS, but not a shared data pool. Every customer gets a workspace with its own database, its own data key, its own backup bucket and its own address. Your clusters and data stay in your Scaleway project.
A workspace is your own, separated part of the Clusterward control plane within the service operated by BitKollegen. It has its own control plane database; its own data key, which encrypts all your credentials; its own bucket for database dumps and bucket archives; and its own address under clusterward.app with a certificate. The workspace is identified by its hostname before any sign-in takes place; an IP allowlist can shield it further. Users, roles, channels, clusters, pipelines: everything belongs to your workspace alone.
We look at your applications and your Scaleway setup.
Database, key, bucket and address are created, and your first administrator receives an invitation by email.
You store your Scaleway project’s IAM key, verified and encrypted.
Connect an existing cluster or create a new one, secure by default.
Invite users, assign roles, set the allowlist and alert channels.
The kind of separation you normally only get from a control plane by running it yourself.
No tables shared with other customers. Your clusters, services, pipelines and logs live in a database that only your workspace knows about.
Credentials, kubeconfigs and variables are encrypted with a data key belonging to your workspace. Another workspace cannot decrypt them, not even with access to the database.
Database dumps and bucket archives from offboardings end up in a bucket that belongs only to your workspace, with your retention rule.
Your workspace responds under its own subdomain with its own certificate. The hostname determines which workspace is addressed, even before sign-in.
Restrict access to your office and VPN addresses. The check recognizes Cloudflare addresses and rejects spoofed headers; locking out your own address is prevented.
Clusters, databases, buckets and the registry are created in your Scaleway project with your IAM key. You see everything in the Scaleway console and pay for it directly to Scaleway.
A directory knows the workspaces and their databases; each workspace is identified by its hostname.
AES-256-GCM per workspace, with the data key itself protected by the platform key.
Multiple instances serve all workspaces; each piece of work is claimed in the workspace’s database, never twice.
An update brings every workspace database up to date, and failures stay isolated.
An honest limit: the service itself runs as shared processes. Everything that holds data is separated.
| Layer | Per workspace | Shared |
|---|---|---|
| Control plane database | Dedicated | Nothing shared |
| Data key | Dedicated, wrapped | Platform root key |
| Backup bucket | Dedicated | Nothing shared |
| Address and certificate | Dedicated subdomain | Base domain clusterward.app |
| Emails | Your domain in sender, subject and footer | Sent through the platform’s mail server |
| Users, roles, channels, audit log | Dedicated | Nothing shared |
| Clusters, databases, buckets | Your Scaleway project | Nothing shared |
| Service processes and updates | None of its own | Operated by BitKollegen |
How roles, mandatory 2FA and the audit log work within the workspace is explained under Security & access. Where the data lives and why operating in the EU is a deliberate decision, under Digital sovereignty.
The first cluster in the workspace is created via Cluster provisioning or by connecting an existing cluster, as described in Getting started.
Roles, mandatory 2FA, audit log and IP allowlist.
Go to Security & accessClusters, databases and buckets in EU data centers.
Go to Digital sovereigntyKapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionIn the demo, we show you a workspace from the inside: separation, roles, allowlist and the path your data takes.
