Kubero's PaaS on Kubernetes: What a Dashboard Over kubectl Actually Solves — and What You Still Operate Yourself

Kubero bills itself as a free, self-hosted Heroku for Kubernetes — push code, get a running app with a domain, logs, and a Postgres add-on, no Helm charts required. That pitch is real. It is also incomplete in one load-bearing way: Kubero is a PaaS on Kubernetes, not a PaaS that gives you Kubernetes.

If you already run a healthy cluster, Kubero removes an entire layer of kubectl and Helm toil. If you do not, the dashboard has nothing to schedule onto. The question to answer before you adopt it is not "is Kubero good?" but "who owns the machines underneath the dashboard?" — and here is the concrete answer.

Verdict up front. Kubero automates the app layer well and the machine layer not at all. That is a deliberate trade-off, not a bug — but it is the trade-off the rest of this post makes explicit so you can pick the right tool for where you actually are.

If the table's second row already makes you uneasy, keep reading — that row is the whole story.

What Kubero Actually Is​

Kubero [pronounced "Kube Hero"] is an open-source PaaS that runs as two containers on any Kubernetes cluster — kubero-ui and the Kubero Operator. There is no external database: all platform state lives in the cluster's own etcd. That small detail matters — there is one fewer datastore to back up, but also no platform state outside the cluster it manages.

How you get it running:

# CLI via install script or Homebrew
curl -fsSL get.kubero.dev | bash
# or
brew tap kubero-dev/kubero && brew install kubero-cli
 
# then
kubero install

kubero install can stand up a new cluster for you on GKE, Scaleway, DigitalOcean, Linode, or locally via Kind — or it can attach to an existing cluster you already operate. Supported Git remotes cover the usual set: GitHub, GitLab, Bitbucket, Gitea/Forgejo, and Gogs. Any language that bakes into a container works — Go, Python, Node.js, PHP/Laravel, Ruby/Rails, Rust, static HTML, and more via buildpacks maintained at kubero-dev/buildpacks.

What lands on day one: a web dashboard, an API and CLI, and a catalog of 160+ app templates (WordPress, Grafana, Bitwarden, Uptime Kuma, Trilium, and others) that deploy without writing a Helm chart. The project sits at roughly 4.4k GitHub stars with its license marked as free and open-source, a demo at demo.kubero.dev, and a Discord for support — a real community, not a one-person repo.

The architecture sketch is intentionally thin: you point Kubero at a kubeconfig, it watches pipelines and apps as custom resources, builds containers from your Git repo, and makes them reachable under the domain you configured. If you squint, it looks like the last mile of a platform. That is because it is the last mile — which brings us to what it covers and what it does not.

What the Dashboard Automates Well​

This is the list Kubero earns. If you already have a cluster, each item replaces real kubectl/Helm YAML and glue scripts you would otherwise maintain yourself.

