The Self-Hosted PaaS Cambrian Explosion: What 55 awesome-paas Entries Say About the Second-Server Problem

There are now 55 ways to turn a server you own into a platform — and almost all of them stop at server number one. Debarshi Basak's awesome-paas list, last verified on July 29, 2026, tags every entry alive or defunct, and its self-hosted section reads like a census of a Cambrian explosion: 48 living projects, 7 graves, and a steady trickle of new entrants that all solve the same first problem brilliantly. The question none of them answers well is what happens when your one server becomes two.

That is the question this post settles. Not "which panel should I pick" — there are good showdowns for that — but which ceiling you are actually buying, what concretely breaks at server number two, and why the fix is a different substrate, not a better panel.

The list by the numbers​

The self-hosted section of awesome-paas holds 55 entries: 48 alive, 7 defunct. The shape matters more than the count. The overwhelming majority cluster around one architecture: a control plane that drives Docker on machines you provisioned yourself, over SSH, one box at a time. Coolify, Dokploy, Dokku, CapRover, Easypanel, ZaneOps, Peon, Piku, Uncloud, JustDeploy — different UX philosophies, same substrate assumption.

The new wave keeps arriving in the same shape. Mooring is a security-first control plane for Docker where you describe a multi-service app in one typed mooring.yaml — explicitly without Docker Swarm or Kubernetes. Temps ships deploys, analytics, error tracking, and session replay in a single Rust binary. Both are genuine improvements on the single-box experience: safer defaults, fewer moving parts, faster setup.

The Kubernetes-native entries are a visible but small minority: Deckrun ("deploy and manage apps on Kubernetes with one config file and one command"), Kubero, Canine, OpenRun, Devtron, Plural. OpenRun is the most honest about the seam — it supports "a single node or Kubernetes" as two explicit modes, because it knows they are two different products wearing one brand.

And the 7 defunct tags are doing quiet work: Flynn unmaintained, Hephy's site offline, Kubeless archived, Argonaut's domain now serving an unrelated product, Setops offline, Stacksnap returning 404, Azure Krustlet abandoned since 2023. In a Cambrian explosion, most species go extinct. Picking a panel is also betting it stays alive.

What adding server #2 actually breaks​

Here is the core deliverable: how the second server joins, per tool, and what stays manual afterward.

Five things break, in every row except the last:

1. Provisioning. Buy the machine, install the OS, harden it, install Docker, register it in the panel. By hand. Per box. The panel manages servers; it does not create them.
2. Placement. You pick the target server per app in a dropdown. There is no scheduler reasoning about bin-packing, affinity, or headroom — you are the scheduler.
3. Remediation. When a box dies at 3 AM, nothing re-provisions it. There is no MachineHealthCheck equivalent watching the fleet and converging back to declared state; there is a dashboard showing red and a human with an SSH key.
4. Declarative state. The panel's database is the source of truth for the fleet. You cannot git diff your infrastructure, review it in a PR, and let controllers converge reality to it.
5. Data. The database on box A does not fail over to box B. Backups, replication, and restore are per-install concerns the panel helps with but does not make fleet-aware.

None of this is a bug report. Dokku never promised you a fleet; Mooring's single-machine focus is a deliberate design choice, and a defensible one.

The point is that the ceiling is architectural, shared across nearly the whole list, and invisible on day one — when every demo deploys beautifully to server number one.

Why the seam doesn't close on its own​

The natural objection is patience: these projects ship fast, so surely the fleet story arrives eventually. Coolify is the test case, because it has the most momentum — roughly 57,300 GitHub stars as of June 2026, a v4.0.0 release in April 2026, self-hosted free forever with an optional $5/month Cloud tier for the dashboard.

And its multi-server story today is exactly "manage several servers from one UI," with reviewers noting the honest caveat: no autoscaling, because multi-node isn't clustering. That caveat has survived every release so far.

Meanwhile the Kubernetes promise has been on the roadmap since the 2022 Show HN for Coolify v2: "Support Kubernetes, so you can scale to infinity and beyond!" Four years later it is still described as "on the horizon." That is not a criticism of the maintainers — bolting a second, declarative substrate onto a mature SSH-driven product is genuinely a second product. It is evidence that the seam doesn't close by waiting. The architecture that makes these tools great at box one — direct SSH control, panel-owned state, Docker-shaped assumptions — is the same architecture that makes box N a manual exercise.

