You picked an open source tool on purpose. Maybe it was n8n instead of a per-task automation SaaS, Keycloak instead of paying per active user for auth, Postgres and Grafana and Mattermost instead of three separate subscriptions that each want a seat license. The pitch is good: own your data, no per-seat bill, no vendor deciding your roadmap.
You run docker compose up. It works. You show the team. Everyone is happy.
Then it goes to production, and the actual job starts.
The work that is not in the README
The README gets you a running process. Keeping that process healthy, safe, and recoverable for the next two years is a different list: sizing and provisioning, OS patching, application updates that don't break your config or schema, TLS that renews itself, backups that are off-host and actually tested, monitoring that warns you before the disk fills, email that gets delivered instead of spam-filtered, a firewall and some answer for volumetric attacks, secret and log rotation, and tracking CVE disclosures for every app you run, forever.
None of this is hard in isolation. All of it together, across five or six self-hosted apps, is a part time job. And it usually lives in one engineer's head.
The two options most teams settle for
Do it yourself on a VPS. Works right up until the person who set it up is on leave during an incident, or the one undocumented upgrade step gets skipped, or a restore is needed for the first time and nobody has tested one. The software is free. The operational knowledge is expensive and fragile.
Pay for the vendor's hosted version. Faster to start, but often back to per-seat pricing, your data on their infrastructure, and you've given up the control that made you choose open source. For some tools the managed tier costs several times the raw compute.
There is a third option: a managed layer on top of the open source software you already chose, one that leaves you with full root access and your own data.
What Elestio actually does
Elestio runs that layer. Pick an app from a catalog of 400+ open source templates, pick where it runs, a major cloud provider and region of your choice, your own virtual machines, or your own hardware on premise, and it deploys onto a dedicated instance, not a shared box.
From there, everything on that operational list is already handled:
- Automated encrypted backups, off host, with retention, and restore that's actually tested
- Monitoring with alerting on the things that actually page you
- Automatic OS patching and application updates, with a rollback path
- Managed SMTP so outbound mail is set up and deliverable
- TLS certificates that issue and renew on their own
- A firewall and DDoS protection in front of the instance
- Built-in CI/CD if you're deploying your own code alongside
- Support that covers the whole stack, not just the VM
You keep full root access. It's your instance and your data, exportable any time. Billing is a flat fee on top of compute, not per user, so growing your team doesn't grow your bill.
Getting started takes minutes, not a sprint
Pick a template, choose a region, and Elestio provisions the instance with backups, monitoring, updates, TLS, and a firewall already configured before your first request even hits it. No YAML to write first, no runbook to build before you're allowed to go live.
Most teams have their first app running in under ten minutes.
Takeaway
Open source being free to license doesn't make it free to operate. Backups, patching, updates, monitoring, mail, and security tracking are the real cost, and they show up the moment you're in production. Elestio is the fastest way to get all of that handled from day one, so your team spends its time on the product, not the platform underneath it.
Top comments (2)
the part about upgrades and backups is where self-hosting usually gets real. i like testing a restore on a clean host before assuming the compose file is enough.
Absolutely. That’s why restore testing is so valuable. With platforms like Elestio, you can automate backups, restore them to a separate service for validation, and even send backups to your own S3 bucket for an additional layer of control. The mount/backup-path gap is still something worth checking.