We are building Kupe Cloud because a Kubernetes cluster is only the start. It gives you the API, the scheduling model, and access to a huge ecosystem. That is valuable. It is also only the first piece of the puzzle.
The next questions arrive quickly. How do applications get deployed? How does traffic get in? Where do logs go? What metrics are collected? What and how should it alert? How do teams manage access? What does the production environment look like?
Those are not side quests. They are the work that makes Kubernetes usable.
The tradeoff we kept seeing
Teams usually end up choosing between two imperfect paths.
One path is to jump straight to Kubernetes and build the surrounding platform themselves. That gives a lot of freedom. You can use Helm, controllers, operators, GitOps, custom metrics, your own routing choices, and the wider Kubernetes ecosystem.
It also means taking on a surprising amount of work before you get to the thing you actually wanted to ship.
The other path is to use a developer platform that hides most of the underlying model. That can be great early on. Push an app, get a URL, ship fast. There is a reason people like that developer flow.
The trouble is what happens when the product grows up a bit. Suddenly you need more control over networking, observability, background jobs, security posture, release flow, or integration with the rest of your infrastructure. The simplicity that helped at the start can become the thing you are trying to escape.
That is where Kupe comes in, we want to empower users with the power of Kubernetes and the simplicity of a developer platform.
The default journey is backwards
For a lot of teams, the path into Kubernetes follows a familiar pattern.
By the time a team needs the flexibility of Kubernetes, they often have to absorb a large amount of platform work all at once. They are no longer just adopting Kubernetes. They are suddenly assembling delivery workflows, observability, alerting, access patterns, cluster operations, and production defaults.
Kupe Cloud short-circuits that journey.
We give teams a cleaner starting point from day one: fast setup, strong foundations, and a platform that can grow with them instead of boxing them in.
The shape we want
The idea is not to make Kubernetes disappear. That’s not the right goal.
The goal is to make the first serious step into Kubernetes much less expensive. A team should be able to get a useful environment quickly, with everything they need already in place. They should not have to assemble the same basic platform every time, even with all of the best practices in place, there’s still a lot of plates to spin!
Users should the full Kubernetes ecosystem available to them. kubectl, Helm, Terraform/OpenTofu should all work. Teams should be able to bring their own charts, their own deployment patterns, their own metrics, dashboards, and alerts.
That is the line we are trying to hold: reduce the platform work, not the user’s options.
What you get from day one
Kupe Cloud is not just a cluster endpoint. It is the platform around the cluster.
Argo CD is available for GitOps workflows from the start. Logs are sent automatically to a centralised logging stack. Metrics are collected into a central metrics platform, with default metrics scraped out of the box and custom metrics able to be added as needed. Dashboards, monitoring, and alerting are part of the starting point rather than a second project.
We also include sensible production-ready defaults that are based on years of running Kubernetes in real environments. Default alerting is deployed to every cluster and ready to go for the common issues teams actually need to know about: crashing pods, pending workloads, storage pressure, and other operational signals that matter early. Those defaults can be enabled with minimal effort, and teams retain the ability to extend them as needed.
The same philosophy runs through the rest of the platform. The cluster foundation, supporting tools, node lifecycle, and operational components are managed by our platform team so users do not have to assemble and operate those layers themselves.
Built to be open, not limiting
The point of Kupe Cloud is not to reduce what teams can do. It is to reduce how much undifferentiated platform work they need to do before they get real value.
Many platforms feel simple only because they narrow the model. Kupe Cloud is designed to feel simple because the foundations are already in place. As your needs grow, you can build on top of that foundation with the same patterns you would use on any major Kubernetes platform: your own charts, automation, custom metrics, dashboards, alerts and so on.
That is the core idea behind Kupe Cloud. You get the platform, Kubernetes, the tools, the configuration, and the production-ready defaults that work. You are not limited to a narrow abstraction or a closed deployment model. You still get the Kubernetes API, the ecosystem, and the flexibility to grow beyond the defaults when you need to.
Why we built it this way
We have built platforms of many shapes and sizes. The lesson that kept repeating was simple: most teams do not need more moving parts, they need a better starting point.
We built Kupe Cloud to be lean, modular, and operationally sound. That means choosing proven tools, integrating them thoughtfully, and operating them properly. It means avoiding unnecessary reinvention. And it means giving users something complete enough to deliver value immediately, while staying open enough to support more complex needs over time.
That is the standard we wanted for ourselves, and it is the standard we are building Kupe Cloud to meet.
