# Kubero: Heroku's workflow, running on the Kubernetes you already have > Kubero, pronounced Kube Hero, is a GPL-3.0 self-hosted PaaS alternative to Heroku, Netlify, Coolify, Vercel, Dokku and Portainer that runs on Kubernetes, letting developers deploy from containers or source without specialized knowledge following 12-factor principles. It ships 160 plus app templates, GitOps review apps, pipelines with up to four staging environments, add-ons from MySQL to ClickHouse, and keeps its state in etcd rather than a separate database. **kubero-dev/kubero** — A free and self-hosted PaaS alternative to Heroku / Netlify / Coolify / Vercel / Dokku / Portainer running on Kubernetes - Repository: https://github.com/kubero-dev/kubero - Website: https://demo.kubero.dev - Stars: 4,428 · Forks: 213 - Language: TypeScript - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/kubero-dev-kubero ## 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. ## 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. ## FAQ ### What are the alternatives to Kubero? Kubero positions itself as the self-hosted PaaS alternative to Heroku, Netlify, Coolify, Vercel, Dokku and Portainer, with the distinction that it runs on Kubernetes as two containers, a UI and an Operator, storing data in etcd without an extra database. ### How does Kubero deploy applications? Deployments run from existing Docker containers, without Helm charts, or from source code following 12-factor principles, with more than 160 templates for popular apps like WordPress and Grafana, GitOps review apps on pull requests, and automatic redeployments on pushes to branches or tags. ### Which add-ons does Kubero provide? Built-in starter add-ons include MySQL, PostgreSQL, Redis, MongoDB and RabbitMQ from groundhog2k, CouchDB and a Haraka mail server, while operator backed production options include CloudNative-PG and Crunchy PostgreSQL, Percona MongoDB, Redis Cluster, CockroachDB, ClickHouse, Minio and Cloudflare Tunnels. All Bitnami add-ons are deprecated. ## Sources - [kubero-dev/kubero on GitHub](https://github.com/kubero-dev/kubero) - [License: GPL-3.0](https://github.com/kubero-dev/kubero/blob/main/LICENSE) - [Project website](https://demo.kubero.dev) - [README](https://github.com/kubero-dev/kubero/blob/main/README.md) - [Releases](https://github.com/kubero-dev/kubero/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubero-dev-kubero