• Docker deploys without Helm charts. Push a Dockerfile or let a buildpack do it. Kubero builds the image, creates the Deployment, Service, and Ingress, and wires TLS. You never write a chart to ship a container.
• CI/CD pipelines with up to four stages. A single pipeline can model review → test → stage → production with per-phase configuration. Unlimited pipelines per cluster means one Kubero install can back multiple teams.
• GitOps and review apps. Connect a pipeline to GitHub/GitLab/Bitbucket/Gitea/Gogs and Kubero auto-builds on push or tag, and — crucially — spins up ephemeral review apps on pull requests and tears them down when the PR closes. That loop alone saves the bespoke PR-preview workflow many teams hand-roll with GitHub Actions and Helm.
• Add-ons in one click. Postgres, MySQL, Redis, MongoDB, RabbitMQ, CouchDB, and Haraka mail ship as built-in add-ons (groundhog2k charts; Bitnami charts are deprecated after Broadcom's registry removal). CloudNativePG Postgres HA, Crunchy Postgres, Minio, Percona MongoDB, Redis Cluster, CockroachDB, and ClickHouse are available as operators for the harder cases — same add-on UX, real HA underneath when you need it.
• Cronjobs, logs, and a web console. Schedule tasks as cronjobs from the UI, tail logs without kubectl logs, and open a web console into the running container. Small features that collectively retire a lot of kubectl muscle memory.
• Metrics, vulnerability scans, and notifications. Integrated app metrics, scheduled or triggered vulnerability scans, and build/deploy notifications to Discord, Slack, or generic webhooks. Not a replacement for a full observability stack, but enough to know when a deploy broke something.
• Multi-tenancy, SSO, and basic auth. GitHub/OAuth2 SSO and per-app basic auth, with multi-tenant separation so one Kubero install can serve multiple projects without cross-talk.
• API and CLI for everything the UI does. kubero-cli covers add-ons, buildpacks, pod sizes, dashboard tunneling, and more — every click has a command, so CI can drive the platform without scraping a UI.

Taken together, this is a credible Heroku-like surface: git in, URL out, with the boring app-layer wiring handled. For a team that already operates Kubernetes — or inherited a cluster from a prior decision — Kubero's value is that it lets application developers stop thinking about Deployments and Ingresses entirely.

What It Does Not Touch: the BYOK Gap​

"Bring Your Own Kubernetes" is not a footnote in Kubero's architecture — it is the architecture. The dashboard has no opinion about where the cluster came from, how its nodes are provisioned, upgraded, or replaced, or how many machines sit behind the scheduler. That is powerful if you already solved those problems. It is the entire problem if you have not.

Concretely, here is what remains yours after Kubero is installed:

• Cluster creation and lifecycle. kubero install can create a cluster on a handful of providers, but it does not own that cluster's lifecycle the way Cluster API does. There is no declarative Cluster object whose desired state is reconciled by a controller — no "I want three workers on CX32 in FSN1" that the system converges toward and self-heals when a node dies.
• Node provisioning and machine lifecycle. Upgrading Kubernetes, replacing a node, changing an instance type, or adding a second availability zone is not a Kubero operation. You do it through your cloud console, kubeadm, kops, or whatever provisioned the cluster in the first place. Kubero schedules onto nodes; it does not create them.
• Capacity and autoscaling of the fleet itself. The Horizontal Pod Autoscaler can scale your app across the nodes you have. It cannot conjure a new node when the bin is full — that is the cluster autoscaler or a MachineDeployment, both outside Kubero's scope. A deploy that needs a third machine at 2 a.m. waits for a human to provision one.
• Bare-metal and Hetzner-native story. Kubero's install targets are GKE, Scaleway, DigitalOcean, Linode, and Kind. There is no first-class Hetzner Cloud or Hetzner Robot path — yet Hetzner is where the self-hosting cost argument wins most decisively. A platform that aims to undercut managed PaaS on price but has no opinion about the cheapest substrate leaves the economics to someone else.
• Declarative fleet reconciliation. Cluster API's core idea is that a cluster is a Kubernetes object — Cluster, Machine, MachineDeployment, KubeadmControlPlane — reconciled by controllers the same way a Deployment reconciles Pods. Kubero does not model machines at all. The mental model for "I want a different fleet tomorrow" is a cloud-provider ticket, not a kubectl apply.

None of this is a criticism of Kubero's design. A dashboard that also tried to be a cluster provisioner would be a larger, more opinionated, harder-to-adopt project. But it does mean "PaaS on Kubernetes" and "PaaS that is the Kubernetes fleet" are different categories, and comparing Kubero to single-box tools on dashboard polish alone collapses that distinction.

Three Generations, One Spectrum​

Self-hosted Heroku replacements have evolved in three architectural generations. Kubero belongs to the third — but the third generation still splits on whether the fleet itself is declarative.

The jump from Gen 2 to Gen 3 (Coolify/Dokploy → Kubero) buys you real scheduling, rolling upgrades, and HA — Kubernetes at its best. The jump from "Kubero on a cluster" to "fleet-native" buys you the same thing one layer down: the machines themselves become declarative, versioned, and self-healing.

A useful shorthand: Coolify and Dokploy ask you to bring a server. Kubero asks you to bring a cluster. A Cluster API platform asks you to bring a Hetzner token — and builds the rest.

Who Should Pick Which​

There is no single winner — only a best fit for where you are starting:

• You already run Kubernetes in production and want developers to stop writing Helm. Pick Kubero. You solved the hard part; Kubero removes the remaining app-layer toil without asking you to change providers or replatform. The BYOK clause is not a tax for you — it is a non-issue.

• You run one or two VPS boxes and like Docker Compose. Pick Coolify (polished single-box / small-fleet UI, largest community) or Dokploy (stronger multi-server Compose story, good monitoring). Both get you git-push deploys this afternoon with no Kubernetes to learn. Accept the ceiling: scaling past a few boxes, HA, and GitOps review apps will eventually push you toward Gen 3.

• You want git-push deploys and you do not want to operate Kubernetes the hard way. That is the seam a Cluster API fleet fills. You declare the fleet you want — node pools, regions, instance types — and the platform reconciles it, the same way Kubernetes reconciles Pods. Kubero's dashboard is a great last mile; a fleet-native platform is the road underneath it. The two ideas compose well — there is nothing stopping a Kubero install on a CAPI-provisioned cluster — but only one of them answers "who makes the next machine appear?"

• You need strict EU data residency or cost dominance on bare metal. Any solution that terminates on GKE/DO/Linode inherits that provider's jurisdiction and pricing. A fleet on owned Hetzner (or OVHcloud/Scaleway) hardware keeps residency and the ~€10-€50/box flat-rate economics that make self-hosting win. Kubero can run there if you bring the cluster; a Hetzner-native CAPI provider does it by default.

The Honest Bottom Line​

Kubero is the most complete answer to "I have Kubernetes and I want a Heroku-like dashboard without writing Helm" that the open-source ecosystem currently offers. Its 160+ templates, four-stage pipelines, PR review apps, and built-in add-on catalog are not demos — they are a real daily driver for teams that already operate a cluster.

That "already" is doing a lot of work. Every team that adopts a dashboard-on-Kubernetes tool eventually hits the same question a single-box team hits when it needs a second server: who provisions the next machine, and what breaks while a human figures it out? Kubero answers that question by pointing outside itself — to the cloud console, to kubeadm, to whatever built the cluster it runs on. A Cluster API fleet answers it the same way Kubernetes answers "who starts the next Pod" — a controller does, because desired state is declared and reconciled, not ticketed.

If you have the cluster, start with Kubero. If you still need the fleet, start one layer down — and then put Kubero (or any dashboard you like) on top of a fleet that can actually grow itself.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A Cluster API fleet provisions the hardware, reconciles the nodes, and exposes a Render-compatible API and MCP server so agents and humans deploy the same way. Star the repo on GitHub or deploy your first app today.