The state of self-hosting

The default answer to "where should this run" has been "the cloud" for fifteen years, and for most of that time it was correct.

Several things changed and the answer is now more nuanced than the reflex suggests.

what changed in favor of self-hosting#

Machines got enormous. A single server you can rent for a few hundred dollars a month has more cores, more memory, and dramatically more I/O than a rack of hardware from 2012. A very large number of applications fit on one machine with room to spare.

The tooling got good. Configuration management, container runtimes, reverse proxies with automatic certificates, backup tooling. What required a team a decade ago requires a competent person and a weekend.

Cloud egress pricing did not fall. Compute prices came down. Bandwidth pricing at the major clouds is still a large multiple of what it costs, and for bandwidth-heavy applications it dominates the bill.

Managed service prices are high relative to the alternative. A managed database costs several times what the equivalent instance costs, for operational convenience that is real and is not always worth the multiple.

what changed against it#

Security expectations rose. Patching, hardening, monitoring, incident response. Self-hosting means you own all of it, and the threat environment is worse than it was.

Compliance frameworks assume cloud controls. SOC 2, ISO 27001, and their relatives are achievable self-hosted and the evidence collection is more work.

The talent assumption inverted. A decade ago every team had someone who knew Linux systems administration. Now a lot of teams do not, and hiring for it is harder than hiring for cloud skills.

the honest decision framework#

Self-host when:

• Your workload is steady rather than spiky. Cloud's core value proposition is elasticity, and you are paying for elasticity you do not use.
• Bandwidth is a large share of your bill.
• You have or can hire operational competence.
• Data locality or sovereignty is a requirement.
• You are at a scale where the cloud premium is a meaningful number — which starts lower than most people assume.

Use the cloud when:

• Traffic is spiky or unpredictable.
• You are early and optimizing for speed of iteration over unit economics.
• You need global presence and do not want to operate it.
• Your team's time is better spent on the product, which for most early-stage companies it is.
• Compliance requirements are easier to satisfy with a provider's attestations.

The hybrid that most people should consider: run the steady baseline on owned or rented hardware, burst to cloud for peaks, keep object storage and CDN with a provider. This captures most of the cost advantage without giving up elasticity where it matters.

the middle option nobody talks about#

Between "hyperscaler" and "rack in a colo" there is a large market of dedicated server providers and mid-size clouds: a real machine, in a real datacenter, with network and power handled, for a monthly fee.

You get root, predictable performance without noisy neighbors, and bandwidth allowances that are not priced as a profit center. You do not get managed databases, autoscaling, or a hundred adjacent services.

For a very large number of applications this is the correct answer and it is under-considered because the discourse is binary.

the operational minimum#

If you self-host, these are non-negotiable:

• Automated, tested restores. Not backups — restores. A backup you have never restored is a hypothesis. Test it quarterly, on a schedule, with a timer running.
• Unattended security updates, at least for the OS.
• Monitoring with alerting that reaches a human. Disk full is the most common self-hosted outage and it is entirely preventable.
• Infrastructure as code. The machine must be reproducible. If rebuilding it requires someone's memory, you have a single point of failure that is a person.
• A documented runbook for the failures you expect: disk, certificate expiration, service crash, host failure.

That is a weekend of setup and a few hours a month. If nobody on the team will own those hours, use the cloud — that is a legitimate reason and it is the actual deciding factor more often than cost is.

the thing that changed my mind#

I used to treat "we run our own servers" as a red flag. I now treat "we are on the cloud and have never modeled the alternative" as an equal one.

Both are defaults applied without analysis. The analysis takes an afternoon and the answer is frequently not what the reflex says.