Skip to main content

Self‑host Supabase: How I Moved Production to My Server (and Liked It)

Constantin Potapov
11 min

Real‑world experience migrating production Supabase to my own server: why I did it, what went wrong, what I saved, and a pragmatic checklist.

When Cloud Became Pricier Than Metal

The cloud bill confidently passed $200/month. The product grows, the DB swells, and so does the invoice. The thought hit: “why not host it myself?”

Back‑of‑napkin math:

  • Cloud: ~$200/mo for DB, storage, bandwidth, backups
  • VPS (8 GB RAM, 4 vCPU, 200 GB SSD): ~$40/mo + ~$2/mo for cold backup storage
  • Savings: ≈$158/mo or ~$1896/year

For teams in sanctioned geographies, availability risk is real. When production suffers from geopolitics rather than bugs — it’s time to take control.

Context of the Era

2024–2025: expensive clouds, volatile pricing, geopolitical risk. For small products, cloud TCO can be worse than a home/dedicated server. Self‑hosting isn’t romance — it’s a unit‑economics tool.

What “Own Supabase” Means

Supabase is a stack: PostgreSQL + PostgREST + GoTrue (auth) + Realtime + Storage + Kong (gateway) + Studio (admin), all in Docker behind an internal network.

Only the API gateway and Studio are public. Postgres never is. That’s the bedrock of security here.

Why Not Nhost (and When to Choose It)

If you’re a GraphQL purist on Hasura, Nhost feels native. I chose Supabase for simplicity and a mature ecosystem. REST is easy to debug; docs and Next.js integrations are pleasant.

Verdict: for most — Supabase; for GraphQL‑first teams — Nhost. Migrations later are close to rewriting the frontend.

How I Migrated (Weekend Edition)

No romance — a working checklist.

  1. Prepare VPS and backup disk. Wire access, monitoring, alerts.
  2. Deploy the official Supabase Docker stack. Ensure only the gateway and Studio are exposed.
  3. Create DB, enable needed extensions (pgvector, pg_net — per product needs).
  4. Move schema and data. Dry‑run first, then the real run overnight.
  5. Set up RLS policies, keys, and secrets. Double‑check.
  6. Move Storage and CDN. Set correct headers and permissions.
  7. Update frontend SDK keys, run regression, enable logging.
  8. Flip DNS with a prepared rollback.

Backups are not a place for heroism. Automate: daily DB snapshots, weekly cold storage. Practice restores — don’t “trust.”

Business Insights

  • Unit economics: $158/mo savings → ~$1896/year. Paid off in a weekend or two.
  • Control vs outsourced responsibility: you pay with time for predictability and independence.
  • Risks: power/uptime/redundancy — plan for them (UPS, off‑site backups, restore drills).
  • Scale: as you grow, don’t hesitate to go hybrid.

Gotchas I Tripped Over

  • VPS bandwidth limits. Check overage prices.
  • Storage permissions and RLS. One extra “allow” can be costly.
  • Postgres connection limits. Tune to real load, not vibes.
  • Logs. When it’s “your own,” you suddenly need real dashboards — not “later.”

Outcome

Savings are tangible, control is complete, speed is predictable. You trade vendor SLA for owning reliability — but sleeping better when the keys are in your pocket.

Self‑hosting Supabase is a pragmatic choice when you care about cost, predictability, and control. If your inputs are similar — plan the move. A single weekend can be enough.

See also