Dora NodaEvery few months a new single-box PaaS appears, and the demo always looks the same: git push, green checkmarks, HTTPS, a database with one click. Coolify passed 50,000 GitHub stars doing exactly this. Dokploy, CapRover, and Dokku each own a loyal corner of the same territory. Belune — an open-source, self-hosted PaaS that ships as one Go binary next to Docker on your own server — nails that demo better than most, and in one respect it is honest in a way its competitors rarely are. Its own comparison table ends with a row the others usually bury: multiple servers — not supported, planned. The verdict, up front: Belune is arguably the best-cared-for single box in its class, under the same ceiling as all of them.
That verdict needs exactly two halves to hold: proof that the care is real, and proof that the ceiling is structural rather than a missing feature. This post delivers both, in that order.
What Belune actually is
One command on a fresh Linux host with Docker installs it; ports 80 and 443 plus a domain pointed at the server get you automatic HTTPS. Pushes deploy via webhooks (or per-app deploy hooks from CI), builds run through Railpack, Buildpacks, or your own Dockerfile, and a template catalog — Uptime Kuma, Gitea, n8n, Ghost, Metabase, Vaultwarden — provisions one-click apps as native objects so they inherit backups and upgrades. The license is Apache 2.0. So far, this is the standard single-box recipe, executed cleanly. Three details rise above standard.
First, TLS failures explain themselves. Certificate issuance on every ACME wrapper is a spinner that either resolves or doesn't. Belune probes what is actually being served, parses the proxy's ACME errors, and shows the real reason per domain — "hostname resolves to 203.0.113.7, expected 198.51.100.2" — with expiry warnings before they bite. Anyone who has debugged a silent issuance timeout at midnight knows this is the DX detail the whole category skips, and it is genuinely new here.
Second, databases are treated like they matter. PostgreSQL, MySQL, MongoDB, Redis, or your own image — with scheduled backups to S3-compatible storage, restore from the UI, and guarded major-version upgrades that dump, verify, migrate, and roll back if anything goes wrong. The project claims round-trip tests against real database containers rather than mocks for the destructive paths. Most self-hosted PaaS tools treat a database as a container they happened to start; Belune's backup-and-upgrade story is its strongest differentiator.
Third, the operations surface is complete for one box: per-container logs and metrics, a browser terminal, audit log, per-user quotas, disk cleanup, notifications to Discord/Telegram/Slack/ntfy/Gotify on deploy or backup failure, and scheduled snapshot backups for volumes and file mounts — not just databases.
The ceiling, stated by the project itself
Here is Belune's own comparison table, condensed:
| Belune | Coolify | Dokploy | CapRover | |
|---|---|---|---|---|
| Runtime | Single Go binary + Docker | PHP/Laravel stack | Node + Docker Swarm | Node + Docker Swarm |
| App templates / managed DBs | Yes / Yes | Yes / Yes | Yes / Yes | Yes / Yes |
| Guarded DB major-version upgrades | Yes | No | No | No |
| Scheduled DB and volume backups to S3 | Yes | Partial | Partial | No |
| Per-domain TLS status with failure reasons | Yes | No | No | No |
| Multiple servers | No (planned) | — | — | — |
That last row is the whole story. One binary, one box, and the same unanswered second-machine question this site's Coolify-vs-Dokploy coverage has already mapped twice: Coolify orchestrates over SSH from the panel with clustering still experimental, Dokploy commits to Docker Swarm with its networking sharp edges and manual replica management, CapRover is Swarm all the way down. None of them provisions machines declaratively — no machine objects, no health-checked replacement, no versioned fleet rollout. Belune's "planned" is honest, and honesty doesn't change the architecture: the day you need a second server, you are redesigning, not scaling.
Walk through that day concretely, because "redesigning" sounds abstract until it is your weekend. Your first box is full — or you want staging separated from production, which is the same problem wearing a nicer shirt. On Belune today, there is no "add a node" control: you provision a second VPS by hand, install a second Belune, and now you run two independent panels with two Postgres instances, two backup schedules, and deploys you route yourself. On Coolify you register the box over SSH and inherit a fleet-wide credential store plus experimental Swarm placement. On Dokploy you join a Swarm and inherit overlay-networking archaeology — default address-pool collisions with the host network are a recurring support thread. None of these is a machine lifecycle; all of them are new pets. A Cluster-API-based fleet, by contrast, treats the second machine as one more replica of a declaration: health-checked, replaceable, rolled out by version. That is the gap between "manage the box you already have" and "run a fleet," and no single-binary release closes it without becoming a different architecture.
The database tension
Belune's best feature is also its most debatable architectural bet: the database lives in the box. At one-box scale this is pure win — scheduled S3 backups, one-click restore, and guarded upgrades beat what Coolify ships (built-in database dumps exist, but volume backup is not automatic and a small ecosystem of third-party backup tools exists precisely to fill the holes). The prior art shows the pattern clearly: in-the-box databases are exactly as reliable as the discipline around them, and Belune brings more discipline than its predecessors.
But the box is still the fate-sharing boundary, and fate-sharing has a concrete shape. A runaway log volume fills the one disk, and the database and the apps die together — the backup in S3 is intact, and the restore still means rebuilding the only host you have while everything is down. Scheduled dumps help only if someone has rehearsed the restore; Belune's in-UI restore lowers that bar, but the bar still sits on the same machine as the fire. A major-version upgrade rolling back cleanly is genuinely good engineering, and needing it at 3 AM on the same host as production is the part nobody demos. And exit friction compounds quietly: the more your data layer depends on platform-managed upgrade and backup machinery, the more "migrate" means untangling dumps, schedules, and restore runbooks from the panel that owns them. This is why some platforms hold a deliberate line — bex, for example, does not offer managed databases as a matter of stated non-goals: running your database for you is a different business from running your apps, with different failure modes and different on-call. Belune chooses the opposite, and for its target user — one box, no DBA — that choice is correct. It just doesn't survive contact with the second machine, where the database question has to be answered at fleet scope anyway.
Who should adopt it
The decision rule is short:
- One VPS, apps plus a database, no ops team → Belune deserves the top of your shortlist. The TLS clarity and database care are real advantages over Coolify and Dokploy today, and a single Go binary is operationally simpler than a PHP/Node stack with more moving parts.
- Anything you expect to outgrow one box → start declarative. If the second server is a matter of when, price the transition: Belune's multi-server is a roadmap row, while a Cluster-API-based fleet treats the second machine as one more reconciled object.
- You can name the primitive you need (GPU scheduling, custom kernels, regulated topology) → neither. Single-box tools are not in that business at all.
The counter-argument deserves its weight: single-binary simplicity is the feature, and "planned" multi-server may be the right scope discipline for a young project — every panel that rushed clustering shipped a bad one. Fair. But scope discipline cuts both ways: evaluate Belune for the box it runs on today, not the fleet on its roadmap.
Name the conditions that would change this verdict, so it stays falsifiable rather than tribal. If Belune ships multi-server with declarative machine lifecycle — not SSH registration, not Swarm-join folklore — the ceiling section of this post expires and should be rewritten. If your database moves to an external managed service with point-in-time recovery, the fate-sharing objection shrinks to backup hygiene. If you rehearse a full off-box restore quarterly, the 3 AM scenario becomes an exercise instead of an incident. None of those conditions holds by default on day one, which is why the default recommendation stands: the best-kept single box in its class, with TLS errors that finally tell you the truth. It earns its place on the shelf. Just know where the shelf ends.
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.
