Kubero: Heroku's workflow, running on the Kubernetes you already have

Heroku's shape, on your own cluster

Kubero is a self-hosted PaaS that allows any developer to deploy their application on Kubernetes without specialized knowledge, positioning itself explicitly as an alternative to Heroku, Netlify, Coolify, Vercel, Dokku and Portainer, a list that covers both the hosted platforms and the self hosted competitors. It follows the principles of 12-factor apps, and it is possible to run apps based on existing containers or from source code, the two on ramps that matter, bring a Dockerfile or bring a repository. The project presents itself in three languages, English, Chinese and Japanese readmes, runs a public demo at demo.kubero.dev, publishes a full video walkthrough, and keeps a Discord for the community.

Two containers, state in etcd

The basic concept is Kubernetes native, Kubero runs with two containers on any Kubernetes instance, kubero-ui and the Operator, and all data is stored on your Kubernetes etcd without an extra database, which is a meaningful deployment property, no stateful database to back up beside the cluster itself. A separate container mode exists for running the UI outside the cluster, wired through a kubeconfig supplied as the KUBECONFIG_BASE64 environment variable, extractable from a cluster with kubectl config view --raw --minify piped through base64, with the compose file mapping port 8000 to the UI's 2000 and mounting a config.yaml and a server/db directory. That db directory explains the Dockerfile's sqlite settings, the standalone image carries a local sqlite file for its own bookkeeping, while the in cluster deployment leans on etcd as stated.

160 templates, pipelines with four stages

Deployment ergonomics come from two directions. App templates, more than 160 of them, let popular applications like WordPress and Grafana deploy ready to use from a catalog, the difference between clicking and composing. CI/CD pipelines are unlimited with up to 4 separate staging environments per application, giving every app its own progression from review to production. On top sit the GitOps mechanics, review apps that automatically build, start and clean up when pull requests open and close, and automatic redeployments triggered by pushes to branches or tags, the trigger set that makes push to deploy real. Docker deployments need no Helm charts, the platform wraps containers into Kubernetes resources itself, removing the most specialized artifact from the normal path.

Built-in add-ons, and operator-backed clusters

The add-on table has three tiers worth reading carefully. Built in, shipped with the Operator and explicitly not high availability but great to get started fast, are MySQL, PostgreSQL, Redis, MongoDB and RabbitMQ from groundhog2k's charts, CouchDB from Apache, and a Haraka mail server maintained by Kubero itself. Every Bitnami add-on, the MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, Kafka, Memcache and RabbitMQ entries, is marked deprecated. The third tier is operator backed and aimed at production, PostgreSQL HA from CloudNative-PG, Crunchy Postgres clusters, Percona MongoDB clusters, Redis clusters from Opstree, CockroachDB, ClickHouse from Altinity, Minio and Cloudflare Tunnels, the serious data layer the starter add-ons are not. The deprecation of an entire popular chart family in favor of these is the table's quiet headline.

Scans, metrics, logs and a web console

Operations in the web UI cover the daily loop. Scheduled or triggered vulnerability scans run against running applications, folding security posture into the platform rather than an external tool. Integrated metrics monitor application health, and application logs are viewable directly from the UI, the two panes an on call engineer actually keeps open. Safe restarts restart applications through the UI without the kubectl dance, and a built-in container web console gives direct shell access to running containers when logs are not enough. Scheduled tasks round it out with cronjob management, so the periodic jobs that usually live in forgotten crontabs become visible, editable objects in the same interface as the applications they serve.

SSO, multi-tenancy, and notifications

The platform layer handles the organizational concerns. Single Sign On authenticates securely with GitHub and OAuth2, Basic Auth can be configured per application with ease for the simpler cases, and multi tenancy supports managing multiple tenants, the feature that separates a personal tool from one an infrastructure team can offer internally. Notifications deliver build and deployment updates through Discord, Slack or webhooks, feeding the channels teams already watch. An API and CLI integrate with existing tools and CI/CD workflows, so the platform remains scriptable even though its face is a web UI, and everything above is visible in the live demo rather than existing only as a feature list.

A Node monorepo developed against kind

The repository structure is a client, server and services split built on Node 22 Alpine images, the server carrying Prisma schemas and the client the React interface, built with yarn in a two stage Dockerfile that stamps a version file and runs node main. Development against Kubernetes happens through kind, with a kind.yaml cluster definition and a dedicated docker-compose.kind.yaml composition, so contributors get a disposable local cluster rather than needing real infrastructure. Governance files show a maintained project, OWNERS and MAINTAINERS.md beside a security policy and code of conduct. Releases run through v3.0.1 in August 2025, v3.1.0 in September 2025 and v3.1.1 on 2025-09-17, with the last repository push on 2026-09-09 under GPL-3.0.

Editorial conclusion

Choose Kubero when a team has a Kubernetes cluster and wants push to deploy ergonomics without every developer learning kubectl and Helm, since the template library, pipelines and add-on handling cover the Heroku shaped workflow on your own infrastructure. Look at Coolify or Dokku if there is no Kubernetes cluster to run it on, its whole premise is the cluster underneath. Before adopting, note the release cadence, the newest tag is v3.1.1 from September 2025 with the last push on 2026-09-09, prefer the groundhog2k and operator backed add-ons over the deprecated Bitnami ones, and accept the stated limitation that shipped add-ons are not high availability, designed to get started fast rather than to run production databases at scale.

Frequently asked questions

Official sources

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