Coolify vs Dokploy After a Real Migration: What the Same Laravel App on Two Identical Hetzner Boxes Reveals

Every Coolify-versus-Dokploy comparison you have read is a feature matrix. Someone tabs through two dashboards, ticks the same boxes — git deploys, one-click databases, automatic HTTPS — and declares a winner on vibes. A late-September migration report by Qasim Parray did the thing nobody else bothered to do: two identical Hetzner CPX21 boxes, Coolify on one, Dokploy on the other, and the same small Laravel app plus Postgres deployed to both. Same hardware, same workload, real migration scars.

The headline result first, because it is the whole post in miniature: on identical hardware, both panels run the app fine, and the differences that actually matter are the database restore button and build speed — not the feature list.

That table is the promise of this post kept early. The rest is what each row actually means — and where the twin-box result confirms versus complicates our September 19 second-machine showdown.

The experiment, and why identical hardware matters​

The setup is deliberately boring, which is what makes it evidence instead of anecdote. Two Hetzner CPX21 cloud servers — 3 AMD vCPUs, 4 GB RAM, 80 GB NVMe, 20 TB of traffic, roughly €8 a month each — one per panel, both installed with the vendor's own curl-piped script. The workload is a small client staging app: Laravel plus Postgres, expressed as one plain compose file with an app service depending on a postgres:17 service, imported as-is on both sides.

Fixed hardware is the entire methodological point. Panel comparisons usually conflate two variables — the software and the box underneath it — so "Dokploy felt slower" might mean the VPS was throttled, noisy-neighborred, or on spinning rust. Here the box is a constant, which means every delta below is the panel's own behavior: its install path, its build pipeline, its database UX. A €16 experiment that isolates the variable every feature matrix ignores.

That is also what makes the "wash" verdicts meaningful. When both panels attach a custom domain with automatic HTTPS within a couple of minutes of DNS pointing at the box, that is not two vendors' marketing agreeing with each other — it is the same outcome measured twice on the same tin.

Install friction: four minutes, but different architectures underneath​

Both installs are a single curl-to-bash line, both finish in about four minutes, and the minute-and-a-half gap between them is the least interesting part. The interesting part is why Dokploy takes longer: it stands up Docker Swarm mode even for a single-node install, while Coolify only reaches for Swarm once you attach a second server.

That is not an install detail. It is an architecture thesis leaking through the installer. Dokploy's Swarm-first design means multi-node scaling is the default topology with one node in it, rather than a mode you graduate into later. Coolify's per-server-over-SSH model treats the single box as the default and the fleet as an extension. Neither is wrong — the migration author notes Dokploy would be the better starting point if the client ever needs true multi-node Swarm scaling from day one — but the installer tells you which future each project is optimizing for before you have deployed a single app.

For the staging-server job at hand, both verdicts round to "fine." A freelancer billing by the hour will not feel 90 seconds. But file the difference away, because it resurfaces in the multi-server section below as the one structural fork in the road.

The deploy loop: Railpack's 40 seconds versus Nixpacks' minute​

This is the section the feature matrices get most wrong, because "supports buildpacks" is a checkbox and build latency is a daily tax. Both panels auto-detected the Laravel app's PHP runtime and produced a working image with no Dockerfile. Coolify's Railpack build finished in about 40 seconds; Dokploy's Nixpacks build took just over a minute, with the gap attributed to Railpack caching Composer layers more aggressively by default.

Twenty seconds sounds like nothing until you multiply it by the author's actual cadence: a dozen redeploys a day during active client work. That is the deploy-pipeline behavior that matters on a single-box panel — not the trigger mechanism (git push rebuilds on both, plus Coolify's MCP server as an alternate redeploy trigger an AI agent can drive directly) but the iteration loop. A faster rebuild loop is a compounding advantage measured in sustained attention, not seconds.

And then the honest caveat that redeems the whole section: neither buildpack won. Once the app needed a custom PHP extension neither buildpack shipped, the author fell back to a hand-written Dockerfile on both panels — where, naturally, the build-strategy gap evaporated. The representative lesson is not "Railpack beats Nixpacks" but something narrower and more useful: buildpack speed decides your iteration tax right up until the day your app outgrows buildpacks, and on that day both panels converge on the same Dockerfile you already trust.

One explicit scope note: the migration never exercised rollback-after-a-bad-deploy on either panel, so this post claims no rollback verdict. That is a gap in the evidence, not a tie — do not read silence as parity.

Database provisioning and restore: one-click in, one-click out?​

Provisioning is close to a wash with a meaningful lean. Both panels provision the same list of engines — Postgres, MySQL, MariaDB, Redis — and both back them up to S3-compatible storage. Coolify's edge at provision time is that the backup destination and schedule live in the same UI flow as the database itself; Dokploy gets you a running database just as fast.

