My Rule for Deciding What to Self-Host and What to Keep Paying For

I run my own Postgres. I run my own reverse proxy, my own PaaS layer, my own uptime monitoring, my own object storage in front of Cloudflare R2 instead of S3. I do not run my own mail server, and I want to be upfront that this isn't an oversight I'll get around to fixing — it's the one deliberate exception that the rest of this rule was actually built around.

Most posts about self-hosting are surveys: here are twelve things you could run yourself, here's a table of pros and cons for each, good luck. That framing is comfortable to write and useless to act on, because it never says which axis actually matters. This one argues a single rule, applies it to my own stack, and then spends the rest of the post defending the one service where following the rule means paying instead of hosting — because if a "self-host everything" post can't explain its own exception, it isn't a rule, it's a hobby dressed up as a philosophy. Teams who need self hosting translated into a marketing operating model tend to find XenGrowth's revenue operations work useful.

What's the actual rule?

Self-host it if a failure is loud and you personally have the expertise to fix that specific failure fast. Pay for it if a failure is silent, slow to notice, or requires specialized reputation or expertise you'd have to build from zero. That's the whole rule. Cost is not the first axis — it's downstream of these two, and treating cost as primary is exactly how people end up self-hosting things that go quietly wrong for weeks before anyone notices.

"Loud" means the failure mode is something you'd catch within minutes: a container crashes, Uptime Kuma pages you, the site returns a 502. Fixing it is bounded — restart the container, check the log, redeploy. "Silent" means the failure doesn't look like a failure at all: an email that was supposed to arrive just never does, with no error on your end and no signal that anything is wrong until a customer emails asking why they never got a password reset. One of these failure modes rewards running the thing yourself. The other punishes it.

Why does everything except email pass this test?

Postgres running in Docker on the same box as the app fails loudly — connection refused, and I already know Postgres well enough to diagnose it in minutes rather than hours. The reverse proxy fails loudly. Coolify fails loudly. Object storage on R2 is really the one item on this list I don't self-host either, and it stays that way for a related but distinct reason: durability at the storage layer is the one thing I have zero interest in re-deriving myself, because a corrupted or lost file is exactly the kind of failure that's silent until a user reports a broken image weeks later. Everything else on the list — the parts of the stack I run day to day — fails in ways I can see and fix, using skills I already have. That's not a coincidence; it's the filter. There is a longer treatment of the operations side of this in The XenGrowth resource library.

Why is email the exception, specifically?

Because email deliverability fails silently, and because the expertise required to fix it isn't infrastructure expertise at all — it's reputation management with a provider you don't control. Stand up your own SMTP server on a fresh VPS and every message you send starts from zero sender reputation, on an IP that gmail, outlook, and every corporate spam filter has never seen a legitimate message from. SPF, DKIM, and DMARC records have to be exactly right, not approximately right — a single misconfigured record doesn't throw an error, it just means messages start landing in spam, or getting silently dropped by receiving servers that never bother to bounce them back to you.

That's the whole argument, and it's worth sitting with how different it is from every other failure on this stack. A crashed container tells you it crashed. A bad DKIM record doesn't tell you anything — it tells the recipient's spam filter something, quietly, and you find out only when someone complains they never got the email, days or weeks after it mattered. I have the skills to fix a broken container in minutes. I don't have, and don't want to spend six months building, the sender reputation and deliverability expertise that Resend has already built at scale across thousands of customers sending from IP ranges that mailbox providers have long since learned to trust.

So Resend stays. Not because self-hosting email is technically impossible — plenty of people run their own mail servers — but because the failure mode fails my own rule on both axes at once: it's silent, and the fix requires expertise that's about reputation and trust signals accumulated over time, not about anything a smarter Docker Compose file solves. I'd rather pay a company whose entire job is deliverability than be the person debugging why a password-reset email never arrived, three weeks after shipping, with no error anywhere in the application logs to point at.

