Self-hosting talk usually turns into a technical argument — Kubernetes versus bare metal, Ceph versus ZFS. The three teams we followed this year had that argument too. It wasn't what decided the outcome.

The three teams

Team A moved a data pipeline off a managed warehouse to self-hosted ClickHouse on rented bare metal. Monthly spend dropped from $18,400 to $3,900. A year later, still happy.

Team B moved application hosting off a managed PaaS to a small self-managed Kubernetes cluster. Spend dropped from $9,200 to $2,600. Also still happy, twelve months in.

Team C moved a managed Postgres fleet to self-hosted with a two-person infra team covering on-call. Spend dropped from $6,000 to $1,400 in infra costs — but they now pay two engineers roughly $340,000 combined per year to keep it running, on-call included.

The difference wasn't technical

All three migrations succeeded on the metric of "does the software run." What separated the two happy teams from the regretful one was a staffing question asked before migrating, not after:

Do we already have someone whose job includes 3am pages, or are we creating that job for the first time?

Teams A and B had existing infra engineers with spare capacity and on-call rotations already in place — the self-hosted systems were additive load on existing headcount. Team C didn't, and effectively hired two new salaries to save $4,600 a month in hosting fees. The math never closes.

The actual checklist

  • Do you have on-call coverage today, independent of this migration?

  • Is the team doing the migration the same team that will operate it in a year?

  • Have you priced the marginal engineering hours this adds, not just the infra bill it removes?

  • Self-hosting is a staffing decision wearing an infrastructure costume.

  • The savings are real. So is the payroll you might be underpricing.

Run the staffing math first. The Terraform comes after.