ok so I finally got Ronnie’s whole stack running the way I actually wanted it, and I’ve been mildly unbearable about it this week. instead of continuing that trend in person, this is the structured version.
the argument for self-hosting was never purely technical for me. it’s philosophical. and that’s exactly why it’s easy to delay indefinitely — because philosophy doesn’t create urgency the way broken systems do.
the actual pressure point is simple: anything you depend on that you don’t control is a single point of failure. not theoretically. operationally.
The thing you don’t notice until it changes
platform dependence rarely feels like risk while it’s working. it feels like convenience, because that is the interface layer you’re shown.
the problem is that stability is conditional. pricing shifts, product sunsets, policy changes — all of it happens outside your control window. you only see the constraint when it triggers.
at that point, it stops being a design choice and becomes a recovery problem.
Where I actually drew the line
Ronnie — my Ubuntu 24.04 homelab box — now runs a full local stack.
Nextcloud replaces cloud storage. Jellyfin replaces streaming subscriptions. Paperless-NGX handles documents. Immich stores photos. the arr stack handles media workflows. Pi-hole and Unbound control DNS locally.
there was a point where a DNS misconfiguration between Pi-hole and Unbound turned into a cascading failure mode, and fixing that loop was probably the most satisfying systems debugging I’ve done all year. not because it was complex, but because it was mine.
Not everything should be self-hosted. Email is a good example. Deliverability, spam reputation, and infrastructure overhead outweigh the benefit for my use case.
Convenience is not the problem
this is not an anti-convenience argument. it’s an anti-invisibility argument.
the issue is not using platforms. the issue is depending on them without acknowledging that dependence.
for anything structurally important — work, data, systems that cannot disappear without consequence — the relevant question is not “is this convenient?” but “what happens if this stops existing tomorrow?”
Why this scales poorly as you get smaller
larger organizations have leverage: contracts, SLAs, escalation paths. smaller operators do not.
for independent systems — personal infrastructure, small projects, early-stage work — platform changes are unilateral. you receive notice after the decision is made.
that asymmetry is the core reason this matters more at smaller scale, not less.
What actually matters in practice
the hard part is not running docker compose files or standing up services. that is mechanical work.
the harder part is classification: deciding what is structurally critical versus what is simply convenient.
once that distinction is clear, the architecture follows.
Closing position
the goal is not total self-hosting. that becomes its own form of dependence, just redirected inward.
the goal is constraint awareness: knowing what you rely on, why you rely on it, and what you would do if it disappeared.
Ronnie’s stack exists because a subset of systems crossed that threshold for me. everything else remains negotiable.
that line will move over time. it should.
what matters is that it is drawn deliberately, not implicitly.