Self-Hosted vs SaaS: When It Actually Makes Sense to Run Your Own Infra

This blog leans heavily on self-hosting — tile servers, routing engines, reverse proxies, all run on a VPS you manage yourself. It’s worth stepping back and asking the question honestly, because self-hosting is not universally the right call, and treating it as a default rather than a decision is how indie devs end up burning weekends on ops instead of shipping product.

The real trade, stated plainly

Self-hosting trades money for time and responsibility. A managed SaaS trades time and responsibility for money. Neither side of that trade is free — the question is which currency you have more of, and at what stage of your project.

When self-hosting wins

The cost curve is punishing at your scale. Metered APIs (map tiles, routing, some AI inference) charge per unit of usage. If your usage is high and predictable, a fixed-cost VPS running the equivalent open-source stack can be an order of magnitude cheaper — this is exactly the math behind self-hosting map tiles instead of paying per load.
You need data control you can’t get otherwise. Sending every user’s location or personal data through a third party is a real liability, not just a preference, in regulated or trust-sensitive products.
The self-hosted version is genuinely mature. Nginx, Postgres, OSRM, MapLibre tile servers — these are battle-tested, well-documented, and unlikely to disappear or change pricing on you overnight. Self-hosting a shaky, poorly-maintained open-source project is a different bet entirely.
You’re the only one who’ll operate it. A solo dev already comfortable with Docker and a VPS pays a low marginal cost to add one more self-hosted service. A team paying multiple salaries to context-switch into ops work pays a much higher effective cost for the same decision.

When SaaS wins

You need it working today, not this weekend. Time-to-first-result matters most in the earliest validation phase of a product — before you know if anyone wants it, infrastructure ops is pure overhead.
The managed version includes things you’d have to build yourself. Managed databases with automated backups, point-in-time recovery, and failover aren’t “the same thing, cheaper” when self-hosted — they’re a different, larger scope of work you’d otherwise own.
Compliance or uptime SLAs are non-negotiable. If a contract or regulation requires a formal SLA, most budget self-hosted setups (see: Hetzner and friends, none of which offer one) simply don’t qualify, full stop.
The team, not just the founder, needs to operate it. Onboarding a second or third person onto a bespoke self-hosted stack costs real time. A well-documented SaaS product often has a shorter ramp.

The middle path: self-host the stable stuff, buy the volatile stuff

The false choice is “self-host everything” vs. “SaaS everything.” A more useful default for an indie stack:

Self-host infrastructure that’s mature, stable, and where you have real usage volume: map tiles, routing, reverse proxy, your own API layer.
Buy managed services for things that are genuinely hard to run well yourself, or where you’re not the expert: managed Postgres/auth (Supabase, as covered in the auth flow guide), transactional email, payment processing.
Buy KYC/identity verification as a managed service once volume justifies it, but it’s reasonable to start with an open-source liveness check and design for a clean swap later.

The pattern across all of these: self-host what’s core to your product’s economics and mature enough to trust; buy what’s peripheral, compliance-sensitive, or where a vendor’s specialization genuinely beats what you’d build.

A concrete way to decide, per service

Ask these in order, and stop at the first one that gives you a clear answer:

Is there a hard compliance/SLA requirement? If yes, SaaS (or a self-hosted setup on infrastructure that itself offers an SLA, which most budget VPS providers don’t).
Does usage volume make the metered cost painful? If yes and the self-hosted alternative is mature, lean self-hosted.
Will more than one person need to operate this? If yes, weight toward whichever option has better documentation and a shorter onboarding ramp — often SaaS, sometimes a well-documented self-hosted stack if your team already knows it.
Is this core to your product’s economics, or peripheral? Core and high-volume leans self-hosted over time; peripheral and low-volume almost always stays SaaS.

Why this blog is self-hosting-heavy anyway

Worth being transparent about the bias here: the guides on this blog lean self-hosted because that’s the stack that makes sense for a solo dev running a regional product with real, predictable usage volume — map tiles and routing calls that would otherwise rack up a metered bill. That’s a specific set of conditions, not a universal recommendation. If your situation doesn’t match it — early-stage validation, a small team, compliance requirements — the right call is very possibly the opposite of everything else on this blog, and that’s fine. The framework above is the actual tool; self-hosting is just where it points for this particular kind of product.