Last year my monthly infra bill for side projects and client-adjacent work quietly crossed $180. Not because any single project was doing serious traffic — most of it was low-traffic client sites, a couple of personal tools, and staging environments nobody looked at for weeks at a time. It crossed $180 because every new project defaulted to a managed platform, and managed platforms bill you for convenience whether or not you’re using it.
The fix wasn’t “self-host everything, save money.” That’s the conclusion, not the process, and if you start from the conclusion you end up self-hosting things that genuinely should stay managed. The process was going through every line item and asking one question: is this managed because the problem requires it, or because it was the default when I set the project up?
The audit
I pulled up every recurring charge — hosting, database, cache, monitoring, staging duplicates — and wrote down what each one was actually buying me, not what it was named.
- App hosting (PaaS): buying zero-downtime deploys and TLS termination. I already knew how to do both of those myself.
- Managed Postgres: buying automated backups and not thinking about disk. Backups matter. The rest was convenience.
- Managed Redis: buying nothing I couldn’t get from a container on a box I already had running.
- Monitoring/logging SaaS: buying a dashboard for traffic volumes low enough that
journalctland a cron-triggered health check would have told me the same thing. - A duplicate staging environment per project: buying isolation I could get from Docker Compose profiles on one machine instead of a second billed environment per project.
None of that is an argument that managed services are bad. It’s that I’d stopped checking whether the reason I picked one was still true. A team of six shipping multiple times a day should absolutely pay for zero-downtime managed deploys — the time saved is worth more than the bill. A solo dev running four low-traffic projects is paying enterprise prices for a problem they don’t have.
What replaced what
| Was paying for | Replaced with |
|---|---|
| PaaS app hosting | Coolify on a VPS, deploying from a git push |
| Managed Postgres (per project) | Self-hosted Supabase on one dedicated node |
| Managed Redis | A Redis container, same box as the app |
| Public IP + load balancer per project | One Cloudflare Tunnel, no inbound ports open |
| A bastion / VPN for internal access | Tailscale mesh across every node |
| Duplicate staging environments | Compose profiles on the same host |
The hardware side is two Oracle Cloud “always free” instances, a mini PC sitting on a shelf at home, and one small paid VPS as a fourth node for anything that needs to be reachable even if my home connection drops. Tailscale ties all four into one private network so they can talk to each other like they’re on the same LAN, regardless of where they physically sit.
The $14 that’s left is the one paid VPS node and the domain/DNS costs that were never going away regardless of hosting choice. Everything else moved from a recurring bill to a fixed asset (the mini PC) or a genuinely free tier (the two OCI instances) that I now understand well enough to actually rely on.
What it cost in a different currency
Self-hosting doesn’t remove cost, it moves it from money to attention. I now own patching, backups, and the occasional 11pm Tailscale ACL mistake that takes a service off the mesh. That trade only makes sense if you’re going to be the one operating these systems either way — if you’d rather never think about the box underneath your app, paying for managed infra is the correct decision, not a lesser one.
What made it worth it for me specifically: I already run production infrastructure for clients, so the operational skill isn’t a new cost, it’s a skill I’m using either way. The question was never “can I run a Postgres instance,” it was “should this specific project be paying $25/month for something I already know how to run correctly on a box that’s already up.”
What I’d check before doing this again
- Does the workload actually need geographic redundancy or burst scaling? If yes, that’s a real reason to stay managed.
- Is there a compliance or contractual reason a client needs their data on a named cloud provider? Check the contract before the bill.
- Am I actually going to patch this box, or will it quietly rot for eight months? Be honest — an unpatched self-hosted box is worse than a managed one you’re paying to ignore.
The number that actually mattered wasn’t the $170/month saved. It was realizing I’d let “managed” become the default instead of a decision, on projects small enough that the decision was easy once I actually looked at it.