Self-hosted platform-as-a-service, honestly reviewed. No marketing fluff, just what you get when you deploy your own Heroku on Kubernetes.

TL;DR

What it is: Open-source (GPL-3.0) self-hosted PaaS that runs on Kubernetes, letting you deploy applications through a Heroku-style UI without writing Kubernetes manifests or Helm charts [README][4].
Who it’s for: Developers and small engineering teams already running or comfortable setting up Kubernetes who want a self-hosted replacement for Heroku, Render, or Railway. Not for non-technical founders who want to avoid the command line [4].
Cost savings: Heroku’s paid tiers start at $5–7/mo per dyno and escalate sharply at volume; a self-hosted Kubero instance on a managed Kubernetes cluster (e.g., Hetzner k3s) can consolidate dozens of apps for $20–40/mo total. The comparison only makes sense at scale.
Key strength: Full CI/CD pipeline support with GitOps review apps, 160+ one-click app templates, and built-in add-ons (PostgreSQL, Redis, MongoDB) — all running inside your own cluster with zero per-deployment fees [README][4].
Key weakness: Kubernetes is the prerequisite. If you don’t already have a Kubernetes cluster or don’t know what one is, Kubero is not your first move. Tools like Coolify or CapRover serve that audience better [3].

What is Kubero

Kubero — pronounced “Kube Hero” — is a self-hosted PaaS that sits on top of Kubernetes and hides most of its complexity behind a web UI. The project description is plain and accurate: “A free and self-hosted PaaS alternative to Heroku / Netlify / Coolify / Vercel / Dokku / Portainer running on Kubernetes” [README]. The name says what it does.

The core idea is that Kubernetes is powerful but hostile to humans who don’t spend their days writing YAML. Kubero translates the familiar PaaS workflow — push code, see it deployed — into Kubernetes primitives without requiring the developer to understand those primitives. You connect a Git repository, define a pipeline with up to four staging environments, and Kubero handles the rest: spinning up containers, running builds, configuring ingress, managing add-ons [4].

Architecturally, Kubero is lean. It runs as two containers on any Kubernetes instance — kubero-ui and a Kubernetes Operator — and stores all state in the cluster’s own etcd rather than an external database [README]. This is a meaningful design choice: there’s no database to back up separately, no additional stateful service to keep alive. The cluster is the state.

The project is licensed under GPL-3.0, which is meaningfully different from MIT (the license Activepieces uses, for reference). GPL-3.0 requires derivative works to also be open source, which matters if you’re planning to embed Kubero in a commercial product or white-label it. For pure self-hosting purposes, it makes no practical difference [README][1].

As of this review, the repository sits at 4,198 GitHub stars with 194 forks and 2,200 commits across the history [README][website scrape].

Why people choose it

The reviews available for Kubero [1][4] are thinner on head-to-head user opinion than what you’d find for more mature tools like Coolify or n8n, which have broad Trustpilot and Reddit footprints. What the sources do agree on covers three themes.

The Kubernetes leverage argument. If you’re already running Kubernetes — for a staging environment, a microservices setup, or because your cloud provider makes it easy — Kubero turns that cluster into a multi-app deployment platform at minimal additional cost. Medevel’s review [4] frames this clearly: Kubero is an Internal Developer Platform (IDP) that brings “streamlined Heroku workflows to your Kubernetes cluster.” The value is not Kubernetes itself — that’s already there — it’s the UI and automation layer that makes it usable by developers who aren’t Kubernetes specialists.

No external database dependency. Using etcd for state storage is an architectural decision that a surprising number of reviews highlight positively [README][4]. Running a self-hosted PaaS that itself requires a managed database is a layered dependency problem. Kubero sidesteps it.

The Heroku cost escape. Heroku is the canonical comparison [README][4]. Heroku’s 2022 removal of the free tier and subsequent price increases pushed a large segment of its user base into the market for alternatives. For teams already on Kubernetes, Kubero is a credible answer. For teams not on Kubernetes, Coolify and CapRover serve the same escape-from-Heroku narrative with significantly lower setup complexity [3].

What reviewers don’t say is also informative. There are no Trustpilot reviews, no substantial Reddit threads in the sources, and no user quotes about switching from specific tools. The community is active (Discord server, multilingual README with Chinese and Japanese translations), but the public opinion footprint is thin compared to Coolify or Dokku [1][3]. Kubero is a serious tool used by people who don’t write blog posts about their infrastructure.

Features

From the README and Medevel’s detailed breakdown [4]:

Deployment:

Docker container deployments on Kubernetes without Helm charts [README]
Deploy from source code or existing container images [README]
160+ application templates for common software (WordPress, Grafana, Bitwarden, Gitea, n8n, Outline, Ghost, and more) [README][5]
Automatic redeployments triggered by git push to branches or tags [README][4]

CI/CD and GitOps:

Unlimited CI/CD pipelines [README][4]
Up to 4 separate staging environments per pipeline [README][4]
GitOps review apps: automatically build, start, and clean up preview environments when pull requests open or close [README][4]
Webhooks support [README]

Add-ons (built-in, shipped with the Operator):

MySQL, PostgreSQL, Redis, MongoDB, RabbitMQ, CouchDB, Haraka Mail Server [README]
Also supports: Cloudflare Tunnels, MinIO, Percona MongoDB Cluster, CockroachDB, ClickHouse, and others via external operators [README]
Note: All Bitnami add-ons are deprecated and being removed due to Broadcom’s image repository changes [README]

Operations:

Integrated metrics and monitoring from within the UI [README][4]
Application logs accessible directly in the web UI [README][4]
Vulnerability scans — triggered or scheduled [README][4]
Built-in web console for direct container access [README][4]
Safe application restarts via UI [README]
Scheduled tasks / cronjobs [README][4]

Access and security:

Single Sign-On (SSO) via GitHub and OAuth2 [README][4]
Basic Auth for applications [README]
Multi-tenancy support [README]

Developer tooling:

REST API and CLI [README][4]
Brew install available for the CLI on macOS and Linux [README]
Notifications via Discord, Slack, or Webhooks [README]

What’s missing compared to some competitors: no built-in HTTPS certificate management (you rely on cert-manager or your ingress controller), no marketplace with hosted add-ons, and no managed cloud option — Kubero is self-hosted only [README][4].

Pricing: SaaS vs self-hosted math

Kubero itself is free. The software license is GPL-3.0 with no paid tiers, no commercial edition, and no feature gating [README][1]. What you pay for is the infrastructure to run it on.

Infrastructure costs:

The only meaningful cost is the Kubernetes cluster. Options range from:

A self-managed k3s cluster on a $6/mo Hetzner VPS (tight, but workable for low-traffic apps)
Hetzner’s managed Kubernetes starting around $25–40/mo for a basic multi-node setup
DigitalOcean Managed Kubernetes starting at ~$24/mo for a basic node pool
AWS EKS or GKE for teams already in those ecosystems, where cluster costs scale significantly higher

Heroku for comparison:

Basic (after 2022): $5–7/mo per dyno
Standard 1x: $25/mo per dyno
A 5-app deployment on Standard dynos: $125/mo
Heroku Postgres: $5–50/mo depending on tier, per database

Render for comparison:

Individual services: $7–25/mo each
Databases: $7–97/mo depending on instance size

Concrete math for a small team running 10 apps: On Heroku Standard: 10 × $25 = $250/mo plus database costs — easily $300–400/mo total. On Kubero with Hetzner k3s (3-node cluster): ~$35–50/mo for the cluster, covering all 10 apps with shared resources and built-in add-ons. Savings of $250–350/mo, or $3,000–4,200/year.

That math is compelling — but only if you can operate Kubernetes. If you need to hire or contract someone to set it up and maintain it, factor that cost in before making the comparison.

Deployment reality check

Kubero’s quickstart is genuinely accessible for its target audience. The CLI (kubero install) handles cluster setup, installs all components including the Operator, and walks through configuration interactively [README]. The CLI is available via curl, Brew (macOS/Linux), and binary downloads for Windows [README].

What you actually need:

A Kubernetes cluster — existing or new. Kubero supports any Kubernetes instance: local (kind, k3s, minikube), managed (EKS, GKE, AKS, Hetzner), or self-managed [README]
The Kubero CLI to run the install
A domain and DNS configuration for your apps
A Git provider: GitHub, GitLab, Gitea, Forgejo, Gogs, Bitbucket, or self-hosted Gitea/Gogs [4]

What can go sideways:

