Self-hosting open source is easy. Running it in production is not.

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. How much CPU, memory, and disk does this actually need under real load, and what happens when it grows. OS patching. The host needs security updates on a schedule, and someone has to apply them without taking the service down at a bad time. Application updates. The upstream project ships a release with a security fix. Now you need to update without breaking your config, your database schema, or your integrations, and you need a way back if it goes wrong. TLS. Certificates that issue and renew automatically, and do not silently expire on a Sunday. Backups. Not a cron job that writes to the same disk. Off-host, encrypted, with a retention policy, and actually tested by restoring them. Monitoring and alerts. You want to know the disk is 80 percent full before it is 100 percent full and the database has stopped accepting writes. Email. Most of these apps need to send mail for invites, resets, and notifications. Getting that delivered instead of dropped into spam is its own project: SPF, DKIM, DMARC, a warmed sending IP or a relay. Network security. A firewall that exposes only what should be exposed, and some answer for volumetric attacks. Secrets and log hygiene. Rotating credentials, rotating logs before they eat the disk. Tracking disclosures. Every app you self-host is now something you have to watch for CVEs, per project, 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 is usually a part time job that lives in one engineer's head. The two options most teams settle for Do it yourself on a VPS. This works. It works right up until the person who set it up is on leave during an incident, or the one undocumented step in the upgrade runbook gets skipped, or a restore is needed for the first time and nobody has ever tested one. The software is free. The operational knowledge is expensive and fragile. Pay for the vendor's hosted version. Faster to start, but you are often back to per-seat pricing, your data sits on their infrastructure, and you have given up the control that made you choose open source in the first place. For some tools the managed tier costs several times the raw compute. There is a third option, which is to treat "operating open source software" as a solved, boring layer that you rent. What a managed layer looks like: Elestio One option in this space is Elestio. It runs a managed layer on top of open source software that you still own. You pick an app from a catalog of more than 400+ open source templates. You pick where it runs: a major cloud provider and region of your choice, or your own virtual machines, or your own hardware on premise. It deploys onto a dedicated instance, not a shared multi tenant box. From there the operational list above is handled for you: Automated encrypted backups, off host, with retention, and restore that has been 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 are deploying your own code alongside Support that covers the stack, not just the VM You keep root access. It is your instance and your data. The billing is a flat fee on top of the compute, not per user, so it does not punish you for adding people. When this makes sense, and when it does not It makes sense if you are a small or mid sized team without a dedicated platform or SRE function, you want the economics and control of open source, and you would rather your engineers ship product than babysit a Postgres upgrade. It makes less sense if you already have a mature platform team, infrastructure as code for all of this, tested restores, and an on call rotation. If you have built that muscle, keep using it. Takeaway Open source software being free to license does not make it free to operate. Backups, patching, updates, monitoring, mail, and security tracking are the real cost, and they do not show up until you are in production. The question worth asking is whether operating this software is a competitive advantage for your business. If it is, invest in doing it well. If it is not, and for most teams it is not, hand that layer to something that does it for a living and get back to the work only you can do.