Four PaaS on One Server: What the 2026 Self-Hosted Boom Gets Right, and What Breaks at Machine Two

Every 2026 roundup of self-hosted Heroku alternatives names the same four tools: Coolify, Dokploy, Dokku, and CapRover. They are all good at the thing they were designed for — turning one server you rent into a platform that takes a git push and returns an HTTPS URL. The roundups almost never ask the follow-up question that decides whether you still like your choice in eighteen months: what happens at machine two, and can an AI agent operate any of this without you watching?

This post is the comparison I wanted to read before picking. It runs the four incumbents plus bex across the three axes that actually separate the category — the multi-machine story, Docker Compose versus Kubernetes portability, and how deep each tool's agent and MCP surface really goes — and it is honest about where bex loses today, not just where it wins.

The scoreboard, up front​

Star counts and release numbers move; the architecture rows do not. Keep that table in mind, because the rest of this post is the explanation of why the bottom three rows matter more than the top three.

Coolify: the polished default, and its ceiling​

Coolify earned its spot at the top of every roundup. Version 4.0, shipped in April 2026, brought a redesigned dashboard, more than 280 one-click services, and an instance-level MCP server; v4.1 followed with Railpack-based builds and structured audit logging. For a solo developer or a small team putting a first app on a single VPS, it is the safest all-purpose pick in the category, and its community is by far the largest — roughly 45,000 stars and the most answered questions when something breaks at midnight.

The ceiling is architectural, not a matter of polish. Coolify speaks Docker Compose, and Compose does not have a scheduler. Multi-server deployments work by attaching remote servers over SSH to a single Coolify control plane, which makes that control plane — and the /data/coolify/ directory holding its configuration, keys, and certificates — a single point of failure you now have to back up yourself.

Swarm support exists but is flagged experimental by the project's own ecosystem, there is a known gotcha around needing a registry before builds propagate to remote servers, and there is no Kubernetes support on any roadmap worth planning around. The v4 MCP server, the feature that supposedly closes the agent gap, ships read-only tools for inspecting resources — your agent can look, but it cannot deploy.

None of this is a criticism of what Coolify is. It is optimized for simplicity at small scale, and it delivers exactly that. It becomes a problem only when a team mistakes "runs my first app beautifully" for "runs my platform indefinitely."

Dokploy: the sharp challenger with pre-1.0 edges​

Dokploy is the tool most likely to be recommended at you by someone who tried Coolify and wanted something leaner. It is TypeScript rather than PHP, its UI is cleaner, it treats Docker Compose as a first-class citizen instead of an import format, and unlike Coolify it is Swarm-native — multi-server clustering is the default posture, not an experimental add-on.

It also ships things Coolify explicitly lacks: volume backups, built-in monitoring, and finer-grained permissions. On the agent axis it leapfrogged everyone: its official MCP server exposes the entire Dokploy API, a reported 508 tools across 49 categories, against Coolify's read-only handful.

The discount rate on all of that is maturity. Dokploy is still pre-1.0 (v0.29.x as of May 2026), and 2026 was the year that showed what pre-1.0 means in production: its worst CVE wave landed in May and June, and operators reported open data-loss bugs in the restore path — the one path you never want to discover is broken during an incident. Its community is large and growing fast but still roughly half Coolify's size, which matters precisely when you hit those bugs. Teams that evaluated both for production use this year tended to land in the same place: Dokploy's footprint and Compose fidelity are genuinely better, and Coolify's security track record and community depth outweigh that until Dokploy's 1.0 line hardens.

Watch this space more than any other in the category. If Dokploy survives its hardening year with the API-covering MCP intact, the agent-operated gap the rest of this post describes gets much narrower.

Dokku and CapRover: the veterans that still earn their keep​

Dokku and CapRover are the two answers from before the boom, and both still win the workloads they were built for.

Dokku is the mini-Heroku: git push over SSH, Cloud Native Buildpacks turning source into containers, SSL and routing handled behind the scenes, all on a VPS so small it barely registers on the invoice. Its plugin ecosystem — databases, storage, domains, checks — is the most mature in the category because it has had a decade to accumulate. What it will never be is a fleet: single-server operation is the design, not a limitation waiting on a roadmap, and the only multi-node story is a community scheduler-k3s plugin that swaps the simplicity you came for with Kubernetes complexity you were avoiding.

