Beyond the Frontend Scorecard: What Stormkit's Self-Hosted Vercel Roundup Misses for App-PaaS Buyers

On August 13, 2026, Stormkit did something vendors rarely do: it published an honest comparison of six self-hosted Vercel alternatives — Coolify, Dokploy, Dokku, CapRover, Kamal, and Stormkit itself — with licenses verified against each project's GitHub repo, star counts, install commands, and a "look elsewhere if" section for every entry including its own. It is a good roundup. It is also, by its own framing, a roundup for people hosting frontends.

That lens matters more than it looks. Every pick in the article is judged on static and frontend hosting, where edge caching and preview URLs matter more than workers, cron, or Postgres. The moment your "Vercel replacement" also has to run a background worker, send scheduled emails, keep a database backed up, and survive a second server, half the scorecard goes blank. This post fills in the missing half: what the roundup gets right, the app-PaaS scorecard it didn't print, and where each tool lands once backend workloads enter the picture.

What Stormkit's roundup gets right​

The roundup's best move is refusing to rank six tools that aren't competing. It sorts them into three buckets, and the buckets are correct:

• Container platforms — Coolify, Dokploy, CapRover. Somewhere to run any Docker image, including off-the-shelf software you didn't write.
• An application platform — Stormkit. The database, authentication, email, and scheduled jobs your product needs, provided by the platform.
• Deployment tooling — Dokku, Kamal. Get code onto a server you already manage; everything else is yours.

Its picks follow from the buckets: Coolify (or Dokploy, if you prefer the UI) for running everything on one box; Dokku for terminal-first minimalism; CapRover for proven-and-boring with a UI; Kamal when you already have servers and only want deployment automation; Stormkit when you're building a product and want the database, auth, email, and scheduled jobs to come with the platform.

The cost framing is honest too. A VPS that can build and run these tools costs roughly $5–20 a month, and Stormkit flatly says that if your Vercel bill is under about $20 a month and predictable, self-hosting is a worse deal in total cost. Self-hosting wins when the bill grows, when the platform won't run something you need, or when data has to live somewhere specific. All fair — for frontends. Now the missing scorecard.

The app-PaaS scorecard they didn't print​

Here are the same six tools rated on the six dimensions a full-app buyer actually shops for. This is the table the roundup never prints, because a frontend lens has no column for it.

Two patterns jump out. First, the container platforms cluster together: they all run workers-as-containers and one-click databases, and they differ mostly at the edges — Dokploy backs up arbitrary Docker volumes while Coolify backs up databases only, and their multi-server stories range from experimental to native Swarm. Second, Dokku and Kamal look sparse in this table on purpose: that's the deal with deployment tooling. The sparseness is the product, not a gap — as long as you know you're signing up for it.

What the frontend lens drops, dimension by dimension​

Workers and cron: the first thing a real app needs​

The canonical "we outgrew static hosting" moment is not traffic — it's the first background job. A welcome-email sequence, a nightly report, an image-processing queue. Frontend scorecards never test this, and the answers vary wildly.

Coolify ships scheduled tasks, Dokploy runs cron jobs both inside containers and on the host machine, and Stormkit bakes in periodic triggers so scheduled work needs no separate cron box. Dokku handles cron through its plugin system, which works but makes scheduling one more thing you assemble. CapRover leans on its app catalog for a cron runner. Kamal gives you nothing here — it pushes containers to your servers and considers its job done, so the cron runner, the queue, and the retry logic are all yours to build.

None of these answers is wrong, but they imply very different week-ones. A team picking Dokploy for its UI and discovering cron is built in has a different month than a team picking Kamal for its simplicity and discovering that "simple" meant "you build the scheduler."

Databases and persistence: who owns your data at 3 a.m.​

Every tool in the roundup can run Postgres. The question an app buyer must ask is what "run" includes: provisioning, migrations, backups, and restores.

Stormkit's answer is the most opinionated — Postgres attached to an environment with migrations run on deploy — because it's selling an application platform, not a container panel. Coolify and Dokploy offer one-click database engines (roughly eight and six respectively), which gets you a running database fast; the divergence shows up in backups, where Dokploy covers arbitrary Docker volumes and Coolify covers databases only.

Dokku's Postgres plugin is mature and battle-tested over a decade, but backup and restore remain plugin-wired. CapRover provisions databases as one-click apps with app-level backups. Kamal, again, is out of scope by design: your database lives wherever you put it, backed up however you arranged.

The pattern to notice: nobody in this list sells you a managed database with point-in-time recovery and a pager that isn't yours. The spectrum runs from "the platform wires it up" (Stormkit) through "the panel provisions it, you verify the backups" (Coolify, Dokploy, CapRover, Dokku) to "you are the database team" (Kamal). Know which seat you're sitting in before the disk fills up.

