When Your FOSS Project Outgrows a $5 VPS

Every FOSS project starts on a shoestring. A $5 VPS, a free domain from Freenom (don’t do this), maybe a GitHub Pages site. It works. Until it doesn’t.

Here’s how to recognise the moment your project has outgrown its infrastructure — and what to do about it before something breaks.

The Warning Signs

Your project has outgrown its budget VPS when you see any of these:

The OOM killer visits regularly. Your database gets killed at 3am because backups run and there’s only 1 GB of RAM. You’ve learned to recognise the Out of memory: Killed process line in dmesg like an old enemy.

Swap usage is permanent. Your server has been using 800 MB of swap for three weeks. Nothing is fast. Everything is slow. You tell yourself “it’s fine” but you know it’s not.

Disk space is a monthly crisis. Every month you SSH in and find 92% disk usage. You run ncdu, delete some logs, and buy another week. This is not a strategy.

You’ve become nocturnal. A user in a different timezone reports downtime, and you’re the only person who can fix it. You wake up at 4am to restart a Docker container that leaked memory.

Updates are scary. You put off apt upgrade for weeks because you’re afraid something will break and you won’t have time to debug it. When you do update, you hold your breath.

Your project’s bus factor is now one. If you got hit by a bus tomorrow, nobody else knows the server password, the backup schedule, or how DNS is configured.

What’s Actually Happening

These symptoms aren’t just about server specs. They’re about operational maturity.

A $5 VPS is built for personal projects. It assumes one user, one administrator, and a failure mode of “I’ll fix it when I get home.” It provides:

• Shared CPU that might throttle under sustained load
• Minimal RAM that can’t handle concurrent services
• Limited disk I/O that chokes during backups
• No redundancy — if the host fails, you’re down
• No monitoring — if something breaks, you find out from users

When your project has users, contributors, or anything resembling a production workload, those assumptions break.

The Upgrade Paths

There are three ways to level up. The right one depends on your project’s size, budget, and whether you actually want to be a sysadmin.

Path 1: Beefier Self-Hosting (€15-40/month)

Move to a larger VPS or dedicated server:

What improves: RAM headroom stops the OOM killer. NVMe storage means backups don’t cripple your database. Dedicated CPU cores mean your web server doesn’t slow to a crawl under load.

What doesn’t: You’re still the on-call admin. Backups are still your responsibility. Monitoring is still self-managed. When the server has issues at 2am, you’re still the one getting paged.

Best for: Projects where at least one person genuinely enjoys ops work and has the time to do it properly. You’re ready to set up proper monitoring, test backups regularly, and document everything.

Path 2: Add Redundancy (€30-80/month)

Split your services across multiple servers:

• App server (Hetzner CX22, €4.50/mo) — web apps, APIs
• Database server (Hetzner CX22, €4.50/mo) — dedicated PostgreSQL/MySQL
• Backup server (BuyVM storage slab, $5/mo) — Restic target
• Monitoring node (RackNerd, $1.50/mo) — Uptime Kuma, external checks
• CI runner (Hetzner CX22, €4.50/mo when running, spot pricing)

What improves: Your database and app can’t kill each other. If your CI runner thrashes the CPU, your website stays up. External monitoring catches failures that self-monitoring misses.

What doesn’t: More complexity. More things to maintain. More servers to update, monitor, and secure. You’re trading hardware headroom for architectural resilience.

Best for: Projects with multiple active contributors and someone who genuinely understands distributed systems. If the phrase “split your database onto its own server” makes you excited rather than anxious, this is your path.

Path 3: Managed FOSS Hosting (€50-100/month)

Let someone else handle the infrastructure:

OpsHelp provides managed hosting built on the same FOSS stack and providers you’d use yourself — Hetzner servers, Cloudflare DNS, Docker-based deployments, Restic backups. The difference: you don’t manage it.

The cost comparison:

What improves: Everything operational. Security updates happen on schedule because someone gets paid to do them. Backups are tested because it’s a contractual obligation. Someone else responds to 2am alerts.

What doesn’t: You don’t get root access to experiment with exotic configurations. Your stack is opinionated (Hetzner + Cloudflare + FOSS tooling). You’re paying a premium for operational peace of mind.

Best for: Projects where the maintainers want to write code, not debug kernel panics. Nonprofits who need reliable infrastructure without building an ops team. Anyone who has already done the self-hosting learning and is now tired of being on call.

Making the Decision

A practical framework:

Stay on the $5 VPS if:

• Your project has fewer than 50 active users
• Downtime is an annoyance, not a crisis
• Your data is fully backed up elsewhere
• You enjoy the ops work and learn from it
• You have nothing resembling compliance requirements

Upgrade to a larger VPS (€15-40/mo) if:

• You’re hitting RAM/CPU/disk limits regularly
• You have 50-500 active users
• You want to learn production ops at the next level
• You have time to invest in proper monitoring and backups

Move to managed hosting if:

• You have more than 500 active users or any paying users
• Downtime has real consequences (donations, reputation, data)
• Your project has multiple contributors and you’re the only ops person
• You’ve done the self-hosting learning and are now just tired
• Your project’s mission is more important than your ops education
• You handle donor data, user accounts, or legally sensitive information

The FOSS-Native Managed Option

OpsHelp’s managed hosting is specifically built for FOSS projects. It’s not a generic cloud provider — it’s a FOSS-aligned hosting service that uses the same stack and providers we’d recommend you use for self-hosting:

• Hetzner for compute (the same provider we rank #1 for FOSS-friendly VPS)
• Cloudflare for DNS and CDN (free plan works, managed setup included)
• Docker + Caddy for application deployment and TLS
• Restic for encrypted, deduplicated backups
• Prometheus + Grafana for monitoring and dashboards
• Ansible for configuration management

Every configuration is documented. If you ever want to take over self-management, you get a complete export — server configs, DNS records, backup locations, the works. It’s managed, but it’s not a trap.

From £50/month for a single server with monitoring, backups, and support. That’s less than the real cost of self-hosting at mid-level engineer rates.

You’re Not Failing FOSS by Paying for Ops

There’s a weird guilt in FOSS communities about paying for infrastructure services. “Real” FOSS projects self-host everything. “Real” sysadmins compile their own kernels.

This is nonsense.

The FOSS projects that matter most — Linux, Debian, PostgreSQL, Python — all have funded infrastructure teams. They don’t ask volunteers to be on call for production infrastructure. They pay professionals because reliable infrastructure for projects that people depend on is professional work.

Your project might not be Linux. But if people depend on it, their expectations of reliability are the same. Paying for managed infrastructure isn’t betraying FOSS values. It’s acknowledging that some things are worth doing professionally.