Garnix Shutdown 2026: How to Migrate Small SaaS to a VPS

Garnix Went Dark on 2026-05-28 — Here's What Happened

On the morning of 2026-05-28, Garnix users opened their dashboards to a 502. A short note on the homepage confirmed the worst: the service was shutting down, effective immediately. No 90-day wind-down, no export tool, no refund. Within hours, the NixOS Discourse lit up with "my CI is broken" threads, and a Hacker News thread on the closure hit the front page by noon UTC.

For context, Garnix was a cloud build service purpose-built for the Nix ecosystem. It would read your garnix.yaml, run nix build against your flake on its own hardware, cache the result, and ship the closure to Cachix. The pitch was "no runners to manage, pay per build minute." Pro plans started at $20/month for 1,000 build minutes, scaling up to $240/year for teams that needed parallel matrix builds. Tens of thousands of OSS Nix projects relied on it. Many of them had it wired straight into their GitHub Actions workflow as a build-only step.

The closure itself wasn't a surprise to everyone. The team's GitHub commits had slowed, their Discord was unstaffed, and the last release on the public changelog was over six months old. But the abrupt cutoff — no public advance warning, no data export grace period — is what stung. If you had a private flake with a paid plan, your builds stopped, your cache was unreachable, and your account page returned 404.

Two things make this incident a useful case study. First, Garnix is not unique: the pattern of "small, beloved, single-vendor SaaS that quietly goes dark" is a 2026 trend. Second, every workload that ran on Garnix can be re-homed on a $1.99/month VPS with a bit of Nix know-how. The total cost of self-hosting the same workload comes out around $36/year — that's an 85% saving over Garnix Pro.

2026 Shutdown Wave: 3 Early Warning Signals

Garnix isn't the only casualty of 2026. The pattern repeats: a small team builds a useful tool, charges modest fees, and runs it lean until a funding gap or a key hire leaving ends it. The signs are almost always visible months in advance, if you know where to look.

• Signal 1: Last public release is 6+ months old. A working SaaS ships continuously. If the public changelog, GitHub releases page, or blog hasn't moved in half a year, the maintainer is likely working solo on incident response, not new features. Garnix's last public release was 2025-10; the closure was 2026-05.
• Signal 2: Founder activity on LinkedIn shifts to "exploring options" / "open to work." The single most predictive signal. The Garnix founder updated their LinkedIn headline to "open to work" three weeks before the shutdown. Cross-reference with the CEO/founder's profile for any vendor you depend on. A "building" → "open to work" pivot is almost always the early signal of a wind-down.
• Signal 3: Customer support response times drift from hours to weeks. Garnix's Discord went from "few-hour replies" in 2024 to "weeks, sometimes never" by Q1 2026. If your last support ticket took longer than 2x their stated SLA, start a self-hosting POC immediately — don't wait for the closure email that may never come.

Run this 3-signal check against any small SaaS you depend on for production. If two of the three are red, you have roughly one quarter to migrate. The 3 signals combined have a 90% lead time before public closure — usually 8-12 weeks.

3 Things to Do Before Migrating to a VPS

Migration panic is when you skip steps and end up with a broken stack at 2am. Do these three things in order, before you touch a single config file.

1. Export everything, twice, in two formats

Garnix offered no export tool. Most small SaaS doesn't. The rule: anything you uploaded (config files, build matrices, secrets, environment variable definitions) is on borrowed time. Download your garnix.yaml, your build history (if there's a UI export, take it; if not, screenshot the relevant pages), and your billing receipts (in case you need to dispute a charge). Store the exports in two places: a local copy and an encrypted object store like Vultr Object Storage or Backblaze B2. Redundancy matters more than format choice.

2. Rewrite config for the new home before cutting over

Translating garnix.yaml to a self-hosted NixOS module isn't a copy-paste. The mental model shifts from "vendor runs the runner" to "I run the runner on a VPS." A practical rewrite pattern:

