Signup for Kupe Cloud is open. There is no invite code, no card and no charge during alpha.
Alpha is where we find out whether Kupe does what we built it to do: give a team a cluster with GitOps, secrets, metrics, logs and alerting already wired, so they can get on with shipping. We kept it closed for the first two months. The core paths went to a small group of people who already run Kubernetes for a living, because they notice when something is off and can say why. We spent the same two months trying to break the platform ourselves, on production, after every change.
This post is about what that found, and what changed before we opened signup.
We became the first tenant
The end-to-end suite has sixteen phases and a full run takes just under forty minutes. It goes through the public signup service rather than an admin shortcut, creates the cluster through the public API and deploys through Argo CD inside that cluster. Only the residue sweep afterwards runs with admin access, because somebody has to check the cupboard after the party. Everything on the customer path runs as a customer would.
We ran three load profiles alongside it: steady traffic at a small demo app, a workload that outgrows its cluster, and concurrent tenant onboarding through the real signup route. The traffic run handled 298,708 requests over fifteen minutes, with a p95 of 140 ms and no failed requests through the external gateway and TLS. That result came from a tiny demo app on the smallest cluster size. It says the path holds under that test; it does not predict your application's latency.
The cluster-growth tests answered a different question: does the platform add capacity while the workload is still asking for it? In one run, the HPA moved from two to thirteen replicas and the platform added a node under load. A separate scale-out run onboarded two tenants concurrently and left no residue. These are small runs on purpose. They gave us enough surface area to find the awkward parts before asking strangers to do it for us.
The things that broke were useful
Closed alpha earned its keep here. A routine operating-system update brought one node back without networking because a component of the cluster network could not start on the updated kernel. Our reboot tooling could not run on that node either, so it retained the cluster-wide reboot lock.
The first fix looked sensible and changed nothing. It turned off in-place updates on the nodes our provisioning tooling manages, and the workers that needed it are created by the autoscaler, which that tooling never touches. We stopped patching nodes in place. Nodes are now replaced from validated images instead. A follow-up audit found an image-rebuild job that had been reporting success while building nothing. Green is a poor signal when the successful path is to skip every input.
Capacity is the other ordinary failure. Our infrastructure provider does not always have a server available when the autoscaler asks for one. The autoscaler now tries the next size up, alerting includes the pool and the reason, and there is a runbook for the operator who gets the alert. With an empty pool, the first cluster waits for a node to arrive.
A few failures only appear when two tenants do the same thing at once. Two clusters with the same name collided on a host-side role name. A concurrent teardown could also lose the record that told the platform to purge a tenant's data. The scale-out driver found both, and deletion now runs through the same endpoints customers use. You can read the public deletion documentation before trying it yourself.
Alerting needed the same scrutiny. Six chronic alerts were re-posting the same unactionable backlog every four hours. They were responsible for most of the noise, rather than the resource alerts we initially suspected. Fixing that reduced alert volume by 92%. Backlog work and incidents now travel through separate alert paths; an alert in the incident channel should be worth somebody's sleep.
We also made isolation a routine assertion instead of a promise in an architecture diagram. Every end-to-end run creates a second real tenant and checks API access, metrics, logs, dashboards, GitOps destinations, host RBAC and the network boundary. The test that proves one tenant cannot read another's metrics runs before each change ships.
What changed in the platform
The image pipeline builds on a cadence, validates the result, canaries a node, then rolls control planes before core nodes. Promotion runs through a staging estate with full end-to-end and load tests before production. That architecture exists to keep an update from becoming a cluster-wide leap of faith. A cluster without high availability can still see a brief API interruption while a node is replaced; choose HA when you create the cluster if that interruption is not acceptable. The high-availability documentation explains that choice.
Signup is open with one tenant per account for now, plus a cap on total tenants that we raise as we go. The point is containment: an ordinary bad day should stay small. Tenant and account deletion are self-service from the console or CLI, and the suite checks for residue after every deletion.
Releases are built, signed and pinned by digest before they are versioned. The cluster will not run an unsigned image, and baseline policies are enforced. The property that matters is that an untrusted image never becomes a running workload.
What is still rough
Alpha is still alpha. Dedicated nodes and backup tooling do not exist yet, there is no SLA, and maintenance can interrupt a single-replica cluster. The alpha service notice has the current limits and the parts of the service that remain experimental.
Start with the first fifteen minutes
Create an account, create a cluster and deploy something small. It takes no invite code and nothing to pay. Then tell us where the path felt heavier than you expected, especially in the first fifteen minutes: a label you expected to find, a default you expected to be set, or a step that made you stop and ask why it existed. That is exactly the feedback alpha is for. Send it to support@kupe.cloud, and check status.kupe.cloud before treating an odd result as your fault.
Top comments (0)