When to Self-Host vs. When to Pay: The Decision Framework

The self-hosting community has a gravitational pull. Once you successfully deploy one service on your own VPS — once you see Nextcloud running on hardware you control, serving files without a monthly fee to anyone — the instinct is to self-host everything. Every SaaS subscription becomes a personal challenge. "I could run that myself." And you probably could. The question isn't whether you can. The question is whether you should.

This article isn't about ideology. The privacy argument, the data sovereignty argument, the "I don't trust big tech" argument — those are real, and they matter. But they don't help you make Tuesday's decision about whether to self-host your project management tool or pay $10/month for a hosted one. For that, you need a framework that names the actual trade-offs and makes the call obvious once you see them clearly.

What The Docs Say

The official documentation for every self-hostable application says roughly the same thing. "Deploy with Docker in minutes." "Simple setup." "Full control over your data." The Awesome-Selfhosted GitHub list — the canonical directory of self-hostable software — has over 1,800 entries, and every one of them implies that self-hosting is a straightforward proposition.

The managed platforms tell a different story. Vercel's landing page emphasizes zero-config deployments and global edge networks. 1Password's marketing highlights their security team and compliance certifications. Google Workspace sells the idea that email just works, every time, for everyone. The managed pitch is always the same: we handle the complexity so you don't have to.

Both narratives are partially true. Self-hosting is simpler than it was five years ago — Coolify, Docker Compose, and Cloudflare Tunnels have genuinely reduced the operational burden. And managed services do handle real complexity that would otherwise be your problem. The honest answer lives in the gap between the two stories.

What Actually Happens

Every self-hosting decision comes down to three variables. Once you can assess them clearly, the decision almost makes itself.

Variable One — How Critical Is Uptime

This is the variable that ends most self-hosting conversations before they start. If a service going down for four hours on a Saturday costs you actual money — lost sales, broken client workflows, compliance violations — you should not be running it on a single VPS that depends on you to fix things.

Managed platforms have on-call teams, redundant infrastructure, and SLAs. Your Hetzner VPS has you. When the server locks up at 2am because a Docker container ate all the RAM, the recovery time is however long it takes you to wake up, SSH in, diagnose the problem, and restart the service. For a personal Jellyfin server, that's fine — nobody dies if movie night gets delayed. For a client-facing application that processes orders, it's not fine.

The middle ground is services where downtime is annoying but not costly. Your personal Nextcloud goes down while you're at work — you can't access a file for a few hours. Your Gitea instance has an issue — you switch to the GitHub mirror and fix it that evening. Your Miniflux RSS reader crashes — you catch up on feeds tomorrow. These are the services where self-hosting makes the most sense, because the cost of failure is low and the benefit of control is real.

Variable Two — How Complex Is the Maintenance

Some self-hosted services are deploy-and-forget. Others are part-time jobs. The difference isn't always obvious from the README.

Low maintenance — deploy and done. Static file servers, RSS readers (Miniflux, FreshRSS), bookmark managers (Linkding), DNS ad-blocking (AdGuard Home, Pi-hole), media servers (Jellyfin). These applications have small attack surfaces, infrequent updates, and failure modes that are simple to diagnose. You deploy them, check on them occasionally, and they just run. The Docker container starts, serves requests, and doesn't demand attention.

Medium maintenance — periodic attention required. Databases (PostgreSQL, MariaDB), CMS platforms (Ghost, WordPress), monitoring stacks (Grafana + Prometheus), project management tools (Vikunja, Plane), Git hosting (Gitea, Forgejo). These need regular backups, occasional version upgrades that require migration steps, and enough monitoring to catch problems before they cascade. You're spending maybe 30 minutes per month per service on care and feeding. Manageable if you're running a few. Burdensome if you're running ten.

High maintenance — a commitment. Email servers, authentication systems, CI/CD pipelines, anything with complex state that's hard to rebuild from scratch. These services have sharp failure modes — email deliverability degrades silently, auth system bugs lock everyone out, CI pipelines break in ways that block your entire development workflow. The operational knowledge required to maintain them well is significant, and the consequences of maintaining them poorly are worse than not having them at all.

Variable Three — How Sensitive Is the Data

Data sensitivity cuts both ways, and both cuts matter.

For personal files, photos, notes, and private documents — self-hosting means the data lives on hardware you control, encrypted at rest, accessible only to you. No third-party employee can access it. No terms of service change can lock you out. No acquisition can hand your data to a company you didn't choose. This is the strongest argument for self-hosting, and for services like file storage (Nextcloud), it's genuinely compelling.