CapRover is the battle-tested middle child, running since 2017. It is Swarm-based even on a single node, which means clustering was never bolted on, and its one-click app templates plus captain-definition deploys have a "just works" reputation earned over years of quiet production use. The price is visible in the screenshots: a dated UI, a slower release cadence, weaker Compose support than either modern rival, and no MCP story at all — its automation surface is a conventional API and CLI.

Pick Dokku when the workload is one small thing on one small box and you value buildpack maturity over dashboards. Pick CapRover when you value "has not surprised anyone since 2019" over feature velocity. Neither is the wrong answer; both are honest about what they are.

The machine-two seam: what concretely breaks​

Here is the failure list nobody puts in a roundup. The day your first server fills up — or the day you want staging separated from production, or a GPU node for inference next to your CPU pool — the single-box tools make you re-solve problems a scheduler was invented to own:

• Placement stops being automatic. Compose puts containers on a host; it does not decide which host. Bin-packing tenants across machines, respecting affinity, and rescheduling around a dead node become your runbooks, not the platform's reconciler.
• Builds need a registry. On one box the image is just there. Across SSH-attached remotes, builds silently fail to propagate unless a registry is configured — a documented Coolify multi-server gotcha that reads as a mystery outage the first time.
• The control plane becomes the blast radius. One Coolify instance holds every server's keys and certificates. Backing up /data/coolify/ is now your most important cron job, and restoring it is a procedure you will practice exactly once — during the incident.
• Experimental clustering carries experimental failure modes. Swarm support flagged experimental means the multi-server path gets the least testing and the most surprising breakage, which is the opposite of where you want risk concentrated.

A Cluster API-based fleet is built to not have this seam: machines are declarative objects with lifecycle, health checks, and upgrades, so adding the second server is the same API call as managing the first. That is genuinely more machinery — Kubernetes underneath instead of Compose on top — and for one app on one box it is overkill.

The honest framing is cost timing: the Compose tools minimize cost today and concentrate it at machine two; the fleet model pays some complexity up front and keeps the marginal machine boring.

The agent test: who can the operator actually call?​

"Has an MCP server" now appears in comparison tables the way "has an API" did five years ago, and it deserves the same skepticism. The question is not whether an agent can connect; it is what the tool contract lets the agent do, and with what guardrails:

• Coolify (read-only): the agent can inspect resources and search docs. Useful for "what is running and is it healthy," useless for "ship the fix and roll back if the health check fails."
• Dokploy (full API): 508 tools covering the whole API is the deepest third-party surface in the category. Breadth is real, but every tool inherits the API's own authorization model — there is no agent-specific scope story, so "let the agent deploy" and "let the agent touch everything" are uncomfortably close together.
• Dokku / CapRover (none / DIY): SSH and CLI wrapped by whatever harness you build yourself. Maximum flexibility, zero contract, all of the audit logging is your problem.
• bex (scoped, read-write): the MCP server speaks the same Render-compatible API as the dashboard and CLI, but agents authenticate through OAuth scopes — read-only inspection, mutation, and secrets access are separate grants — and workspace roles restrict every call. The deploy-from-chat loop (inspect service, read logs, apply a planned deployment, roll back on failed health checks) is a designed path, not an API key with ambition.

The bar that matters: can an agent take a running service from "broken" to "fixed and verified" while the audit log shows exactly which calls were the agent's? Read-only surfaces fail the first half; unscoped full-API surfaces fail the second. That distinction — not the checkbox — is what "agent-native" has to mean before it is marketing.

The honest scorecard: where bex loses, and who should pick what​

No honest comparison written from inside bex gets to skip this section. Today, Coolify's dashboard polish and 280-service catalog beat bex outright — if your team picks infrastructure partly by how the UI feels on day one, Coolify wins that evaluation. Dokku's buildpack maturity beats bex for the narrow "turn this repo into a container without thinking" case.

Dokploy's full-API MCP currently exposes more endpoints than bex's curated tool surface. And all four incumbents are simpler to install, because a control plane that provisions machines is inherently more to stand up than a script that manages the box it runs on.

The pattern: the category optimizes for day one, and day one is genuinely important — most projects die before machine two. But the teams that survive day one inherit their platform choice, and the cost of guessing wrong is a migration under load. If you can already see the second machine, the GPU pool, or the agent doing deploys while you sleep, pick the tool whose architecture already lives there.

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.