Self-host vs SaaS: when to pay vs when to run it yourself
Status: 🟩 COMPLETE Last updated: 2026-06-21 Plain-English tagline: For every service in your stack — hosting, database, auth, monitoring — you can pay a SaaS company or run it yourself. The math changes with scale. Default to SaaS until you have specific reasons not to.
What this decides
For each service, choose:
- SaaS (managed) — pay a company to run it for you (Vercel, Supabase, GitHub, Resend, Sentry)
- Self-hosted — run it on your own infrastructure (a VPS, your laptop, a Raspberry Pi, AWS bare metal)
The choice is per-service; you can mix freely. Bible Quest is all-SaaS; many serious apps are mostly-SaaS with self-hosted pieces.
The short answer
Default: SaaS for almost everything when starting. The free / cheap tiers cover small projects; the time you save is enormous.
Self-host when:
- Cost at scale becomes obviously worse than self-hosting + ops time
- Data sovereignty / compliance requires you to control the infrastructure
- You need customization the SaaS doesn’t offer
- The SaaS doesn’t exist (uncommon in 2026)
For solo developers and small teams in 2026, the default is “SaaS everything” and stays that way until you have ~$10k/month of SaaS bills.
The factors that matter
- What’s your time worth? A SaaS that saves you 10 hours of setup + ongoing ops at 25.
- What’s the cost at your scale? A free-tier SaaS costs nothing; a self-host costs at least a server. At 10x scale, SaaS may be 50 of self-host + 10 hours of ops.
- How important is uptime? SaaS providers have full-time SRE teams; your self-host has you.
- What’s the data sensitivity? Some regulated data (health, financial) has hosting requirements that SaaS may not meet.
- Do you need customization? SaaS is opinionated; self-host lets you do anything.
- Are you the bottleneck? If ops takes you away from features, SaaS pays for itself.
When to pick SAAS
- You’re starting a project. Don’t self-host anything until something forces you to.
- The free tier covers your current scale. Why pay anything?
- You don’t want to maintain anything. Backups, patches, scaling, monitoring — outsource it.
- You value not-being-on-call. SaaS providers handle incidents at 3am; you don’t.
- The service has compounding network effects (GitHub for discoverability, Vercel for preview URLs, Stripe for trust).
Common SaaS choices for the modern Next.js stack:
| Layer | SaaS choice |
|---|---|
| Source control + CI | GitHub |
| Hosting | Vercel (or Netlify, Cloudflare Pages, Railway) |
| Database + auth | Supabase (or Neon, PlanetScale, Firebase) |
| Transactional email | Resend (or Postmark, SendGrid) |
| Monitoring | Sentry, Better Stack |
| Analytics | Vercel Analytics, Plausible, Fathom |
| AI / LLM | Anthropic, OpenAI, Google APIs |
| Payments | Stripe |
| File storage | Supabase Storage, AWS S3, Cloudflare R2 |
All SaaS. Bible Quest uses a subset of these — all SaaS, no self-hosted infrastructure of any kind.
When to pick SELF-HOST
- Cost at scale is dominant. A 1000/month Pro tier for the same workload — once you have the scale to justify it.
- Compliance requires it. HIPAA, certain government contracts, EU data residency rules.
- You need deep customization. A custom Postgres extension. A specific kernel version. A non-standard auth flow.
- You’re learning ops. Self-hosting is excellent for learning what SaaS abstracts.
- The service is genuinely simple. A static blog on a Hetzner box might be 30 minutes of setup and $4/month forever.
Common self-host candidates (when reasons exist):
- Postgres — many teams move off SaaS Postgres when they hit ~$500/month
- Redis — usually self-hosted from day one (cheap, simple)
- Background job runners (BullMQ, Inngest self-hosted)
- Static asset hosting — when CDN bandwidth costs matter
The hybrid: SaaS for the painful parts, self-host for the simple parts
A common shape for medium-size apps:
- App hosting: Vercel (avoiding ops)
- Database: self-hosted Postgres on a beefy VPS (cost at scale)
- Auth: Supabase Auth or Auth0 (auth is painful to get right)
- CDN: Cloudflare (free)
- Email: Resend (deliverability is painful)
The principle: pay for the things that are hard to operate. Self-host the things that are simple.
The hidden cost of self-hosting
When evaluating “self-host saves $X/month,” include:
- Initial setup time — hours to days.
- Maintenance time — patches, version upgrades, certificate renewals.
- Monitoring setup — you can’t fly blind.
- Backups — and verified-restorable backups, not just the existence of files.
- Incident response — when it breaks at 3am.
- Compliance + security — SOC 2, SSL, intrusion detection.
- Capacity planning — when does the box need to be bigger?
For a hobby/side project, 5/month self-hosted that needs 5 hours/month of attention.
For a serious business, the math eventually flips — but later than most people think.
What if I’ve already chosen?
“I started SaaS and want to migrate parts to self-host”: identify the highest-cost SaaS service. Audit whether self-hosting is actually cheaper once you include ops time. If yes, migrate ONE service. Don’t try multiple at once.
“I started self-hosted and the ops is killing me”: evaluate moving the worst-pain pieces to SaaS first. Postgres → managed Postgres. Email → Resend. Often a partial move is enough.
“My SaaS bill is growing unsustainably”: check tier ceilings. Often you can negotiate Enterprise pricing once you’re at meaningful scale (~$2k+/month). Provider competition is real.
“I want to leave a SaaS but I’m locked in”: if the SaaS uses open standards (Postgres is portable; Supabase Auth uses standard JWTs; GitHub repos clone cleanly), the lock-in is mostly time, not technical. If it uses proprietary APIs (Firebase, some Auth0 features), the lock-in is real.
See also
- Free tier vs paid tier 🟩 🟦 — choosing within a SaaS
- What is the cloud? 🟩 — IaaS/PaaS/SaaS distinctions
- Vercel 🟩 🟦
- Supabase 🟩 🟦
- GitHub 🟩 🟦
- Containers and Docker 🟩 🟦 — the modern self-host primitive
- Operating systems overview 🟩 🟦
- Decision frameworks — index 🟩