Kupe Cloud is in alpha: Kubernetes, without the assembly

You can get a Kubernetes cluster from plenty of places. What still takes work is everything that turns that cluster into a platform someone can actually use: how apps get deployed, how traffic gets in, where secrets live, what gets monitored, which alerts exist before anything breaks, and how a team gets from sign-up to a working kubectl context without a half-day of assembly. That is the layer we kept rebuilding, so we built it once as a product. Kupe Cloud is now in alpha.

This is a slightly unusual post for the Core blog because it is about our own product. Better to say that plainly: Kupe Cloud is built and operated by Core Solutions. The audience is still the same one the rest of this blog writes for though: platform and lead engineers who already know the difference between “a cluster exists” and “the platform is usable”.

The familiar moment is not cluster creation

The recognisable part of platform work is rarely the command that creates the cluster. It is everything that arrives straight after.

A fresh cluster immediately turns into a queue of practical questions:

• how do workloads get deployed, and by what GitOps path
• how does ingress work, and which defaults are already in place
• where do secrets come from, and how do they land in workloads
• what do teams get for logs, metrics, dashboards, and alerting on day one
• which access patterns are supported, and how quickly can somebody start using them

None of that is a side quest. It is the work that decides whether Kubernetes feels like a good foundation or an expensive hobby.

That is also why the argument in Nobody warns you about year two of platform engineering keeps coming back. Launching the infrastructure is only the start. The real bill is in the repeated assembly and the repeated maintenance of the same surrounding layer.

The two usual escape routes are both imperfect

Most teams trying to get a sensible application platform around Kubernetes drift toward one of two answers.

The first is to build everything yourself on raw Kubernetes. You keep the model. You keep the flexibility. You can use the APIs, tools, and workflow shapes your team already understands. You also take on a surprising amount of platform work before anybody ships anything useful.

The second is to adopt a higher-level developer platform that gets people moving quickly by hiding more of the underlying system. That can be a very good trade at the start. The trouble shows up later, when the product grows up and the abstraction starts deciding too much on your behalf. Networking gets awkward. Background jobs stop fitting neatly. Observability is limited to the slice the product chose to expose. Security posture has to fit somebody else’s opinionated path. You moved faster, then discovered you were borrowing against a future migration.

That trade-off is the backbone of Why Are We Building Kupe Cloud?: reduce the platform work, but do not solve it by taking control away from the team that eventually has to operate the result.

It also sits squarely with the rest of the line we have been holding on this blog: stop copying big-tech platform architecture, but also stop pretending that a bare cluster is the whole answer. You need less machinery than a hyperscaler. You still need more than a Kubernetes API endpoint.

So we built the layer we kept assembling

Kupe Cloud is our attempt to hold that middle line.

The design principle is simple to describe and easy to get wrong: stay as close to native Kubernetes as possible, while managing the platform work that most teams do not want to rebuild for the tenth time. The goal is to give you a working platform shape earlier, without cutting you off from the real model underneath it. Hiding Kubernetes behind a toy control panel would do the opposite.

In practice, that means your existing workflows still make sense. kubectl still works. Helm still works. Terraform and OpenTofu still work. GitOps still works. If you already know how to operate Kubernetes, the platform should feel like it removed assembly, not agency. That is the same distinction behind what good developer experience looks like in Kubernetes: the answer is to make people need less pointless platform work before they can ship, while the model stays visible to anyone who wants it.

What is actually wired in on day one

A new Kupe Cloud cluster arrives with a real platform spine already in place:

• GitOps is pre-wired. A cluster created from the console, the CLI, or the Terraform/OpenTofu provider registers itself with Argo CD before you arrive. You point Argo CD at your repo and choose the cluster; you do not spend the first session wiring a GitOps control plane together by hand.
• Secrets land as ordinary Kubernetes Secret objects. Kupe Cloud stores them in OpenBao and syncs them into the cluster in a shape workloads already understand, which is the same reason we like the External Secrets Operator pattern: fewer bespoke client assumptions, fewer special cases in application code.
• Observability is there from the first minute. The stack behind that is Mimir, Loki, Alloy, Grafana, and Alertmanager. Metrics and logs start ingesting as soon as the cluster exists, and the default dashboards and alerts cover the sort of early failure modes that otherwise wait until the least convenient hour.
• The console is a Kubernetes console, not six friendly tiles. It is built on Headlamp with our own plugins layered on top, so you can drill into workloads, inspect pods, tail logs, and use the platform-specific views without being fenced off from the cluster.
• There is a published provider. The kupecloud/kupe provider is live on both the Terraform Registry and the OpenTofu Registry. The important caveat is the honest one: it covers the core resources and workflows today, not every corner of the platform.
• There is a working docs path and a CLI path. The docs at docs.kupe.cloud walk through a first cluster, and the kupe cluster ... CLI path gets you to a usable kubectl context rather than a login screen and a shrug.

That is the bar we wanted for ourselves when we kept doing this work by hand: enough of the platform is already in place that you can get on with the thing you meant to run.

The target is fifteen minutes, and alpha is how we test it

One bar we have set ourselves is straightforward: from zero to a running cluster with healthy workloads, monitoring, and alerting in about fifteen minutes, regardless of prior Kubernetes experience.

That is a target, not a guarantee and not an SLA. Alpha is where you find out whether the clean path you designed is the one real people actually take. Sometimes the gap is small. Sometimes a new pair of eyes finds the awkward bit straight away.

That is why this is an alpha at all. We want people to break the flow, tell us where the defaults are thin, and point at the places where too much platform work still shows through.

The gaps stay in the post, because they are part of the product

The capability list only matters if we are just as plain about what is missing.

Today, Kupe Cloud still has real alpha constraints:

• No dedicated nodes yet. Clusters share host infrastructure, which is fine for testing and a fair number of real workloads, but it is not the right answer if you need hard isolation or reserved capacity.
• Backup responsibility inside the cluster is still yours. We back up the platform services we operate, but workload backup and recovery inside your cluster is still something you need to own today.
• The docs are still catching up with the engineering. The main path is there; the long tail is not complete yet.

The fuller version of that contract lives in the Alpha Service Notice, and the more product-shaped walkthrough is in Kupe Cloud Is in Alpha. Both matter because “alpha” should describe how the product works today, not just give cover for rough edges.

If you want to try it

Kupe Cloud is free during alpha. There is no card, no charge, and nothing to cancel while we are still fixing the shape of the product.

If you want access, use the invite code B54W-WPHX when you sign up at kupe.cloud/signup. We will keep that code open for a limited window during the alpha. If it has expired by the time you read this, or it simply does not work, contact us or email support@kupe.cloud and we will sort an invite out.

Kupe Cloud is still in alpha, and we want direct feedback from engineers using it in real work. If you try it, tell us what holds up, what gets in the way, and what would make it a better Kubernetes platform for real teams.