What You Should Never Self-Host

Owning your stack is a decision, not a religion. There are things I self-host across twenty companies, and there are things I would never touch. The line is simple: self-host what carries your data, your logic, and your lock-in risk. Rent the things that are commodities, hard to run safely, or catastrophic to get wrong. Draw that line badly and you either pay a fortune renting your core, or you spend your nights running infrastructure that was never going to give you an edge.

Never self-host your email deliverability reputation

You can run your own SMTP server. You should not. Deliverability is not a software problem, it is a reputation problem, and reputation takes months to build and one mistake to destroy. IP warming, feedback loops, blocklist monitoring, DKIM alignment, and the endless fight with spam filters are a full-time job that adds nothing to your product. Rent this. Use a real sending provider and keep your own list and your own templates so you stay portable. The thing to own here is the audience, not the pipes, which is exactly the point I make in owning your customer list, not just your store.

Never self-host DNS as your only copy

DNS is the switchboard for everything. If it goes down, nothing resolves, and debugging it under pressure is miserable. Run authoritative DNS on a hardened, redundant, anycast provider. That is not lock-in, because DNS is a fully portable standard. What you own is the domain and the zone file itself, which you can move anywhere in minutes. Owning the records is the point. Running the nameservers is not.

Never self-host your edge and DDoS protection

Absorbing a volumetric attack takes global capacity you will never have on a few boxes. Put a CDN and DDoS layer in front of your own origin. This is the cleanest hybrid there is: your server holds the logic and the data, the edge holds the traffic. I do exactly this and wrote it up in putting Cloudflare in front of your own server. You get the ownership where it counts and rent the one thing that genuinely needs planet-scale infrastructure.

Never self-host secrets you cannot rotate safely

Secrets management done wrong is worse than not doing it. If self-hosting your secrets means a plaintext file nobody backs up and everybody can read, rent a real manager instead. That said, self-hosting secrets well is very doable, and I cover the pattern in managing secrets without a cloud vendor. The rule is capability, not dogma: if you can run it to a real security bar, own it. If you cannot, do not pretend.

What you should self-host

Everything that holds your core data and logic. Your primary database. Your application. Your deploy pipeline. Your backups. These are the things that accumulate lock-in and cost, and they are the things where control actually changes your economics. The full case for that split is in the hybrid stack: self-hosted core, cloud for overflow.

The mistake people make is treating self-hosting as all or nothing. The maximalist self-hosts DNS and email and edge protection and spends every weekend firefighting things that were never going to matter. The renter puts the database and the app on a managed platform and pays a lock-in tax on the exact assets that carry their business. Both got the line wrong.

Draw it deliberately. Own the core, where data gravity and cost compound. Rent the commodity edges, where scale and reputation are the real product. When you run the core on infrastructure you control, like HostSSH, and rent the genuinely hard commodities, you get the ownership that pays off without the 3am pages that do not. That is what a hybrid stack is actually for.