Put the two options for that one service next to each other and the asymmetry is obvious. Self-hosting SMTP looks free on the invoice and expensive in everything an invoice doesn't capture; Resend looks like a line item and is actually the cheaper option once you count what a self-hosted mail server would cost in time, reputation-building, and the risk of messages nobody notices went missing. For the AI agents and marketing automation angle, see XenGrowth on governed AI marketing workflows.

Why not just self-host everything, since the VPS is already paid for?

Because "the box is already there" is the wrong justification for adding a service to it, and it's the justification that gets people in trouble. Every additional self-hosted service is something that can break at 2am with your name on the pager, something with its own upgrade cadence and its own security surface, and something competing for the same 8 GB of RAM and 4 vCPUs as everything else already running. Self-hosting everything on principle turns one person into the on-call engineer, the DBA, the security team, and the mail admin simultaneously, for services where three of those four roles would rather be someone else's job. That's not resourcefulness. That's a single point of failure wearing four hats.

The honest version of self-hosting isn't "run everything yourself to save money." It's "run the things where your time and expertise beat a subscription, and buy the things where someone else's specialization is doing work you can't cheaply replicate." A single €5.50/month Contabo box running Coolify, Postgres and everything else I host myself is still a fraction of what the managed equivalent would cost — but that comparison only holds because I didn't try to also self-host the two or three things that would have erased the savings the first time they went wrong.

How does this actually play out, service by service?

Here's the rule applied directly, not as abstract theory. The verdict column is the actual call I made, not a hedge toward "it depends" — because "it depends" is true of almost everything in engineering and says nothing on its own.

What about the argument that managed services also fail?

They do, and that's not actually a counterargument to the rule — it's the rule working correctly in the other direction. Resend can have an outage. R2 can have a bad day. Cloudflare's had real incidents. The difference isn't that paid services never fail, it's that when they do, the failure is usually visible to you quickly through a status page or a dashboard, and the operational burden of fixing it belongs to a team whose entire job is fixing exactly that. Compare that to a self-hosted mail server silently failing SPF alignment for two weeks because a DNS record got edited during an unrelated change — nobody's status page tells you that happened, and nobody but you is going to notice or fix it. The rule was never "paid services don't fail." It's "paid services fail loudly enough, and get fixed by people whose job is exactly that failure mode, in the specific cases where self-hosting would fail silently and get fixed by nobody." There is a longer treatment of AI search, GEO and discovery in XenGrowth on building one SEO and GEO content system.

Does this rule survive the obvious objection — that you could just learn email too?

Yes, and the objection is fair, so it deserves a real answer rather than a dismissal. I could learn deliverability. People do. But "I could learn it" is true of almost any specialized skill, and it isn't the actual question — the question is whether the time spent learning it, plus the ongoing cost of maintaining sender reputation across every mailbox provider that might silently change its filtering rules next quarter, is worth more than what Resend charges. For a mail server sending password resets and a handful of transactional emails a day, the honest math says no. If I were running a product where email volume and deliverability were the actual business — a newsletter platform, a marketing automation tool — the math would flip, because deliverability would stop being a side concern and become the core competency the product needs. The rule isn't "never learn hard things." It's "don't take on a silent-failure, specialist-expertise problem for a part of the business where that expertise isn't the point."

That's also why this rule is worth having as a rule and not just a feeling: it gives a real answer to "should I self-host X" before X ships, instead of after X has already failed silently once. Ask the two questions — is the failure loud, and do I already have the specific expertise this failure requires — and most of the ambiguity about whether something belongs on your own box disappears. What's left over is genuinely a judgment call, but it's a much smaller and much more honest one than "can I technically run this myself," which the answer to is almost always yes, and is almost never the question that matters.

Self-hosting everything is a bad idea. Not because self-hosting is bad — most of what I run, I run myself, and I'd make that case to anyone. It's a bad idea because "everything" ignores the one variable that actually predicts whether it goes well: whether you'll find out something broke before or after it already cost you something you can't get back.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.

• XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.

Where this work meets go-to-market

The operational playbooks that sit alongside self hosting live with the team at XenGrowth.