Dokploy in 2026: How Close Is Single-Server PaaS to Cluster API?

The most interesting number in self-hosted PaaS this year is not a star count. It is a ceiling: Dokploy, the Docker Compose-native PaaS that started as a one-VPS Heroku alternative, spent 2026 adding almost everything a small platform team asks for — remote servers, preview environments, external secrets, AI-assisted log analysis — while still, at its core, deploying containers onto machines you provisioned by hand. The question is no longer "can Dokploy do what I need" but "which of these additions actually move the ceiling, and which are fresh paint on the same single box?"

Here is the short answer, with the evidence below.

The pattern: everything Dokploy added in 2026 makes operating the machines you already have dramatically nicer. Nothing in the list provisions a machine, declares desired state for a fleet, or reconciles drift when reality diverges from the manifest. That is the line, and it has not moved.

What Dokploy actually shipped in 2026​

A quick inventory of the year, so the verdicts above are checkable rather than vibes.

Multi-server went from checkbox to workflow. Dokploy's Swarm-native multi-server support — a manager running the panel plus worker servers joined over SSH — matured through the v0.29 line, and v0.29.0 (April 2026) added non-root support, so remote servers no longer need root SSH access, just a user with passwordless sudo. A June 2026 hands-on comparison against Coolify v4.0.0 put it plainly: pick Dokploy for "native multi-server support, and standard Docker Compose handling," with Swarm still labeled experimental on the Coolify side.

Compose handling stayed the differentiator. The same comparison confirmed the operational detail that matters most to teams arriving with a real docker-compose.yml: Coolify's zero-downtime deploys work only via Dockerfile, Nixpacks, or single-image deploys — Compose stacks get stop-then-start, with rolling support deferred to a v5 roadmap — while Dokploy deploys a standard Compose file with little to no modification and does not trigger a full rebuild on container stop/start. For a Compose-shaped team, that is the whole evaluation.

Secrets grew up. The v0.30 line (current at v0.30.5 in early September 2026) brought external vault providers — HashiCorp Vault/OpenBao, Infisical, AWS Secrets Manager and Parameter Store, among six supported backends — so secrets can be sourced at deploy time instead of living in the panel database. It also deprecated the old Isolated Deployment toggle in favor of explicit per-service Docker networks, which is the kind of unglamorous correctness fix that signals a maturing project.

The workflow layer thickened. Preview deployments isolate per-PR state (a named volume like app-data becomes app-data-<pr-suffix>, so each preview gets its own data and teardown cleans it up), the one-click template catalog passed 518 entries, and v0.29.0 added AI analysis of logs and build errors. Around the API, a small ecosystem of community MCP servers and a community Terraform provider now let AI agents and IaC pipelines drive Dokploy instead of clicking the dashboard.

The license changed, and the roadmap with it. On January 21, 2026, Dokploy restructured to a standard Apache 2.0 core plus a separate Source Available license for proprietary/ directories. The features named for the paid side are worth reading carefully: SSO/SAML, white-labeling, audit logs — and high availability, auto-scaling, and disaster recovery. The platform's own roadmap concedes that the fleet-level primitives are the premium tier, not the core.

For context on scale: roughly 34,000 GitHub stars against Coolify's roughly 55,000 (June 2026 figures), idling at a community-reported 300–400 MB of RAM. Dokploy is the leaner, Swarm-native panel; Coolify is the bigger ecosystem with the larger template library and pure Apache 2.0 throughout. Both install with one command on a 2 GB VPS.

What genuinely narrows the gap​

Three 2026 additions actually raise the ceiling rather than decorating beneath it.

Swarm-native multi-server is the real deal — within its scope. Before remote servers, "Dokploy" and "one VPS" were synonyms, and outgrowing the box meant migrating platforms. Now a Dokploy manager can spread services across worker nodes with Swarm rolling updates, which covers the most common growth story honestly: the team whose second machine is a bigger version of the first. Zero-downtime Compose deploys across boxes is a capability that used to require either Kubernetes or hand-rolled orchestration, and Dokploy now ships it in the free core.

Non-root remote access removes the security objection. Multi-server over root SSH was always a non-starter for careful teams; v0.29.0's passwordless-sudo model makes joining a second or third server something a security-conscious operator can actually approve. Adoption blockers count as ceiling when they gate the multi-machine story.

External secrets close an enterprise-readiness gap. Sourcing secrets from Vault, Infisical, or AWS at deploy time means Dokploy no longer needs to be the system of record for credentials — a prerequisite for any team with a compliance checklist. Combined with per-service networks replacing the old isolation toggle, the v0.30 line reads as Dokploy growing from "great for side projects" to "auditable enough for a small company's production."

Each of these changes what a team can run. None of them changes how machines come into existence — which brings us to the other column.

What is still polish on one box​

The rest of the 2026 list is genuinely good software that leaves the fundamental limitation untouched.

Templates multiply choices, not capacity. Five hundred eighteen one-click templates mean faster time-to-first-deploy for Postgres, Redis, or yet another AI proxy — on the same servers you already operate. A template catalog has never provisioned a node, and this one does not either.