Multi-server and HA: the seam every single-box tool has​

This is the dimension where the frontend lens costs teams the most, because it's the one you can't evaluate until you need it — and by then you're migrating.

Dokku is single-host by design; the maintainers have said multi-host support isn't on the roadmap, and the only path off one box is the Kubernetes scheduler plugin, which is really a path off Dokku's model entirely. CapRover builds on Docker Swarm, so clustering is native to its architecture. Dokploy manages remote servers with Swarm as its clustering story, while Coolify attaches remote servers over SSH with Swarm support still experimental — fine for spreading load across boxes, not a true scheduler.

Kamal is the interesting inversion: it deploys to N hosts natively and has no single-box ceiling at all, but it also has no dashboard, no build service, no environment management, and no health-driven rescheduling. You get multi-server deploys; everything a platform would do with those servers remains your YAML and your runbooks.

Stormkit's self-hosting story centers on your own server, with environments, variables, domains, and TLS handled per installation. That's coherent for its audience — teams building a product, not a fleet — but it means the multi-node story is the question to ask before you commit, not after.

The honest summary: every tool here except Kamal inherits a ceiling from its architecture (one box, or one Swarm), and Kamal avoids the ceiling by declining to be a platform. If your roadmap has a second server in it, that row of the table matters more than all the preview-URL polish combined.

The 20-dollar-a-month line is a frontend number​

Stormkit's cost rule — self-hosting loses below ~$20/month, wins above it — is right for the workload it describes. A static site on a $5 VPS with automatic TLS is genuinely cheaper than a scaling Vercel bill, and there's almost nothing to operate.

Backend workloads move the break-even. The VPS still costs $5–20, but now you also own uptime for stateful services, backup verification and restore drills, database upgrades, TLS renewals across services, and whatever your cron runner does when the box reboots at 4 a.m. Every project in the roundup automates part of this, and none of them makes it someone else's problem the way a managed platform does — Stormkit says exactly that, and it's the most important sentence in the article for app buyers.

This doesn't mean self-hosting backends is uneconomical. It means the comparison isn't "$6 VPS versus $20 Vercel" but "$6 VPS plus your on-call time versus a managed bill that bundles the pager." Teams that price their own ops time honestly sometimes still pick self-hosting — for data residency, for the workloads managed platforms won't run, or because the managed bill at their scale genuinely dwarfs the ops cost. The mistake is making that call with a frontend scorecard that never lists the backend line items.

Where bex fits: past static hosting, before Kubernetes YAML​

There's a team this whole comparison underserves: outgrowing single-box panels, not ready to author and operate Kubernetes manifests. They've felt the specific seams — the second server, the worker that needs more than a cron hack, the database whose backups they've never test-restored — but "just run Kubernetes" would replace their PaaS problem with a cluster problem they have no headcount for.

That's the gap bex is built for. Push a git repo, get a running HTTPS service on machines you own, through a Render-compatible API — with background workers, cron jobs, and managed Postgres as first-class primitives rather than plugins or catalog apps, and multi-machine scheduling that doesn't top out at one box or one Swarm. No cluster YAML to write, no control plane to feed and water; the fleet behavior (placement, health-driven rescheduling, declarative machine lifecycle) comes from Cluster API under the hood instead of from your runbooks.

If that sounds like the next step after the tools above, the move is incremental: keep the frontend where it is, move one stateful service or worker onto bex, and compare the week-one experience — including the 3 a.m. parts — against the panel you came from.

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.

Pick guide: which panel for which team​

• Running everything on one box, workers and databases included — Coolify for breadth, Dokploy if you prefer the UI and want volume-level backups.
• Terminal-first team that wants a decade-stable git push flow — Dokku, with eyes open about single-host and plugin-assembled scheduling.
• Proven, boring, UI-driven, Swarm-native clustering — CapRover.
• You own servers and want deploy automation without a platform — Kamal, with a plan (and an owner) for cron, databases, and backups.
• Building a product and want Postgres, auth, email, and scheduled jobs bundled — Stormkit.
• Past one box, before Kubernetes — bex.

Stormkit's roundup deserved its audience: verified licenses, real star counts, and picks that respect the reader's intelligence. Just remember what it measured. Frontend hosting is the audition; workers, cron, databases, backups, and the second server are the job. Shop for the job.

Sources: Stormkit, "Best self-hosted Vercel alternatives in 2026" (Aug 13, 2026); Contabo, "Coolify vs Dokploy: Complete Comparison Guide 2026"; Cloudzy, "Coolify vs Dokploy: Self-Hosted PaaS Compared"; Dokploy's Dokploy-vs-Coolify comparison; Northflank, "6 Best Dokku alternatives for app deployment in 2026"; Qovery, "7 Vercel Alternatives for Teams That Need Backend Services" (Sep 3, 2026).