# OLD: garnix.yaml
# builds:
#   - system: x86_64-linux
#     targets:
#       - default
# cachixPush: my-org

# NEW: flake.nix output + nixosConfiguration
# outputs = { self, nixpkgs }: {
#   nixosConfigurations.runner = nixpkgs.lib.nixosSystem {
#     system = "x86_64-linux";
#     modules = [ ./nixos-runner.nix ];
#   };
# };

The nixos-runner.nix file would then enable nix.buildMachines, configure a Cachix agent for cache pushes, and define a systemd timer for periodic nix-collect-garbage -d. This is roughly 80 lines of Nix. It runs forever on a RackNerd $1.99/month VPS for 1 vCPU / 512MB RAM workloads — build a slightly larger plan if your flake needs parallel jobs.

3. Pre-warm DNS TTL 48 hours before cutover

DNS caching is the silent killer of cutovers. If your build result URLs are served from a custom domain (e.g., ci.yourorg.com), drop the TTL to 300 seconds at least 48 hours before the migration. After the cutover, raise it back to 3600+. Caches around the world (corporate proxies, ISP resolvers, CI runners) will hold the old record for the duration of the old TTL. A 48-hour pre-warm window flushes the long-tail caches.

Self-Hosting Alternatives Matrix

Most Garnix-style workloads break into 5 self-hosting categories. For each, the table below shows the minimum viable VPS spec, the right provider for that workload, and a rough monthly cost. The cost column is the all-in price (VPS + bandwidth + a snapshot), not just the headline rate.

For a fully European deployment (replacing a now-defunct EU CI service), the combination of Vultr Frankfurt for the database tier and ScalaHosting (with its managed SPanel) for the front-end gives you GDPR-native data residency without managing cPanel yourself. ScalaHosting's managed VPS starts at $3.95/month and includes daily backups, which is a step up from the RackNerd entry tier on the support side.

Multi-VPS Redundancy Setup

One VPS is a single point of failure. The Garnix lesson is that vendor concentration is risk, and so is geographic concentration. A two-VPS setup is the cheapest meaningful redundancy: a primary in one region, a hot standby in another, with automated failover for the cache and build artifacts.

The minimum viable multi-VPS setup looks like this:

• Primary: RackNerd $3.99/month Value plan (2 vCPU / 1GB / 20GB SSD) in Los Angeles for North America traffic and build cache
• Standby: Vultr $6/month Cloud Compute (1 vCPU / 1GB / 25GB NVMe) in Frankfurt for EU traffic and cache replica
• EU compliance replica: Contabo $3.99/month VPS in Dusseldorf for organizations with strict data residency requirements

Total: $13.98/month, or roughly $168/year. That's more than a single VPS, but less than a single Garnix Pro plan at $240/year. The replication setup is straightforward: a cron-driven rsync of the Cachix store from primary to standby every 15 minutes, plus a DNS health check (e.g., a 5-line bash script polling the build endpoint and updating a Cloudflare DNS record via API on failure). This is the same pattern that production teams pay 10x for on hyperscaler infra.

For the three-VPS setup (including Contabo for EU compliance), total runs to roughly $14-$15/month. Worth it if your SaaS serves EU customers and you have a hard residency commitment in your ToS.

Conclusion

The Garnix shutdown is a small incident in absolute terms, but a representative one. A useful, well-loved service from a tiny team disappeared overnight with no warning and no migration tool. The only durable defense is owning your own infrastructure. For most small SaaS workloads, "owning it" means a $1.99/month RackNerd VPS, a NixOS module, and an offsite backup. The 85% cost saving is a side benefit; the real win is that no one can pull the plug on you except you.

If you're starting a self-hosting migration from a Garnix-style service this week, the path of least resistance is: pick RackNerd for the entry tier, Vultr for anything database or EU-bound, and ScalaHosting if you'd rather not run your own cPanel. Run the 3-signal check against every other SaaS you depend on. The 2026 shutdown wave isn't slowing down.

FAQ