Dokku vs Dokploy vs Kubero: Three Generations of Self-Hosted Heroku Alternatives

Every few years, the self-hosting world rediscovers Heroku. Not the company — the idea: git push, and your app is running on the internet with HTTPS, somewhere you control. Dokku nailed that idea in 2013 on a single five-dollar VPS. Dokploy is nailing it again in 2026 with a modern UI and multi-server reach. And Kubero asks the uncomfortable next question: what if the servers underneath were Kubernetes all along?

These three projects are not really competitors. They are three architectural generations of the same dream, each one answering the question the previous generation could not. This post compares them head-to-head across the five dimensions that actually decide a self-hosting choice — git-push deploy flow, scaling story, high availability, multi-node reality, and upgrade pain — and then places them on the spectrum that ends with platforms that provision the machines themselves.

TL;DR: the three generations in one table​

If you stopped reading here, you already have the shape of the answer: each generation moves the ceiling one layer up — from one box, to several boxes, to a whole cluster. The rest of this post is why each ceiling exists and what it costs to outgrow it.

Gen 1 — Dokku (2013): the mini-Heroku that owns one box​

Dokku calls itself "the smallest PaaS implementation you've ever seen," and thirteen years in, the description still fits. You install it on a single Linux server with a bootstrap script, add a git remote, and git push dokku main builds your app from Heroku-compatible buildpacks, a Dockerfile, or a prebuilt image, then serves it behind nginx with Let's Encrypt TLS. Background workers, cron tasks, Postgres and Redis via plugins, zero-downtime deploys — the Heroku workflow, faithfully reproduced, on hardware you rent for the price of a coffee.

The constraints are not accidents; they are the design. Dokku's maintainers have been explicit for years: Dokku is a single-host solution, and there are no plans for multi-host deployment. dokku ps:scale web=2 gives you two containers on the same machine. If that machine dies, everything on it dies with it — there is no failover, no rescheduling, no second copy anywhere. Backups, OS patching, disk-full incidents at 3 AM: all yours.

That sounds harsh until you price the alternative. For side projects, staging environments, and small production apps that fit on one VPS, Dokku's total operational surface is one server and a shell CLI you can learn in an afternoon. Nothing to upgrade except Dokku itself and Docker. The wave of critical CVE disclosures across self-hosted panels in early 2026 was a reminder that "one server you own" also means "one server you patch" — but with Dokku, at least, there is exactly one of them.

Dokku's ceiling: the day one server is not enough — more traffic than a single box, a customer asking about uptime SLAs, a second region — Dokku has no answer, by philosophy. That is the exact gap generation two was built to fill.

Gen 2 — Dokploy (2024): the UI-first Docker PaaS that stretches past one box​

If Dokku is a Heroku you operate from the terminal, Dokploy is a Render you operate from the browser. Born in 2024 and already past ~35,000 GitHub stars, it wraps Docker and Docker Compose in a polished web dashboard: connect a Git repo, and Dokploy builds and deploys it; pick Postgres or Redis from a one-click catalog; attach a domain and Traefik terminates HTTPS automatically. The whole control plane runs as four containers — app, Postgres, Redis, Traefik — installed with a one-liner.

The generational leap over Dokku is multi-server management. Dokploy can orchestrate remote servers over SSH, so your apps and databases can live on machines other than the one running the dashboard. It also supports remote build servers, keeping heavy image builds off production hosts. For a team graduating from one VPS to a small fleet — app server here, database server there, a staging box somewhere else — this is exactly the management layer Dokku refuses to be.

But read the fine print on that multi-server story, because it defines Dokploy's own ceiling. Clustering runs on Docker Swarm, and Swarm support is still flagged experimental; remote-server monitoring is a documented gap; and as one operator guide puts it, multi-server here means multiple instances, not true clustering. There is no scheduler bin-packing your workloads, no control plane rescheduling containers off a dead node, no declarative desired-state loop reconciling drift. You get more boxes under one UI — genuinely useful — but each box is still, operationally, a pet.

Dokploy is also pre-1.0 (v0.29.x as of mid-2026) with a split license: Apache-2.0 core, plus a source-available license gating future paid features like SSO, RBAC, and audit logs. That is a reasonable business model, and teams evaluating it should simply note which side of the line the features they need fall on.

Dokploy's ceiling: Docker-level orchestration. The day you need real scheduling — workloads that place themselves, survive node death automatically, scale on metrics without human clicks — no dashboard over SSH remotes can provide it. That requires an orchestrator with a control plane. Which is to say: it requires Kubernetes, the thing Dokploy explicitly chose to avoid.

Gen 3 — Kubero: Heroku UX on Kubernetes you bring yourself​

Kubero completes the progression by conceding the hardest part to Kubernetes. It is a self-hosted, Heroku-style PaaS that runs on Kubernetes: GitOps push-to-deploy, pull-request preview apps, app templates, and database add-ons, all without writing a single Helm chart. Developers get the git push workflow; underneath, Kubero speaks Deployments, Services, and Ingresses so they do not have to.

Everything Dokploy cannot do, Kubero inherits for free — because Kubernetes already does it. Horizontal pod autoscaling, multi-replica high availability, pod disruption budgets, rolling updates with real health gates, scheduling across nodes and zones: none of this is Kubero code, and that is the point. The moment your platform sits on a real orchestrator, the scaling story, the HA story, and the multi-node story stop being features a PaaS team must build and start being configuration a PaaS team must expose.

