Kubero: a self-hosted PaaS that stores its state in Kubernetes etcd

What Kubero removes from the deployment path

The README frames the target user plainly: Kubero "allows any developer to deploy their application on Kubernetes without specialized knowledge." That is the problem it addresses. A developer with a container image or a Git repository normally needs to produce a Deployment, a Service, an Ingress, image pull secrets, environment configuration and a release process before anything is reachable. Kubero puts a web UI in front of that work and generates the Kubernetes objects instead. It follows the 12-factor app principles and accepts two input shapes: an existing container image, or source code that it builds. The audience is teams that already have a cluster and want a self-hosted alternative to Heroku, Netlify, Vercel, Dokku or Coolify without giving up Kubernetes as the runtime. It is not aimed at people who have no cluster, and the README does not present a hosted option.

Two containers, one operator, and etcd as the only database

The architecture is stated in one line: "Kubero is Kubernetes native and runs with two containers on any Kubernetes instance (kubero-ui and Operator). All data is stored on your Kubernetes etcd without an extra database." The ui container serves the interface and the API. The operator is the component that watches Kubero's own custom resources and reconciles them into Deployments, Services and the rest. Because there is no Postgres or MySQL behind the platform, the state of your pipelines, apps and their configuration is etcd data. That removes a moving part from the install and adds a dependency on etcd health and backup discipline. The README also lists integrations that sit on top of this: CI/CD pipelines, GitOps review apps that are built, started and cleaned up on pull request open and close, redeploys on branch or tag pushes, add-ons, metrics, notifications to Discord, Slack or webhooks, vulnerability scans, logs, a web console, cronjobs, multi-tenancy, SSO via GitHub and OAuth2, and basic auth. Each of those is a feature claim in the README, not something this article has exercised.

Add-ons are Helm charts you did not choose

The add-on table is the most concrete part of the README. MySQL, PostgreSQL, Redis, MongoDB, RabbitMQ and CouchDB are listed as built in. Five of them point at groundhog2k's helm-charts repository (mysql, postgres, redis, mongodb, rabbitmq) and CouchDB points at Apache's couchdb-helm. That means the platform's add-on layer is a thin wrapper over third-party charts maintained outside the Kubero project. When an upstream chart changes values, deprecates a field or drops a Kubernetes version, the add-on path is exposed to that change. This is a normal trade-off for a PaaS that does not want to own database operators, but it is worth knowing before you promise a team that "deploy PostgreSQL from the UI" is a supported, version-pinned operation. The README does not state which chart versions are bundled or how they are pinned.

Getting it running: the install surface the README names

The README does not reproduce the installation commands inline; it links to the documentation site and the demo. What it does commit to is the shape of the deployment: two containers, kubero-ui and the Operator, on any Kubernetes instance. The homepage and docs are at kubero.dev, with a live demo at demo.kubero.dev and screenshots at kubero.dev/docs/screenshots. The repository is TypeScript, the default branch is main, and the latest release at the time of writing is v3.1.1 from 2025-09-17, following v3.1.0 and v3.0.1. Because the exact manifest, Helm chart or kubectl commands are not in the material available here, treat the docs site as the source of truth for install steps rather than any command quoted from a blog post. What you can verify from the repository itself is the operator's deployment manifests and the RBAC it requests, which is the part that determines how much of the cluster Kubero can touch.

Where the design gets in the way

Storing all platform data in etcd is elegant until you need to query it. There is no SQL surface for pipelines, apps or their history, so reporting and bulk edits go through the API or the UI. etcd is also not a general-purpose database: it holds the whole cluster's state, and a Kubero namespace that grows with every pipeline, review app and build record adds to the same store your control plane depends on. Backup and restore of the platform is therefore a cluster-level concern, not a pg_dump. The second limitation is the operator itself. A Kubernetes operator that reconciles user-facing abstractions is the component most likely to need upgrades in lockstep with the cluster, and the release cadence shown here (v3.0.1 in August 2025, v3.1.0 in early September, v3.1.1 in mid-September) suggests active movement. If your cluster is on a slow upgrade cycle, or you cannot test operator upgrades in a staging cluster first, that mismatch is a real failure mode. The third case where Kubero is the wrong tool: teams that want a managed control plane with a vendor on the hook for uptime. Kubero is self-hosted, and the README offers no hosted tier.

Kubero against Dokku and Coolify

The README names Dokku and Coolify among the alternatives it positions against, and the difference is architectural rather than cosmetic. Dokku is built around a single host and Git pushes to that host; the application process runs on that machine, and scaling means adding machines and managing them yourself. Coolify targets self-hosted deployment across servers and Docker, with a UI in front of that. Kubero assumes Kubernetes from the start: the unit of deployment is a Kubernetes workload, the platform is an operator plus a UI, and the state lives in etcd. If you already have a cluster and want the PaaS layer to be a tenant on it, Kubero's model matches. If you do not have a cluster and do not want one, Dokku or Coolify will get you to a running app with less infrastructure underneath. That is the actual decision, and it should be made before comparing feature lists.

Licence, maintenance and what upgrading costs

Kubero is licensed GPL-3.0. For internal use that is usually unremarkable. If you plan to embed Kubero in a product you distribute, or to modify it and ship those modifications, the copyleft terms apply and you should have someone qualified read them rather than take this paragraph as advice. On maintenance: the release history shows three releases in roughly five weeks (v3.0.1, v3.1.0, v3.1.1), which means upgrades arrive often enough that pinning a version and reading release notes before moving is the practical approach. The upgrade cost is not just the UI container. The operator, the CRDs it owns and the add-on charts are all part of the surface, and the add-on charts are maintained by groundhog2k and Apache, not by Kubero. Budget for a staging cluster where you can apply a new Kubero release and confirm that existing pipelines, review apps and add-ons still reconcile before touching production.

Editorial conclusion

Adopt Kubero if you already run Kubernetes, want developers to deploy without writing manifests, and are comfortable with a GPL-3.0 platform whose data lives in etcd. Do not adopt it if you need a managed control plane, a relational store for platform state, or a PaaS that is not tied to a cluster you operate. Before installing, verify the operator's RBAC scope, the etcd backup and restore path for the kubero namespace, and whether the add-on Helm charts it references match the versions your cluster already runs.

Official sources

1. kubero-dev/kubero on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases