Dokku Is Still Here After a Decade of Panel Waves: What the Original Single-Box PaaS Says About Coolify's 58K Stars and the Second-Machine Moment

In June 2013, Jeff Lindsay published a shell script under 100 lines long and called it "the smallest PaaS implementation you've ever seen." Thirteen years later, Dokku is shipping version 0.38.x, its plugin ecosystem still gets commits every month, and Heroku-compatible git push deploys still work the way they did when the project was stitching together Docker, Buildstep, and gitreceive. Meanwhile the tools that were supposed to replace it keep arriving in waves — and replaying the same playbook with a newer UI.

Here is the scoreboard as of mid-2026:

Star counts for Coolify, Dokploy, and CapRover come from a June 22, 2026 snapshot; Dokku's last widely cited count is from September 2024. The direction matters more than the digits: the single-box self-hosted PaaS is not a stepping stone the industry is leaving behind. It is the default answer to "I want Heroku, but on my server" — and it keeps winning that vote.

So this post is not a eulogy for single-box tools or a hit piece on panels. It is the other thing: an honest inventory of where Dokku's decade of survival says these tools plateau, why Coolify and Dokploy inherit the same ceiling, and how to treat "start on a panel, graduate to a declarative fleet" as a continuity story instead of a replatform. If you are a Render or Heroku leaver picking your first self-hosted home, that is the map you actually need.

What Dokku's survival actually proves​

Dokku survived for a boring reason that turns out to be the important one: it nailed an interface and refused to move it. git push dokku main deploys a Heroku-compatible app. Buildpacks turn source into an image. A plugin installs Postgres. That contract has held since 2013, which means a Dokku app from 2018 still deploys on Dokku 0.38 — and, just as importantly, still deploys on Heroku, or on anything else that speaks buildpacks and Procfile-shaped processes.

The plugin model did the rest. Dokku core stayed small while the ecosystem absorbed the long tail: Postgres, Redis, MySQL, Mongo, Let's Encrypt, and dozens of community schedulers and integrations. Official plugin repos were still landing commits in June 2026, and Dokku core itself picked up fixes like the scheduler-k3s scaling corrections through the summer. A thirteen-year-old project does not get that kind of maintenance unless real production workloads depend on it.

There is a second, quieter proof of durability: Dokku grew its own escape hatch. The old external dokku-scheduler-kubernetes plugin is deprecated in favor of a scheduler-k3s plugin shipped in Dokku core, which deploys apps to Kubernetes via generated Helm releases, with KEDA-backed autoscaling configuration managed through scheduler-k3s commands. Dokku's maintainers understood something the panel wave is still learning: the way to keep a single-box tool relevant is to give its users a door out of the single box that does not require abandoning the workflow.

The plateau checklist: five signals you have hit the single-box ceiling​

Single-box tools plateau in the same five places, regardless of which logo is on the panel. Run through this list honestly the next time you add an app:

1. One-machine blast radius. Every app, every database, and the panel itself share one kernel, one disk, and one network interface. A runaway build consumes the CPU your production apps need; a disk-full event takes down Postgres and the control plane together; a kernel upgrade is a maintenance window for everything. Coolify's own community runbooks warn against running builds on the same server as production apps for exactly this reason. Backups help, but restoring a whole box is disaster recovery, not high availability.

2. Same-box add-ons. The one-click Postgres is a container on the same disk as everything else. That is fine for a side project and genuinely convenient — until you need a Postgres upgrade without app downtime, point-in-time recovery, or a replica on different hardware. Plugin-maintained add-ons optimize for install speed, not for the day-two operations a stateful service eventually demands.

3. Multi-server is SSH plus hope. Coolify can manage remote Docker hosts over SSH, and both Coolify and Dokploy offer Docker Swarm clustering — but Swarm support is explicitly experimental in Coolify, and the broader community verdict on Swarm-based panels is consistent: workable for a few nodes, fragile beyond that. There is no declarative machine lifecycle anywhere in this stack. Adding a server means provisioning a VM by hand, joining it over SSH, and remembering which apps live where. Nobody reconciles desired state against actual state, because desired state was never written down.