The price is stated plainly in Kubero's own documentation, under the heading "What Kubero won't do for you": manage your Kubernetes cluster. You bring a working cluster — provisioned, upgraded, networked, and monitored by someone, and that someone is you. For a team that already runs Kubernetes, this is the correct division of labor: Kubero turns an existing cluster into a Heroku. For a team that does not, Kubero's prerequisite is the project: learning Kubernetes operations to earn a simpler deploy flow is a deal many small teams rationally decline, which is exactly why Kubero's community stays smaller and more infrastructure-fluent than Dokploy's.

Kubero's ceiling: the cluster itself. Kubero schedules onto machines; it does not create them. Node provisioning, machine lifecycle, cluster upgrades across a fleet, adding a second cluster — all outside its scope. Which raises the final question of this post: who provisions the provisioner?

Head-to-head: the five dimensions that decide​

Git-push deploy flow. All three deliver the core promise, with different ergonomics. Dokku is pure CLI and closest to original Heroku semantics. Dokploy adds GUI-driven Compose stacks and image deploys that Dokku's buildpack-centric model handles awkwardly. Kubero adds GitOps semantics and PR preview environments as first-class citizens. Winner: Dokploy for breadth, Kubero for team workflows, Dokku for simplicity — genuinely a three-way tie decided by taste.

Scaling story. Dokku scales vertically (bigger box) plus same-host replicas — a hard wall. Dokploy scales horizontally across SSH-managed servers but without metric-driven autoscaling or intelligent placement. Kubero inherits the Kubernetes scaler stack end to end. Winner: Kubero, by an architectural order of magnitude. This is the dimension where "runs on Kubernetes" stops being an implementation detail and becomes the whole argument.

High availability. Dokku: none, by design. Dokploy: you can run copies on multiple servers, but failover is manual and there is no control plane to notice a dead node. Kubero: multi-replica Deployments with health probes and rescheduling are the default shape of everything. Winner: Kubero. Dokploy's multi-server support narrows the gap for planned maintenance; it does not close it for unplanned failure.

Multi-node reality. This is the dimension the marketing pages blur, so be blunt: Dokku has one node. Dokploy manages N nodes as N individuals over SSH with experimental Swarm clustering. Kubero does not manage nodes at all — your cluster does, properly, because that is what Kubernetes is for. Winner: Kubero if you have a cluster; Dokploy if "several pets under one dashboard" matches your actual scale. Both beat Dokku the day one box stops being enough.

Upgrade pain. Here the ranking inverts. Dokku upgrades are a package update on one server — fifteen minutes and a coffee. Dokploy upgrades its four-container control plane plus whatever Docker versions drift across your remotes — manageable, but N servers means N chances for skew. Kubero upgrades ride the Kubernetes upgrade treadmill: the PaaS layer is easy, the cluster underneath is a quarterly project with version skew policies and node-drain discipline. Winner: Dokku, effortlessly. Every layer of power you add is a layer you must maintain — the iron law this whole comparison obeys.

The layer none of them owns: the machines​

Step back and look at the table again. Dokku assumes a server. Dokploy assumes servers. Kubero assumes an entire cluster. All three schedule onto machines that somebody else — you, with a VPS control panel and an SSH key — provisioned by hand. The submissions get more sophisticated, but the foundation stays manual: click, install, join, repeat. Fleet growth means repeating your provisioning runbook; fleet upgrades mean repeating your maintenance runbook; drift between what you declared and what exists is detected by humans, usually during incidents.

This is the exact seam the next architectural step exists to remove. A Cluster-API-based platform treats machines the way Kubernetes treats pods: declarative objects, reconciled by controllers. Need a node? A MachineDeployment gains a replica and a server appears, bootstrapped and joined. Need an upgrade? Roll the machine set and watch old nodes drain themselves. The "zero-drift" posture France's SNCF runs across a 200-cluster national-rail fleet — every cluster reconciled to declared state on a monthly cadence — is the same control loop, just pointed at infrastructure instead of workloads. Kubero won't manage your cluster; Cluster API's whole job is managing clusters, including the metal (or VMs) underneath them.

So the full spectrum reads: Dokku (one box, by hand) → Dokploy (several boxes, one dashboard) → Kubero (a cluster, Heroku-flavored) → fleet-as-code (clusters and machines, declared and reconciled). Each arrow preserves what came before — the git push workflow survives every transition — and automates the layer the previous generation left manual. The question was never which tool is "best." It is which manual layer is currently costing you the most sleep.

Which one should you pick?​

• One VPS, side projects, first production app: Dokku. A decade-plus of maturity, MIT-licensed, learnable in an afternoon. Outgrow it proudly when the time comes.
• A few servers, a small team, Docker-native: Dokploy. The UI, one-click databases, and SSH multi-server management are a genuine step up — just go in knowing Swarm clustering is experimental and node death is still your problem.
• You already run Kubernetes: Kubero. It converts sunk cluster-ops cost into Heroku-grade developer experience, which is the best trade in this entire post.
• You want the machines to manage themselves: look past all three, to declarative fleet tooling built on Cluster API — where adding capacity means editing a manifest, not opening a hosting panel.

The Heroku dream was never really about git-push deploys. It was about not thinking about servers. Each generation of self-hosted PaaS has pushed the "servers" one layer further from the developer's face — and there is exactly one layer left to go.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.