Dora NodaYour platform-as-a-service is now an install flag. Not a project you evaluate, not infrastructure you operate — a checkbox in a VPS configurator, a --software key in a provisioning CLI, a button in a Deploy tab. In 2026, three separate installer moments made that official: Contabo added Dokploy and Coolify to its 1-click app catalog on a fleet that just crossed 500,000 VPS; the hlab lab-provisioning CLI shipped --software dokploy in its 0.10.6 release in July; and VPSBox put a four-panel picker — Coolify, Dokploy, Dokku, CapRover — one click away on a disposable local VM. (Contabo's catalog also lists the ZeroClaw agent runtime next to the panels; it is a neighbor in the catalog, not a PaaS panel, and worth naming so the comparison below stays honest.)
Each of these treats the PaaS panel as something you install like a package rather than something you operate like infrastructure. That distribution model is winning: it owns the moment a self-hoster goes from "I have a server" to "I have a deploy target," and that moment increasingly decides which panel they run for years. But installers optimize exactly one moment — the first deploy on the first box — and silently skip everything after it: upgrade cadence, backup and restore testing, and the second machine. This post walks the three installers side by side, names what the model selects for with concrete numbers, inventories the day-2 gaps at the installer level, and argues that any "fleet, not panel" platform has to meet installers where the self-hoster already starts instead of where the architecture diagram wishes they would.
Three installers, one optimized moment
| Installer | Trigger moment | Panels offered | What "done" looks like | Documented second-machine path |
|---|---|---|---|---|
| Contabo 1-click apps | Ordering (or reinstalling) a VPS/VDS | Dokploy, Coolify | Panel login on a fresh server, minutes after checkout | None — order another VPS; no fleet join step |
hlab --software (0.10.6, July 2026) | Provisioning a lab VM from the CLI | Dokploy, Coolify (plus Docker, k3s, runtimes) | Dokploy running via its official installer, Docker pre-installed | None — provision another VM; no join step |
| VPSBox Deploy tab | Clicking Deploy on a local sandbox VM | Coolify, Dokploy, Dokku, CapRover | Panel running on a disposable local Ubuntu VM (Multipass) | None by design — the sandbox is local-only, production is out of scope |
The pattern is the same in all three rows: a single action collapses "provision a machine, install Docker, install the panel, reach the login screen" into one step. Contabo does it at purchase time — pick Dokploy in the configurator or hit Reinstall on a server you already have. hlab does it as one key in a provisioning checklist, and its changelog is refreshingly explicit about the mechanics: selecting Dokploy also installs the Docker Engine first, because Dokploy's own installer tears down Swarm state and would abort on a bare box. VPSBox does it as rehearsal: boot a local VM that looks like a fresh VPS, try the panel, break things safely before renting anything real.
Note the preview of the argument in the last column. Every row's second-machine path is absent, and that absence is load-bearing for everything in the second half of this post.
What the model selects for: the fastest first deploy wins
Installers compete on exactly one metric — minutes from "I want a PaaS" to "my app is live" — and the numbers show why that metric dominates panel choice.
Contabo: minutes from configurator to panel login. The 1-click app ships with the server itself, so there is no SSH session, no curl | sh, no dependency ordering to get wrong. At 500,000 VPS and counting, Contabo's catalog decision is distribution at a scale no panel's own install docs can match: the panel a self-hoster meets in the configurator is the panel they deploy to first, and the first deploy has a way of becoming the production deploy. Contabo's own editorial voice reinforces the single-box framing — its 2026 "replace Heroku without Kubernetes" guide recommends Coolify, Dokku, Dokploy, and CapRover with the explicit note that all four run on a single VPS.
hlab: one flag added to a provision step. The --software dokploy key (alongside coolify, k3s, docker, and language runtimes) folds the panel into the same command that creates the VM. There is no separate install phase to schedule, document, or forget; the panel arrives with the machine. For lab and rehearsal workflows — the exact workflows where a team evaluates whether to self-host at all — collapsing install into provision removes the last reason to defer trying the panel.
VPSBox: one click onto a box you can throw away. VPSBox's contribution is removing even the VPS bill from the evaluation: the "server" is a local Multipass VM with real SSH and hostnames, and the Deploy tab installs the panel there. Trying all four panels is an afternoon, not a procurement cycle. When evaluation is this cheap, the panel with the smoothest first fifteen minutes wins before architecture ever enters the conversation.
The published install-time figures back up the shape of this competition: third-party comparisons put Dokploy's install at roughly three minutes and Coolify's at roughly four, with idle footprints (about 9% CPU and low-40s RAM usage on a small VPS in one 2026 test) close enough that neither panel loses on overhead. When installs differ by a minute and idle cost differs by noise, the differentiator is not the panel — it is whoever puts the panel one click closer to the self-hoster. That is what installers sell, and they are right to sell it: the fastest first deploy is the whole game at the starting line.
What the model silently skips
Here is the other side of the table. Each gap below is stated at the installer level — what re-running or revisiting the installer does about it — with panel-level quirks demoted to supporting notes, because the installer is the thing that claimed the relationship with the operator.
1. Upgrade cadence: the installer never comes back
Contabo: the 1-click path's revisit story is Reinstall — which wipes the server and starts over. That is a reprovisioning story, not an upgrade story. The panel, Docker Engine, and host OS all drift forward on their own schedules after day one, and nothing in the 1-click flow reconciles them. The operator who clicked once now owns three upgrade cadences with no forcing function tying them together.
hlab: the provisioning checklist is initial-provision-only. It gets the versions right at creation time (Docker before Dokploy, unpinned but ordered), and then it is done. There is no hlab upgrade counterpart that re-runs the checklist against a running box to converge panel, engine, and OS — the tool provisions machines; it does not own them afterward.
VPSBox: disposability is the entire point. The sandbox VM exists to be broken and thrown away, so "upgrade the panel in place" is a question the tool correctly refuses to answer. The risk is not in VPSBox itself — it is in the operator who rehearsed only the install, then performs the production install the same carefree way and inherits an upgrade story they never rehearsed at all.
The supporting panel-level note: none of the four panels ships a reconciler for the layers beneath it. A panel upgrade that wants a newer Docker, a Docker upgrade that wants a newer kernel, an OS upgrade that moves cgroups under both — each is the operator's manual sequencing problem, and the installer that made day one effortless has no day-two-hundred counterpart.
2. Backup and restore: the volume was created, never rehearsed
Contabo: this is the exception that proves the rule — Contabo sells Auto Backup as a separate product alongside the 1-click catalog. Backup exists, but it is a second purchase and a second configuration surface, not part of the one click that created the data. The installer flow optimizes "panel running"; "panel recoverable" is a different checkout line, and nothing in the 1-click experience tests a restore.
hlab: the provision step creates the VM and its disks and installs the panel's stateful dependencies (Dokploy brings Postgres; the changelog notes the Swarm-backed services explicitly), but the checklist has no backup primitive. What the provisioner creates, only the operator's separate discipline protects — and skipping that discipline was the provisioner's whole pitch.
VPSBox: the sandbox is a local VM, so "backup" degrades to whatever Multipass snapshots the operator takes by hand — host-level snapshots with no application awareness. That is fine for rehearsal and useless as a production restore story, which is precisely the gap: the installer taught a workflow (click, deploy, iterate) whose production equivalent needs a restore drill the installer never mentioned.
The honest summary: every one of these installers creates stateful volumes on day one and rehearses losing them on day never.
3. The second machine: the path installers don't draw
Contabo: need more capacity? Order another VPS — and start over at the configurator. There is no "join this VPS to the panel on that VPS" step in the 1-click flow. Two Contabo 1-click panels are two independent single-box installs that happen to share a billing account.
hlab: provision another VM with the same flag and you get a second independent panel. The tool's unit of operation is the machine, and nothing in the software catalog expresses "these two machines are one platform."
VPSBox: there is no production second machine at all — the sandbox is local-only by design. The operator graduates from VPSBox to a real VPS with a panel choice fully formed and a fleet architecture entirely unformed.
Panel-level quirks, as supporting notes only: Coolify does support native multi-server management, but no installer wires it — the operator discovers it after the single-box install, if ever. Dokploy's multi-node story runs through Docker Swarm and requires configuring a container registry, a documented onboarding cliff (one panel author calls it exactly that) that the 1-click install never prepares you for. Dokku and CapRover replicate rather than orchestrate: more machines means more independent panels. The panels' clustering stories range from unwired to cliff-edged to absent — but the deeper point is that the installer, which owned the operator's attention at the one moment they were making platform decisions, spent all of it on machine one.
What "fleet, not panel" has to do about it
A Cluster-API platform's pitch — declarative machine lifecycle, a fleet that reconciles instead of a panel that sits on a box — is the correct answer to every gap above. But correctness is not distribution, and installers currently own distribution. To convert installer users instead of merely pitying them, the fleet pitch has to meet three concrete requirements:
1. Adopt the installer-provisioned box; don't demand greenfield. The self-hoster already has a running VPS with apps on it. A platform that requires wiping that box and starting from its own provisioner is asking the operator to throw away the one thing the installer gave them — a working deploy target — on the promise that the replacement is more operable. The winning move is an import path: enroll the existing machine, discover its workloads, and put machine lifecycle under declarative management without a flag day.
2. Match the minutes-to-first-deploy bar for machine one. The installer set the expectation: one action, minutes, panel login. A fleet platform whose machine-one story is "write these five manifests, then wait for reconciliation" loses the comparison before its advantages (which all accrue at machine two and beyond) ever get evaluated. Day-one ergonomics are the price of admission to the day-two conversation.
3. Make machine two a declared replica, not a re-install. This is where the fleet model finally gets to be visibly better instead of theoretically better: adding capacity should be changing a replica count in a declared machine set and watching a controller converge — not re-running an installer and hand-joining the result. The operator who lived through "order another VPS, start over" will recognize the difference instantly, because they have the scar tissue. But they only get there if requirements 1 and 2 kept them in the funnel.
Installers won distribution by respecting where the self-hoster actually starts: one VPS, one evening, one deploy. The fleet pitch wins the rematch the same way — by starting there too, and being the thing that is still correct when the evening project needs its second machine.
Contabo's 1-click catalog, hlab's --software provision step, and VPSBox's Deploy tab all agree: the PaaS panel is now something you install, not something you build. What they install it onto is still one box — and one box is still where every fleet begins.
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.