Kubernetes is the hard part. Setting up a production-ready cluster with proper node sizing, persistent volume provisioning, ingress configuration, and cert-manager is non-trivial. None of the reviews understate this, though Medevel [4] frames the Kubero layer itself as straightforward once the cluster exists.
The Bitnami add-on deprecation is an active issue. If you’re running older Kubero deployments that used Bitnami add-ons (MySQL, PostgreSQL, Redis via Bitnami), those are being removed in future releases [README]. Migration to the built-in Operator add-ons is necessary.
No managed cloud fallback. If your cluster goes down, Kubero goes down. There’s no hosted option to fall back to while you fix the infrastructure.
SSO is included but limited to GitHub and OAuth2 [README][4]. If your organization needs SAML or LDAP, that’s not built in.
The public review footprint is thin. LinuxLinks [1] covers Kubero as part of a software directory but doesn’t publish a hands-on verdict. SaaSHub [2][3] tracks it as an alternative tool but has no user reviews on file. For a tool asking you to trust it with your deployment infrastructure, the lack of public incident reports and user feedback is a data gap worth noting.

Realistic time estimate for a developer already comfortable with Kubernetes: 1–3 hours to a working Kubero instance on an existing cluster. For someone setting up Kubernetes from scratch: a full day to a weekend, depending on how much you already know about networking, DNS, and persistent storage.

Non-technical founders: this is not your tool. Start with Coolify on a single VPS.

Pros and Cons

Pros

Kubernetes-native architecture without the YAML. Kubero translates Heroku-style workflows into Kubernetes primitives. Developers get the simplicity of PaaS on infrastructure they control and can scale [README][4].
No external database. All state lives in Kubernetes etcd — no separate Postgres or Redis required to run Kubero itself [README]. Fewer moving parts to break and back up.
160+ one-click app templates. WordPress, Grafana, Ghost, Outline, Gitea, n8n, NocoDB, and dozens more deploy in minutes [README][5]. The template library is genuinely broad and actively maintained.
GitOps review apps included. Automatically spin up preview environments on pull requests and tear them down on merge. This is a feature that costs real money on Render or Railway, and it’s standard in Kubero [README][4].
Unlimited pipelines and staging environments. No tier gating on the number of pipelines or apps. You pay for the cluster, not the feature count [README].
Built-in vulnerability scans. Scheduled or triggered scans of running containers without a separate security tool [README][4].
SSO included at no cost. GitHub and OAuth2 SSO are built in for all users, not gated behind an enterprise tier [README][4].
Active CLI-driven installer. kubero install handles the complexity of bootstrapping a cluster and configuring all components [README].

Cons

Kubernetes is a hard prerequisite. This is not an optional detail. If you don’t have Kubernetes knowledge or an existing cluster, the setup cost is high. Coolify or CapRover solve the same problem for a much wider audience [3].
GPL-3.0 limits commercial reuse. You can self-host freely, but you can’t embed Kubero in a proprietary product or SaaS without open-sourcing your derivative. If you’re building a hosting product on top of Kubero, talk to a lawyer first [README][1].
No managed cloud option. Self-hosted only. There’s no “Kubero Cloud” to start on while learning the tool or to fall back to when your cluster has problems.
Bitnami add-on deprecation. An active migration burden for existing deployments. The built-in Operator add-ons are the replacement path, but the transition is required, not optional [README].
Thin public opinion footprint. Very few independent user reviews, no Trustpilot presence, no substantial Reddit discourse in the available sources [2][3]. For a tool managing your production deployments, that’s a meaningful information gap.
SSO limited to GitHub and OAuth2. No SAML, no LDAP. Teams with existing enterprise identity providers need to evaluate whether this is workable [README][4].
Not a managed-database alternative. The built-in add-ons (PostgreSQL, Redis, etc.) are explicitly not HA-ready — they’re documented as a fast start, not a production database substitute [README]. For real databases, you need a managed service or a separate Operator like Crunchy or Percona.

Who should use this / who shouldn’t

Use Kubero if:

You already run Kubernetes or are planning to run it regardless — for a staging environment, a microservices deployment, or cost consolidation across many apps.
You’re a developer or small engineering team that wants Heroku-style simplicity without Heroku’s per-dyno pricing.
You need GitOps review apps and CI/CD pipelines without paying per-seat or per-pipeline.
You’re deploying multiple apps and want them consolidated on shared infrastructure with shared add-ons.
You want SSO, vulnerability scanning, and multi-tenancy without a commercial license.

Skip it (use Coolify instead) if:

You’re a non-technical founder who wants to self-host and escape SaaS bills but doesn’t know Kubernetes. Coolify runs on a single VPS with a Docker-based install and a gentler learning curve [3].
You want managed HTTPS, automatic Let’s Encrypt, and a setup that takes 30 minutes, not a weekend.

Skip it (use CapRover instead) if:

You need something between Coolify’s simplicity and Kubero’s Kubernetes power. CapRover runs on a single server, has a mature app store, and is less opinionated about infrastructure [3].

Skip it (use Dokku instead) if:

You want the minimal, Unix-philosophy version of Heroku: git push deploys, zero UI, maximum control. Dokku is the smallest PaaS implementation that works and has been doing so for a decade [3].

Skip it (stay on Heroku/Render) if:

You have fewer than 5 apps and the cost is manageable. The Kubernetes infrastructure overhead only pays off at scale.
Your team has no one who can maintain a Kubernetes cluster. Downtime on self-hosted infrastructure is your problem to fix.

Alternatives worth considering

From the SaaSHub alternatives list [3] and the project’s own positioning [README]:

Coolify — the most direct competitor for the “self-hosted Heroku” category. Runs on a single VPS, actively developed, MIT-licensed, significantly easier to set up than Kubero. Choose Coolify if you don’t need Kubernetes.
CapRover — Docker-based, single-server PaaS. Mature, stable, large app store. Better than Coolify for some multi-app scenarios, similar ease of setup [3].
Dokku — the original “tiny Heroku.” Bash-based, minimal, rock-solid. No UI, maximum control. For developers who prefer the terminal [3].
Dokploy — newer open-source alternative to Heroku, Vercel, and Netlify. Worth evaluating alongside Coolify and CapRover [2].
Portainer — Docker and Kubernetes management UI, not a PaaS. Lower-level than Kubero, useful for teams that want visibility into their container runtime without the deployment automation layer [3].
Heroku — the incumbent. Easiest experience, no infrastructure to manage, most expensive at scale, fully proprietary. The thing you’re replacing.
Render — hosted alternative with a better free tier than Heroku’s current offering. Closed source, usage-based pricing, no self-hosting option.
Railway — modern hosted PaaS with per-service usage pricing. Good DX, no self-hosting option, costs climb at volume [2].
Porter — Heroku experience that runs in your own AWS/GCP/Azure account. Bridges managed and self-hosted, commercial product [3].

The practical shortlist for a team evaluating self-hosted PaaS: Kubero vs Coolify. If you have Kubernetes, Kubero. If you have a VPS, Coolify. Everything else is a more specialized answer to a narrower question.

Bottom line

Kubero is a well-designed tool for a specific audience: developers who already speak Kubernetes and want to stop writing YAML for every deployment. It delivers a genuine Heroku-style experience — git push deploys, review apps, staging pipelines, one-click add-ons — on infrastructure you own and control, at a total cost that makes Heroku’s per-dyno pricing look absurd at scale. The GPL-3.0 license, the etcd-native state storage, and the CLI-driven install are all thoughtful architectural choices.

The ceiling is Kubernetes. If you don’t have it and don’t plan to invest in it, Kubero isn’t the tool for you — Coolify or CapRover will get you to self-hosted faster with less infrastructure surface area to maintain. But if Kubernetes is already in your stack, or if you’re running five or more applications and the economics of a shared cluster make sense, Kubero turns that cluster into a platform rather than a collection of manually configured deployments. That’s the pitch, and it’s an honest one.

If the Kubernetes setup is the blocker, that’s the kind of deployment work upready.dev handles for clients. One-time setup, your infrastructure, your control.

Sources

LinuxLinks — “Kubero - self-hosted PaaS” (updated March 9, 2026). https://www.linuxlinks.com/kubero-self-hosted-paas/
SaaSHub — “Kubero Down? Kubero status and reported issues”. https://www.saashub.com/kubero-status
SaaSHub — “Top 12 Open-Source Alternatives to Kubero”. https://www.saashub.com/open-source/kubero-alternatives
Medevel — “Kubero: A Powerful Heroku Alternative for Your Development Needs”. https://medevel.com/kubero/
Kubero — Application Templates. https://www.kubero.dev/templates/

Primary sources:

GitHub repository and README: https://github.com/kubero-dev/kubero (4,198 stars, GPL-3.0 license)
Kubero website: https://www.kubero.dev
Kubero documentation and screenshots: https://www.kubero.dev/docs/screenshots

Features

Authentication & Access

Single Sign-On (SSO)

Integrations & APIs

Plugin / Extension System
Webhooks

Replaces

Related DevOps & Infrastructure Tools

View all 196 →

Coolify

52K

Self-hosting platform that deploys apps, databases, and services to your own server with a single click. Open-source alternative to Heroku, Netlify, and Vercel.

devops Apache-2.0