The case for self-hosted infrastructure

For a solo builder running real products, infrastructure decisions are business decisions. Part of my stack runs on infrastructure I control: Docker-based, self-hosted, deployed through my own pipeline. This is not an ideological position; it is a cost-and-control calculation.

What self-hosting actually buys

• Data ownership. Product data for a childcare platform or an event SaaS is sensitive data. Keeping the database under your own control simplifies both compliance and conscience.
• Predictable costs. Managed platforms price convenience per request, per seat, per gigabyte. A rented server has a fixed price, which makes planning easier, especially before revenue scales.
• Transferable knowledge. Docker, networking, backups and monitoring are skills that compound. Lock-in is the opposite.

What it costs

Self-hosting trades money for time and responsibility. You become the on-call engineer for TLS renewals, security patches and 3 a.m. disk alerts. That cost is real, and pretending otherwise is how people end up with an unpatched server and no backups.

The decision rule I use

1. Self-host the boring core. Databases, app servers, reverse proxies: standard, well-documented, low drama.
2. Buy the hard-to-operate. Managed services for things where operational failure is catastrophic and expertise is scarce.
3. Automate or don’t do it. Every deployment, backup and certificate must be automated. Manual ops is technical debt with a pager.
4. Write the recovery plan first. If restoring from backup has never been rehearsed, there is no backup. There is a hope.

The honest trade-off

For products early in their life, self-hosting keeps costs low and options open while the system design is still moving. The moment operational load outweighs those benefits for a specific component is the moment to move that component to a managed service. Deliberately, not by default in either direction.