The churn in the list reinforces the point from the other side. Seven graves in one section, and the living entries include projects whose entire pitch is "the previous fork, but maintained." Betting your fleet story on a panel's roadmap means betting the panel survives long enough to build a second product. Some will. The list's defunct tags show that many won't.

The exception that proves the rule​

The K8s-native minority in the list escapes most of the five-item breakage list — not because its authors are smarter, but because the substrate does the fleet work. When Deckrun deploys through Kubernetes, placement is the scheduler's job, dead nodes get cordoned and drained, and desired state lives in manifests you can version. Canine's pitch ("Heroku simplicity with Kubernetes power") and Kubero's existence say the same thing: the fleet ceiling lifts the moment the substrate is declarative.

The honest footnote is that Kubernetes charges its own complexity bill — which is precisely why the single-box tools exist and thrive. A $5 VPS, a free panel idling at around 1 GB of RAM (Dokploy trims that to roughly 0.8 GB), and a git push that just works is a genuinely great deal for a side project or a first app. Nobody should run a control plane to serve a weekend project. The K8s-native tools aren't "better" in any absolute sense; they price the fleet story into day one, and for many teams that price exceeds the value until server two shows up.

That is what makes OpenRun's two-mode framing the most clear-eyed in the list. Single node and Kubernetes aren't tiers of one product — they're different answers to "who manages the machines," and pretending otherwise is how teams discover the seam at the worst possible moment.

What a Cluster-API fleet does differently​

Now the side-by-side that the whole post has been building toward: the day you add capacity.

The panel flow. Notice load or plan headroom. Buy a machine. Install and harden the OS. Install Docker. Add its SSH key to the panel. Register it, validate it, then go app by app deciding what moves where. Update the database story by hand. Verify TLS, volumes, and backups on the new box. Every step is a human step, and step zero — "buy a machine" — never enters the system at all.

The Cluster-API flow. Edit one manifest: the MachineDeployment replica count goes from 3 to 4, or the autoscaler bounds widen. Controllers provision the machine from a template, bootstrap it, join it to the cluster, and start health-checking it. Placement is the scheduler's job against declared constraints. If a machine dies, remediation deletes the failed Machine object and converges a replacement — the same reconcile loop that created it, running without a human in the path. The fleet's desired state is a git-reconcilable artifact: provision, place, remediate, and declare are all API objects, not runbook steps.

The difference is not "Kubernetes versus Docker." It is who owns the machine lifecycle. In the panel world, machines are pets you register; the platform starts at the container. In the Cluster-API world, machines are cattle the platform itself provisions; the lifecycle — create, join, watch, replace, delete — is declarative all the way down to the bare metal or VPS API. That is the exact seam the single-box wave is built on top of, and the exact seam a fleet-native platform is built to not have.

Note the symmetry with the list's own evolution: the tools that grow a real multi-machine story (Deckrun going straight to K8s, OpenRun's second mode) all converge on the same insight — at some machine count, SSH-and-dropdowns must give way to declare-and-reconcile. Cluster API just starts there.

Pick your ceiling on purpose​

The awesome-paas list will keep growing, and that is good news: the single-box experience has never been better, and competition among 48 living projects keeps it sharp. But every new entrant should be asked one question before adoption: show me server number two. Not the multi-server docs page — the actual flow, including who provisions the box, who places the workload, and what happens at 3 AM when the box dies.

A rough decision framework:

• Single-box is right when the app count is small and stable, load is predictable, the team fits in one chat channel, and the cost floor matters more than the growth ceiling. Side projects, first apps, internal tools — the panel world is the rational pick, and the list gives you dozens of good options.
• Plan the seam when the second app has different scaling needs than the first, when anyone says "high availability" in a planning meeting, when the team grows past the people who remember which app lives on which box, or when GPU, batch, or bursty agent workloads appear on any roadmap. You don't need the fleet on day one — but you need the migration to be a promotion, not a replatform.

Fragmentation is only a problem if you mistake 48 options for 48 different ceilings. Read the list again and there are really two: tools that manage the boxes you built by hand, and substrates that build the boxes from declarations. Choose knowing which one you're standing on.

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.