Previews improve workflow, not fleet shape. Per-PR environments with isolated volumes are a top-tier developer experience, matching what Render and Railway sell as a premium feature. But every preview lands on the same Swarm you already run; a preview surge competes for the same CPU and disk as production, with no mechanism to burst capacity for it.

AI log analysis debugs faster within the same walls. Having the panel explain a failed build beats grepping logs at 2 a.m., but it is an observability convenience, not an infrastructure primitive. It cannot restart a dead node, reschedule around one, or tell you that you need another.

MCP servers and the Terraform provider automate the panel, not the platform. Community MCP servers that let an agent create apps, attach domains, and read logs through Dokploy's API are a real step toward agent-operated infrastructure — the agent follows Dokploy's actual rules instead of guessing CLI flags. But the API surface they wrap ends at the workload layer. No endpoint provisions a Hetzner server, joins it to the Swarm, labels it, and cordons the old one. Automating "deploy" without automating "machine exists" is half the loop.

The honest summary: Dokploy's 2026 made the box (or few boxes) you have dramatically more pleasant and more capable. It did not give you a second box on demand.

Where the line still sits​

Here is the explicit checklist — the capabilities that still require declarative multi-machine provisioning underneath, i.e. the Cluster API side of the comparison:

• Machine provisioning. Somebody still buys the VPS, installs Docker, joins it to the Swarm, and configures it by hand (or by scripts you wrote). Cluster API's whole premise is that machines are declarative objects: a MachineDeployment says "three workers of this shape," and controllers converge reality to match. Dokploy has no equivalent; its server list is an inventory you maintain.
• Desired-state reconciliation and drift repair. If a Dokploy worker's Docker config drifts, or a node dies overnight, nothing converges the fleet back to a declared state — there is no declared state for the fleet, only for the workloads on it. CAPI's reconcile loop (plus MachineHealthChecks that detect and replace failed nodes) is the primitive here, and it operates one layer below anything in Dokploy's model.
• Autoscaling and HA as core behavior. Dokploy's own licensing announcement places HA, auto-scaling, and disaster recovery on the paid Source Available side — acknowledging these are unsolved in the free core. On a CAPI-managed fleet, cluster-autoscaler-style capacity response and multi-replica control planes are table-stakes architecture, not a tier.
• Node lifecycle operations. OS upgrades, kernel patches, Docker version rollouts, and cordon-drain-replace cycles across the fleet are manual per-server work in Dokploy's world. A declarative machine layer rolls these as versioned, health-gated machine updates — the difference between "SSH into each box on a Saturday" and "bump a field and watch the rollout."
• Fleet uniformity at scale. Two or three hand-joined Swarm workers stay consistent through operator discipline. Past that, snowflake drift — different Docker versions, different sysctls, different disk layouts — becomes the tax on every deploy. CAPI fleets get uniformity from the machine template, not from memory.

None of this is a criticism of Dokploy's choices. A Compose-native panel that tried to also be a machine provisioner would be worse at both. The point is architectural: workload automation and machine automation are different layers, and 2026 added a great deal to the first while leaving the second exactly where it was.

Stay or move: a decision guide​

The variable that flips the answer is not app count or traffic — it is machine count and how often it changes.

Stay on Dokploy when: you run one to three apps (or a Compose stack or two) on a stable set of one to three servers; your capacity changes rarely enough that provisioning a box by hand twice a year is fine; your team wants git-push deploys, previews, and one-click databases without learning Kubernetes. This describes the large majority of self-hosters, and Dokploy's 2026 made this tier genuinely excellent — standard Compose, rolling updates, external secrets, and agent-friendly APIs at 300 MB of idle overhead is a combination nothing else in the space matches at this simplicity.

Start planning the move when: adding capacity is routine rather than exceptional; you need nodes to appear and disappear on schedule or on load; a dead node at 3 a.m. must heal without a human; or fleet uniformity across five-plus machines is becoming a part-time job. These are machine-layer problems, and no template count or MCP wrapper solves them — they are solved by declaring the fleet and letting controllers reconcile it.

The migration path is kinder than it looks: Dokploy-standard Compose files and container images transfer cleanly, and the discipline of external secrets and per-service networks carries straight over. The teams that struggle are the ones who wait until the Swarm is load-bearing for a dozen services before admitting the machine layer needs its own automation.

The gap that remains​

Dokploy's 2026 is a case study in doing one layer superbly: the workload experience on owned hardware has never been this smooth, from preview environments to agent-driven deploys. The comparison writeups narrowing the gap are right about everything except the conclusion — the gap they are measuring is developer experience, where Dokploy now rivals platforms far above its weight. The gap that remains is measured in machines: who provisions them, who heals them, and who notices when they drift. That layer still belongs to declarative fleet tooling, and Dokploy's own roadmap — with HA and autoscaling named as future paid features — agrees.

The pragmatic takeaway: run Dokploy with full confidence while your fleet fits in your head, and start learning declarative machine management the moment it stops fitting. The ceiling is higher than ever. It is still there.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with declarative multi-machine provisioning underneath instead of hand-joined boxes. Star the repo on GitHub or deploy your first app today.