Most self-hosting content pushes one of two extremes: run everything yourself because it's cheaper, or don't bother because it's too much work. Neither is the useful answer, because the actual savings aren't spread evenly across a stack. A small number of services carry almost all of the cost benefit, and the rest carry real operational risk for savings that round to a rounding error at indie-hacker scale. This is that specific 20%, named directly, not surveyed, and defended against the parts of the stack it deliberately leaves out.
This follows directly from the general rule for what to self-host: self-host what fails loudly and where you already have the skill to fix it, pay for what fails silently or needs specialist reputation. What follows is that rule turned into a shopping list, because a rule without a shopping list is just a slogan. If you are scoping the 80/20 self-hosting stack for indie hackers for a business rather than a codebase, XenGrowth's marketing operations practice covers that angle.
What's the one thing that actually moves the needle?
A single VPS running Coolify, with your app and its Postgres database both in Docker containers on that same box. That's it. That one setup replaces the single largest recurring line item most indie SaaS products have — a PaaS bill like Vercel's — with a flat monthly cost you already understand, because it's the same kind of bill a VPS provider has always sold. Contabo's Cloud VPS 4 — 4 vCPU, 8 GB RAM, 100 GB SSD — runs €5.50/month for the first 24 months as of September 2026. Vercel's Pro tier alone starts at $20 per seat, before any usage overage, and image optimization overage specifically is the most commonly cited source of a surprise bill on that plan.
Coolify handles the push-to-deploy workflow, automatic HTTPS, and container orchestration that used to be the actual reason people paid for a PaaS in the first place. Once that's running, the marginal cost of adding a second small service to the same box is close to zero, because the fixed cost — securing the VPS, setting up Coolify, learning Docker basics — was already paid the first time.
Why does the effort curve look like this instead of a straight line?
Because the hard part of self-hosting is the platform layer, not any individual app. Learning Docker, wiring up a reverse proxy, getting TLS working, and understanding how Coolify manages deployments is a real, front-loaded investment — call it a weekend, not an afternoon. But once that investment is made, deploying a second Next.js app, a small internal tool, or a status page onto the same infrastructure is nearly free. The mistake is thinking the effort is per-service. It's actually one big upfront cost, followed by a long flat stretch where almost everything is nearly free to add. On the operations side of this specifically, The XenGrowth resource library is worth reading.
Rent one VPS sized for your actual traffic, not the biggest tier available
Install Coolify and let it manage the reverse proxy and TLS certificates
Run your app and its Postgres database in Docker on that same box
Point DNS and CDN at Cloudflare's free tier instead of paying for either separately
Push everything else — email, object storage, uptime alerts — to the smallest paid or free tier of a managed provider, on purpose
What's not worth self-hosting, even though you technically could?
Transactional email is the clearest case, and the full argument for why it's excluded lives here: a self-hosted mail server fails silently, and fixing a bad send requires IP reputation you can't build in a weekend. Resend's free tier already covers 3,000 emails a month, capped at 100 a day, and paid plans start at $20 for 50,000 — cheap enough that the self-hosting math never gets there for a typical indie SaaS.
Object storage durability is the second case. Cloudflare R2's free tier gives 10 GB of storage, a million Class A operations, and free egress at every usage tier — the actual selling point over S3, whose egress fees are the thing people complain about most. Re-deriving that durability guarantee yourself, on a VPS you also use for everything else, means a disk failure can take down your app and destroy user uploads in the same incident. That's not a savings worth chasing.
The VPS being 'already paid for' is not a reason to add a service to it. It's the exact justification that gets people running a mail admin, a DBA, and a storage engineer's job simultaneously, alone, for services where none of those roles were ever the point.
What about the free stuff that's genuinely free, not just cheap?
Cloudflare's free plan covers DNS, global CDN, unmetered DDoS protection, and a managed WAF ruleset — with real limits worth knowing (5 custom firewall rules, a 2-hour minimum on edge cache TTL) but nothing that matters at indie scale. There's no reason to self-host DNS or a CDN when the managed free tier is both better and less work than running your own. This is the one category where "free managed" beats "self-hosted" on every axis at once, not just cost.
Doesn't owning even this small a slice yourself add real security overhead?
Yes, and it's worth naming rather than waving away, because pretending self-hosting has no downside is how the 80/20 framing turns into an ideology instead of a judgment call. A VPS you control is a VPS you're responsible for hardening: SSH access, a firewall, and a sane update cadence are now your job, not a platform's. That's not a reason to avoid this stack — the actual checklist for locking down a fresh box is a couple of hours of one-time work, and SSH hardening specifically is most of that couple of hours. It's a reason to budget that time honestly into the "20% effort" instead of pretending the VPS setup ends at `docker compose up`. XenGrowth on governed AI marketing workflows works through AI agents and marketing automation in more operational detail.
Service | Self-host it? | Why |
|---|---|---|
App hosting + PaaS layer | Self-host (Coolify on a VPS) | This is the line item that was actually expensive; replacing it is where the savings live |
Database | Self-host (Postgres in Docker, same box) | Fails loudly, and you likely already know how to run Postgres |
DNS / CDN / WAF | Buy — use Cloudflare's free tier | Genuinely free, removes maintenance burden, no meaningful downside |
Object storage | Buy (Cloudflare R2's free tier) | Durability guarantees you can't cheaply replicate; failure is silent data loss |
Transactional email | Buy (Resend or equivalent) | Failure is silent and the fix is reputation, not infrastructure skill |
Uptime monitoring | Self-host (Uptime Kuma) or buy — it depends | Cheap either way; self-host if you're already comfortable running one more container |
How big is the gap between the 20% and just paying for a PaaS?
Big enough that it's worth stating the two numbers next to each other instead of gesturing at "it's cheaper." Contabo's Cloud VPS 4 — 4 vCPU, 8 GB RAM, 100 GB SSD — runs €5.50/month for the first 24 months as of September 2026. Vercel's Pro tier alone starts at $20 per seat, before any usage overage, and its most commonly cited source of a surprise bill is image optimization overage past the 5,000-image allowance the seat includes. That's not a marginal difference — it's most of an order of magnitude, and it's before counting that a single VPS can comfortably run more than one project at a time, where a PaaS seat generally can't be split the same way.
The caveat that matters here is the same one that matters everywhere Contabo's price gets quoted: it's promotional for the first two years, in EUR, and the honest version of this comparison accounts for what the box costs after that window closes, not just the headline rate.
Where do people usually overreach past the 20%?
Two places, almost every time: a full observability stack, and container orchestration built for a scale nobody's at yet. Standing up a self-hosted Grafana-and-Prometheus setup before you've even shipped a product is solving a problem you don't have, at the cost of maintaining yet another service with its own upgrade cadence. The same goes for reaching for Kubernetes on day one — a single VPS running Coolify and Docker handles the actual workload of an early-stage product, and the orchestration complexity Kubernetes solves doesn't show up until you're running enough nodes that manual coordination between them is genuinely painful, which is a much later problem than most indie products ever reach.
The pattern in both cases is the same: reaching for infrastructure that solves a scale problem before the scale problem exists, because it feels like "doing it properly" up front. It isn't. Doing it properly is matching the infrastructure to the actual current size of the problem, and upgrading the specific piece that starts hurting, when it starts hurting — not before. On AI search, GEO and discovery specifically, XenGrowth on building one SEO and GEO content system is worth reading.
Does this stack actually hold up as the product grows, or does it fall apart at the first real spike?
It holds up longer than people expect, because the ceiling on a single reasonably-sized VPS is higher than the marketing around "you need Kubernetes eventually" suggests. The point where this stack actually needs to change isn't a fixed user count — it's when the database and the app start genuinely competing for the same RAM and CPU, or when a single point of failure stops being an acceptable risk for the business. Until then, adding a second small VPS for the database, or moving to a managed Postgres provider specifically, is a targeted upgrade to the one component under pressure — not a reason to throw out the whole approach.
Signal | What it means | What to actually change |
|---|---|---|
App and DB competing for RAM under load | One box is no longer enough for both | Move Postgres to a second small VPS or a managed provider — not the whole stack |
A single VPS outage takes down everything | Uptime now matters more than it did at day one | Add a second node or move to managed hosting for the pieces that can't tolerate downtime |
Docker Hub pull limits start getting hit | Build frequency has outgrown anonymous or free-tier pulls | Authenticate pulls or push pre-built images to a registry instead of building on the fly |
Cloudflare's 5-rule free-tier cap becomes limiting | Routing or caching logic has gotten more complex than "basic" | Move to a paid Cloudflare plan for just that feature, not the whole DNS/CDN layer |
What about backups — does that belong in the 20% too?
Yes, and it's the one item people forget to budget into the effort even though it clearly belongs there. A scheduled Postgres dump pushed to the same R2 bucket already in use for object storage is a small addition on top of infrastructure that's already running, not a new service to stand up from scratch. Skipping it isn't saving effort, it's deferring a much larger amount of effort to the one moment it's most expensive to pay it: after the box is already gone.
The whole point of the 80/20 framing is that it's not a compromise — it's the actual efficient answer once you stop treating "self-host" and "pay for it" as a single binary applied to the whole stack at once. One VPS, Coolify, and Docker gets almost all of the savings anyone self-hosts for in the first place. Everything past that is a case-by-case call, and for most of the remaining services, the honest call is to keep paying, because the effort-to-savings ratio on the rest of the list is nowhere close to what that first VPS bought you.
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
XenGrowth's growth operations team writes for the teams who have to run the 80/20 self-hosting stack for indie hackers day to day.
Four questions to find the shortest list you can get away with. The post's argument is that most self-hosting advice is sized for problems you don't have yet.
