Why not just use a self-hosted PaaS layer?

Fair question. That kind of tool is free, open source, and does a lot of what a paid host does. If you’re weighing it against paying someone like us, you deserve a straight answer, not a sales pitch that pretends it’s bad. It isn’t. Here’s the honest version.

What a self-hosted PaaS layer actually is, and where it’s great

A self-hosted PaaS layer is an open-source, self-hostable platform that puts a Heroku-style layer on top of your own server. You install it on a VPS, connect a Git repo, and it handles builds, deploys, TLS certificates, and databases through a clean web UI. It’s genuinely good software.

For a lot of people, that kind of tool is the right answer, and I’ll say that plainly:

• It’s free. No per-app fee, no seat pricing. You pay only for the server underneath.
• It kills the worst setup pain. Push-to-deploy, automatic HTTPS, and one-click databases without hand-writing Docker and Caddy configs.
• You keep full control. It’s your server, your data, no vendor lock-in.
• It’s actively developed with a real community behind it.

If you’re technical, enjoy running your own infrastructure, and have the time, a self-hosted PaaS layer plus a cheap VPS is a legitimately excellent setup. I’m not going to pretend otherwise to win an argument.

So why would anyone pay?

Because “free tool” and “free outcome” aren’t the same thing. That kind of tool removes the config work. It does not remove the operations work or the responsibility. Those are the parts people underestimate.

Here’s what it hands you that’s still your job:

• The backups are yours to get right. A self-hosted PaaS layer can take database backups, but you configure them, choose retention, pick where they go, and, the big one, actually test that a restore works. It won’t call you when a backup silently stops running. It won’t notice your restore is broken until you need it.
• You’re the one on call. When the server runs out of disk at 3am, or a deploy wedges, or Postgres won’t start after an update, there’s no one to page. You are the pager. It’s software; it doesn’t wake up.
• The tool itself needs maintaining. It’s another piece of software on your server that needs updates, and occasionally its own updates break things. You now run the tool that runs your apps.
• Security and patching stay with you. OS updates, firewall, exposed ports, the tool’s own dashboard being internet-facing. All yours.
• No named human who knows your setup. If you get stuck, there’s a Discord and GitHub issues. Helpful, but it’s not someone whose job is your uptime.

None of this makes it bad. It makes it a tool, not a service. The difference between a tool and a service is who’s responsible when it breaks.

The real comparison: what you’re actually buying

	Self-hosted PaaS layer (self-run)	Managed hosting (us)
Software cost	Free	Included in plan
Server cost	You pay (~€7 to €45/mo)	Included in plan
Deploys, TLS	Handled by the tool	Handled
Backups configured	You set up	Set up for you
Backups tested	You test them	We test restores
Monitoring	You wire it up	Included
3am incident	You	A named human
Maintaining the platform	You (the tool + OS)	Not your problem
Your time per month	Real, variable	Near zero

The honest way to read this table: a self-hosted PaaS layer wins on cash, hands down. Managed hosting wins on time and on who carries the risk. That’s the whole trade. Anyone who tells you managed hosting is “better” full stop is selling. It’s better for a specific person: someone whose time is scarce, whose app matters enough that a bad backup is a disaster, and who doesn’t want to be the one on call.

Who should just use a self-hosted PaaS layer

Genuinely, use one if:

• You’re comfortable running Linux and enjoy it, or want to learn.
• Your app is low-stakes enough that a bad day is annoying, not catastrophic.
• You have the time to set up backups properly and test a restore, then keep an eye on it.
• Saving the monthly fee matters more to you than saving the hours.

That’s a lot of people, and they should not pay us. We’d rather tell you that than take money for something you can do yourself.

Or, we do it for you

Pay us when your time is worth more than the fee, or when a lost database would be a real problem: we run your app on a VPS with tested backups, point-in-time recovery, monitoring, and a named human who answers at 3am. Same cheap infrastructure a self-hosted PaaS layer would run on, minus the on-call job. See our pricing, or read why self-hosting stops making sense at a certain point.

FAQ

Is a self-hosted PaaS layer actually free, or are there hidden costs?

The software is genuinely free and open source. The hidden cost isn’t money, it’s time: setting up and testing backups, monitoring, keeping the tool and the OS patched, and being on call when something breaks. You also pay for the server underneath. Free tool, not free outcome.

Can a self-hosted PaaS layer do backups?

Yes, that kind of tool can schedule database backups to local or remote storage. What it can’t do is guarantee they’re kept long enough, stored safely off-server, and actually restorable. That last part, testing the restore, is the step people skip, and it’s the step that matters when disaster hits.

If that kind of tool is so good, what am I paying you for?

Time and responsibility, not features. It gives you the tooling. We give you the outcome plus someone accountable for it: backups we’ve tested, monitoring we watch, and a human who responds when your app goes down. If you’d rather own all of that yourself, a self-hosted PaaS layer is a fine choice and we’ll say so.

Can I start on a self-hosted PaaS layer and move to managed later?

Absolutely, and it’s a sensible path. Run it while you’re small and have time. Move to managed hosting when your app gets serious, your time gets scarce, or the thought of a 3am outage stops being theoretical. Because it’s all standard Docker and Postgres, moving between the two is straightforward.