No rent is not free. It exchanges a subscription line item for an operational burden that has no fixed price and does not show up on a budget. Most people who choose to self-host underestimate this cost until they have paid it for a year. The cost is worth paying for many workloads. It is worth knowing what you are paying before you decide.
What you are taking on
When you self-host, you become the operator. The operator is responsible for availability: the service is up when someone needs it. The operator is responsible for security: patches are applied, credentials are rotated, access is controlled. The operator is responsible for data integrity: backups exist and can be restored. The operator is responsible for the relevant decisions about what is stored and where.
Managed platforms take most of this off your hands for a price. Heroku, Render, Fly, Vercel, Railway: the subscription covers the operational work their team does so you do not have to. That price is real. The alternative is also real. The difference is visibility: the subscription appears on a credit card statement; the operational time does not.
The operator is always there. On managed platforms, someone else is paying them. When you self-host, you are the operator.
What requires ongoing attention
The honest list, in rough frequency order:
The rough time cost
The numbers below assume one service with automation in place for patches and certificate renewal. The steady-state figure is maintenance work: applying patches, reviewing logs, confirming that automated tasks completed. The stabilisation figure covers the first three months, when you discover what you did not account for: the firewall rule that blocks the health check, the database that runs out of disk under load, the backup script that silently fails when the destination is full.
| Phase | Time cost | What it covers |
|---|---|---|
| Steady state | 2 to 4 hrs/month | patches, log review, confirming automation ran |
| First three months | 4 to 8 hrs/month | finding what you missed at setup |
| Routine incident | 2 to 4 hrs each | service down after a package update |
| Serious incident | no ceiling | data corruption, security event, disk loss with no verified backup |
The serious row is where documented runbooks and at least one practiced restoration from backup earn their keep. These figures are per service. Multiple services multiply, but there are economies of scale once shared tooling exists: a patch automation system, a backup verification script, a monitoring stack. The overhead per additional service drops once the scaffolding is built.
The skills gap
Most developers today ship software to managed platforms and have not operated a production system end-to-end. The distinction matters. Shipping to a platform means writing code that a platform runs.
Operating means reading kernel logs, diagnosing why a process was killed by the OOM killer at 3am, understanding what a firewall rule you added last month actually does and whether it covers all the cases you intended, and recognising when a certificate error is a configuration problem versus a certificate problem versus a DNS propagation problem.
These skills are learnable. They are also valuable in themselves, independent of the operational context, because they produce an understanding of how production systems actually behave that writing application code does not. But learning them on a service that real people depend on is a specific kind of risk. The first year of operating a critical self-hosted service is when you discover what you do not know, and the discovery process has a cost.
The incident that reveals the gap
The common pattern is: something breaks, you do not have the runbook, the backup you thought existed turns out not to have run for three weeks, and the investigation takes most of a day. This happens to almost everyone once. The people who self-host successfully are the ones who took the lesson and built the tooling; the ones who gave up are the ones who decided the cost was not worth it. Both conclusions are reasonable. The important thing is to have the incident early, with low stakes, rather than late, with high ones.
When it makes sense
Sensitive data. Medical records, financial data, personnel information. Data you cannot legally or ethically place in a third party's hands without contractual guarantees you can actually enforce and audit. Self-hosting is not a guarantee of security, but it puts the relevant decisions, and the accountability for them, in your hands rather than someone else's.
Cost at scale. Many services are priced at the low end for small use and become expensive at volume. At some scale, the operational cost of self-hosting is lower than the subscription. The crossover point varies widely by service and depends heavily on how much the operational work costs in your context, but it is real and worth calculating before signing a multi-year contract.
Configuration that managed services do not support. Some workloads require network topology, integration patterns, or security configurations that no managed offering supports. Self-hosting is sometimes not a preference but a constraint.
The learning value. Running your own infrastructure teaches things that running on a platform does not. If you are building systems for a living, the operational knowledge compounds. The cost in year one is an investment; years two and three are cheaper and produce a clearer picture of what you are building.
The minimum viable operations posture
Before calling something "self-hosted" rather than "running on a server and hoping," a service needs five things:
- Automated TLS certificate renewal with an alert if renewal fails more than a week before expiry.
- Automated backups to a separate location, with at least one verified restoration in the last 90 days.
- A monitoring check that alerts you when the service is unreachable, running outside the service itself.
- A documented recovery procedure that you have followed at least once, even in a test environment.
- A patch cadence you have actually followed for at least three months, not just one you have planned to follow.
Without these five, you have a service that runs but not one you are operating. The distinction matters when it breaks at an inconvenient time, which is when things break.
The rent-free alternative is real. The work it requires is also real. Knowing the cost before you choose it is the only way to choose it on sound footing.
No rent is not free. Self-hosting swaps a subscription line item for operational work that has no fixed price and never shows up on a budget. The cost is worth paying for plenty of workloads. It is worth knowing before you decide.
What you take on
When you self-host, you are the operator. That means availability, security patches, credential rotation, backups that actually restore, and the decisions about what is stored and where. A managed platform (Heroku, Render, Fly, Vercel, Railway) does this work for a fee. The fee is real. So is the time. The only difference is that the subscription lands on a credit card statement and the operational time does not.
The recurring tasks, in rough frequency order:
- Weekly: security patches for OS, runtime, and dependencies.
- Monthly: dependency updates that break things and need testing.
- Quarterly: backup verification and credential rotation.
- Annually: TLS certificates (near-free with auto-renewal, a missed calendar item without it).
- Ongoing: monitoring that tells you the service is down before users do.
The time cost
Steady state: 2 to 4 hours a month for a small service once automation is in place. First three months: 4 to 8 hours a month while you find what you missed. Incidents: a routine one (down after a package update) is 2 to 4 hours; a serious one (data corruption, a security event, disk loss with no verified backup) has no ceiling. Runbooks and a practiced restore are what cap that last number.
A backup you have never restored from is not a backup. It is a file in a directory you hope works.
The skills gap
Most developers ship to platforms and have never operated a system end to end. Shipping means writing code a platform runs. Operating means reading kernel logs, diagnosing an OOM kill at 3am, and knowing whether a cert error is config, certificate, or DNS. These skills are learnable and valuable on their own, but learning them on a service real people depend on is its own risk. Expect one bad incident early; have it with low stakes, not high ones.
When it makes sense
- Sensitive data you cannot legally or ethically hand to a third party.
- Cost at scale, where the subscription overtakes the operational cost (calculate the crossover before signing a multi-year contract).
- Configuration no managed offering supports, so it is a constraint, not a preference.
- Learning value, since the operational knowledge compounds if you build systems for a living.
The minimum posture
Before you call it self-hosted rather than running on a server and hoping, you need five things: automated TLS renewal with a failure alert, automated off-site backups with a verified restore in the last 90 days, external monitoring that alerts when the service is unreachable, a recovery procedure you have actually run once, and a patch cadence you have followed for three months. Without them you have a service that runs, not one you operate. The distinction matters at the inconvenient moment, which is when things break.
Sources
- Let's Encrypt documentation on ACME auto-renewal: why certificate expiry stops being a manual calendar item once renewal is automated and monitored.
- The SRE practice of game days and restore drills (Google's Site Reliability Engineering, 2016): a backup is only proven by a tested restoration, not by the fact a backup ran.
- The companion piece, scarcity used to be free, on the hidden price of resources that arrive without a line item.