Restore is where the migration's verdict actually lives, and it is the single biggest delta in the whole experiment. Coolify restores a specific backup point-and-click from the dashboard. Dokploy's restore flow currently routes through the CLI rather than a full dashboard restore. For the author's client — who is never going to SSH into anything — that is the difference between "she can restore last night's backup herself" and "she has to text me."

Dwell on that framing, because it reframes the entire panel decision for freelancer-and-client shops. The database question is not which engines are supported or whether backups exist; both panels clear that bar. The question is who can perform the restore at 11pm, and whether that person needs a terminal. Every self-hosted PaaS demo provisions a database. Almost none of them demo the restore. This migration did, and the restore is what picked the winner.

The author's standing advice generalizes beyond either panel: manually trigger a database restore into a throwaway app once, before you need it for real. He found Dokploy's CLI restore step only after needing it under pressure, which he correctly identifies as the worst possible time to read docs for the first time.

Day two: velocity is a wash, changelog discipline isn't​

Both projects ship at a pace that would embarrass most SaaS vendors. At writing time Coolify sat at v4.3.23 with four patch releases in the preceding two weeks and roughly 62,000 GitHub stars; Dokploy at v0.30.7 on a similar cadence with about 37,500 stars, roughly a year and a half the younger project. Neither cadence is a red flag — real bugs get fixed in days — but both demand the same operational discipline: read the changelog before clicking update on a client's box.

The author earned that rule the hard way, treating a Coolify minor bump as routine and losing a custom Traefik label override that a new default had quietly replaced. That anecdote deserves more weight than the version numbers, because it names the actual day-two tax of fast-shipping panels: not instability but silent default changes. Pin versions on client infrastructure, diff the changelog, and re-verify proxy overrides after every update — on either panel, since Dokploy ships just as fast.

The remaining day-two surface splits cleanly. Custom domains with automatic HTTPS: a wash, minutes on both. Team access: Coolify's native team roles let the author hand a client's other contractor deploy access without handing over root, which Dokploy's Swarm-leaning model answers with Swarm's own primitives — more powerful if you already think in Swarm, more friction if you do not. And Coolify's bundled MCP server means routine restarts and status checks can skip the dashboard entirely via an AI agent, a small thing that compounds exactly like the build-speed gap.

Where this confirms — and complicates — our second-machine showdown​

Our September 19 showdown worked out the concrete second-machine play for Coolify, Dokploy, CapRover, and Deploynix: about $12 a month for the second box on any self-hosted panel, different join mechanisms, and the shared gotcha that every panel leaves your database on one disk. The twin-box migration is the ideal follow-up experiment because it holds the box constant at one machine and asks what differs before server two ever arrives. Three confirms, two complicates.

Confirmed: the mechanism gap is real. The showdown described Coolify's SSH-attached servers versus Dokploy's Swarm-join as different philosophies; the migration felt the difference at install time, when Dokploy stood up Swarm on a single node. Same fork, observed one machine earlier.

Confirmed: the database is still the decision. The showdown's shared gotcha was that no panel replicates your database to the second machine. The migration finds the single-machine version of the same truth: the database differentiator is not engines or backups but who can run the restore. One disk or two, the panel decision keeps coming back to Postgres.

Confirmed: cost is identical on the same box. Two CPX21s at ~€8 each is ~€16 whether Coolify or Dokploy sits on top; both panels are free self-hosted. The showdown's cost analysis survives untouched — price never enters this decision until managed tiers do.

Complicated: the frame was run-versus-rent, but buyers decide on restore UX. The showdown (via Deploynix's original) framed the real question as whether you run the control plane or rent it managed. The migration suggests single-box buyers — the overwhelming majority of both panels' users — actually decide on the restore button and the rebuild loop. The control-plane question matters at server two; most buyers never get there.

Complicated: Swarm-first versus SSH-first matters less than claimed — until it matters all at once. Both vendors' positioning implies the multi-server model should drive the pick. The migration shows a client staging server running happily for months under either model, with the fork only biting at scaling day. That does not make the models equivalent; it makes the choice reversible-for-longer than the marketing suggests, which is genuinely useful information for anyone picking under uncertainty.

The verdict, and the one thing to do this week​

The author's pick rule survives this site's read intact: Coolify for the client-handoff job, where one-click restore and a faster rebuild loop compound daily; Dokploy where Swarm-first multi-node scaling from day one is the actual requirement rather than a someday-maybe. Either removes real pain over hand-rolled compose files and Caddy configs, and neither pick is embarrassing.

But the durable output of this migration is not the pick — it is the checklist it implies for evaluating any single-box panel. Time the rebuild loop, not the install. Demo the restore, not the provision. Read the changelog before every update, and pin versions on anything a client depends on. Do those four things and the panel mostly picks itself.

And the one thing worth doing this week regardless of which you picked: manually trigger a database restore into a throwaway app once, before you need it for real. Identical hardware, identical app — and the restore path was still the thing found under pressure. Fix that on your own box before your client finds it on theirs.

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.