4. No fleet story for the machines themselves. OS patching, Docker upgrades, certificate rotation, and node replacement are per-box chores. There are no MachineDeployments, no rolling node upgrades, no health-checked machine replacement. A 2026 comparison of the self-hosted panels rates every one of them "limited, single-node" on the multi-node scale path — CapRover gets "Swarm scaling, fragile beyond a few nodes" as its slightly better grade. That is not a missing feature. It is the architecture.

5. Security blast radius equals the box. When researchers disclosed 11 critical Coolify flaws in January 2026 — authentication bypass and remote code execution on self-hosted instances — the severity came from the architecture, not just the bugs: compromising the panel meant compromising every workload on the box. Every panel vendor patches quickly, but the blast-radius math is structural. One box, one compromise domain.

None of this is an argument against starting on a single box. One developer, a handful of apps, tolerant downtime windows — that profile may never outgrow Dokku or Coolify, and paying fleet complexity tax for it would be the actual mistake. The checklist is a tripwire, not a verdict: when two or three of these start hurting at once, you have arrived at the second-machine moment, and it is time to plan the graduation instead of bolting another workaround onto the box.

The 2026 panels replay the playbook — and inherit the ceiling​

Coolify at ~58,000 stars and 481,000-plus instances is the category leader by adoption and breadth. Dokploy went from zero to ~35,000 stars in roughly two years. Both wrap Docker with a web UI, Traefik as the HTTPS-by-default reverse proxy, Git-based deploys, and a catalog of one-click services. CapRover has held its ~15,000-star niche since 2017 with the same essential shape.

Feature for feature, the panels are better products than Dokku ever was for their audience: visual service management, preview deployments, multi-server SSH management, a dedicated remote build server in Coolify's case. But architecturally they are Dokku with a UI — the deploy target is still a Docker daemon on a box you manage, the databases are still containers on that box, and the multi-machine story is still SSH plus experimental Swarm. The ceiling did not move. The room under it just got nicer.

That is why Dokku's survival is diagnostic rather than nostalgic. If the panels had solved a structurally different problem, the thirteen-year-old CLI tool would be a museum piece. Instead it keeps shipping, because the problem it solves — first machine, git-push workflow, minimal moving parts — is the same problem the panels solve, and neither generation claims the second machine.

Graduation as continuity, not replatform​

Here is the reframe that matters for Render and Heroku leavers: moving from a panel to a declarative fleet should carry over almost everything you built. The artifacts are the same; only the scheduler and the machine lifecycle change.

Dokku already proved the continuity thesis in miniature: its scheduler-k3s plugin keeps the git push workflow and swaps the deploy target to Kubernetes. A Cluster API fleet is the same idea carried through to the machines — MachineDeployments give you the rolling upgrades, health-checked replacement, and declarative desired state that no panel's SSH list ever will, while your containers, config, and routing intent come along unchanged.

The practical version of this story has three stages, and you should only pay for the stage you are in. Stage one is the panel on one box: cheapest, simplest, correct for as long as the plateau checklist stays quiet. Stage two is the panel's own multi-server features — remote build host, a second app server over SSH — which buys headroom while teaching you which workloads actually need isolation. Stage three is the declarative fleet, adopted when machine lifecycle itself becomes the toil: that is when desired-state reconciliation starts paying for its complexity, and not before.

The honest migration story​

Dokku's decade teaches one lesson the star counts obscure: the tools that last are the ones that make leaving them cheap. Heroku-compatible deploys, standard OCI images, boring Postgres dumps — every one of those is a door. The panels inherited Dokku's doors along with its ceiling, which is why "start on Dokku or Coolify, graduate to a Cluster API fleet" works as a continuity story. Nothing you build on the first machine is wasted; it all replays on the fleet with a better scheduler underneath.

So pick the panel with confidence, run the plateau checklist quarterly, and when the second-machine moment arrives, graduate the scheduler — not the apps.

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.