For data where security failures have serious consequences — authentication credentials, payment information, client data with contractual obligations — self-hosting means you're the security team. You're responsible for patching, for access control, for encryption, for incident response. One misconfigured Docker port and your PostgreSQL database is exposed to the internet. Managed services aren't immune to breaches, but they have dedicated security teams, compliance audits, and insurance. You have a VPS and good intentions.

The framework isn't "sensitive data should always be self-hosted" or "sensitive data should never be self-hosted." It's "who is better positioned to protect this data — you or a team of specialists?" For your personal files, you are. For your customers' payment information, you're not.

The Decision Grid

Putting the three variables together produces clear categories.

Self-host confidently. These services score well on all three variables — downtime is tolerable, maintenance is low, and you benefit from controlling the data. File storage and sync (Nextcloud). Media server (Jellyfin). Git hosting for personal projects (Gitea, Forgejo). Bookmark management (Linkding). RSS (Miniflux). DNS-level ad blocking (AdGuard Home). Recipe management (Mealie). Note-taking (Memos). These are the bread and butter of self-hosting, and the case for running them yourself is strong.

Self-host cautiously. These services have a trade-off that makes the decision context-dependent. Databases — self-host if you understand backup and recovery, use managed if the data matters and you're not confident in your backup game. CMS platforms like Ghost or WordPress — self-host if you're the only user and can tolerate occasional downtime, use managed if it's a business site. Monitoring (Grafana/Prometheus) — self-host because the irony of your monitoring platform going down is too perfect to risk with a paid service, but also because the self-hosted version is genuinely better for monitoring self-hosted infrastructure. Project management (Vikunja, Plane) — self-host if you're a solo user, but think hard before moving a team onto infrastructure you maintain alone.

Don't self-host. These services fail on at least two of the three variables, and the failure modes are severe enough to override the benefits of control. Email — deliverability is a full-time reputation management job, and Fastmail at $5/month is the obvious answer. Authentication (Keycloak, Authentik) — a misconfigured auth system is a security catastrophe, not an inconvenience. Payment processing — PCI compliance exists for a reason, and that reason is that running payment infrastructure is extraordinarily hard to do safely. DNS resolution for production services — Cloudflare's free DNS is better than anything you'll run yourself. Anything where downtime costs real money and you're the only person who can fix it.

The Gap Between "I Can" and "I Should"

The Awesome-Selfhosted list is dangerous in the same way a hardware store is dangerous to someone who just learned to use a drill. Everything looks like a project. Every SaaS subscription looks like an unnecessary expense. The capability to self-host something creates a gravitational pull toward actually doing it — and that pull doesn't account for the time cost, the maintenance burden, or the opportunity cost of spending your weekend debugging Keycloak instead of doing literally anything else.

The honest math: a Hetzner VPS running five carefully chosen self-hosted services — Nextcloud, Jellyfin, Gitea, Miniflux, AdGuard Home — costs about $5/month and maybe an hour of maintenance per month. That's a clear win. The same VPS running fifteen services including a mail server, a CI/CD pipeline, a monitoring stack, a project management tool, and a database cluster costs $5/month in server fees and 15 hours per month in your time. If your time has any value at all, the managed alternatives are cheaper.

The Migration Path That Actually Works

Start with managed services. Understand what the service does, how you use it, and what would happen if it went down. Then — and only then — self-host the ones where the case is clear. You're migrating from a position of knowledge, not experimenting from a position of curiosity.

Every self-hosted service should have a documented exit path. If you stop wanting to maintain Nextcloud, your files should be exportable to Google Drive or Dropbox in an afternoon. If Gitea becomes a burden, your repositories should mirror to GitHub automatically. The exit path isn't an admission of defeat — it's an acknowledgment that your priorities might change, and infrastructure should serve you rather than the other way around.

The people who get the most value from self-hosting are the ones who self-host selectively. Five services they genuinely use, on a single well-maintained VPS, with good backups and a clear understanding of what each service demands. The people who burn out are the ones who treat the Awesome-Selfhosted list like a checklist — deploying everything, maintaining nothing, and spending their weekends fighting Docker networking issues instead of using the tools they deployed.

The framework is simple. Low stakes, low maintenance, high data sensitivity benefit — self-host it. High stakes, high maintenance, or security-critical data — pay someone who does this for a living. The decision is rarely ambiguous once you name the variables. The hard part isn't the framework. The hard part is being honest about which category your specific situation falls into.

This is part of CustomClanker's Self-Hosting series — the honest cost of running it yourself.