Self-Hosted vs Cloud Supabase for SaaS 2026

Q: What Boilerplates Assume About Your Supabase Setup?

Most boilerplates that target Supabase are written and tested against Supabase Cloud, not self-hosted. This has practical implications if you buy a boilerplate with plans to self-host. Boilerplates using Supabase typically rely on the JavaScript client library (@supabase/supabase-js), which connects via the REST API that Supabase Cloud exposes. The same client works with self-hosted Supabase, but you'll need to update the environment variables to point at your self-hosted instance. The critical

TL;DR

Start with Supabase Cloud. Switch to self-hosted only when you have a specific reason. The most common reasons: your Supabase cloud bill exceeds $200/month (self-hosting becomes cost-competitive), you need full data sovereignty (GDPR, HIPAA, enterprise contracts), or you need features unavailable on cloud (custom Postgres extensions). Most SaaS products should stay on cloud. Here's the complete cost and complexity comparison.

Key Takeaways

Supabase Cloud Pro: $25/month/project — handles everything, zero maintenance
Self-hosted: free software, but $30-80/month VPS + significant DevOps work
Break-even: self-hosting becomes cost-competitive around $150-200/month cloud spend
Data sovereignty: self-hosted wins for GDPR, HIPAA, SOC2 requirements
Performance: self-hosted can be faster (VPS closer to your users)
Maintenance cost: 2-4 hours/month minimum for updates, backups, monitoring

Supabase Cloud: What You Get

Supabase Cloud Free ($0):
  → 2 projects
  → 500MB database
  → 5GB bandwidth/month
  → 1GB file storage
  → Project PAUSED after 1 week inactivity
  → Community support only

Supabase Cloud Pro ($25/month/project):
  → No project pausing
  → 8GB database (then $0.125/GB)
  → 250GB bandwidth (then $0.09/GB)
  → 100GB storage (then $0.021/GB)
  → Daily backups (7-day retention)
  → Email support
  → 99.9% uptime SLA

Supabase Team ($599/month):
  → Unlimited projects (Pro tier each)
  → Point-in-time recovery
  → SOC2 compliant
  → Priority support
  → SSO for Supabase Dashboard

The Pro plan is a deal. $25/month for hosted Postgres + Auth + Storage + Edge Functions + Realtime is extremely competitive with building the equivalent infrastructure yourself.

Self-Hosted Supabase: What's Involved

Supabase is fully open source. You can run the entire stack:

# Clone and start self-hosted Supabase:
git clone https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env

# Configure .env:
POSTGRES_PASSWORD=your-super-secret-password
JWT_SECRET=your-super-secret-jwt-token-at-least-32-characters
ANON_KEY=<generate with JWT tool>
SERVICE_ROLE_KEY=<generate with JWT tool>
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=your-dashboard-password
SMTP_HOST=smtp.resend.com
SMTP_PORT=465
SMTP_USER=resend
SMTP_PASS=your-resend-api-key
SMTP_SENDER_NAME="Your App"
SMTP_ADMIN_EMAIL=admin@yourdomain.com

docker compose up -d

What runs in Docker Compose:

PostgreSQL (the database)
Supabase Studio (dashboard UI)
Kong (API gateway)
GoTrue (auth service)
PostgREST (REST API from Postgres)
Realtime (WebSocket server)
Storage API (S3-compatible file storage)
Edge Functions (Deno runtime)
Supavisor (connection pooler)

The Real Cost of Self-Hosting

Infrastructure Costs

Minimal setup (1 VPS):
  DigitalOcean Droplet 4vCPU/8GB RAM: $48/month
  Object storage (Backblaze B2): $6/month for 1TB
  Backup storage: $3/month
  Domain/SSL: ~$1/month
  Total: ~$58/month

Better setup (database + app separated):
  Database VPS (Hetzner CX31): €13/month (~$14)
  App VPS: €9/month (~$10)
  Object storage: $6/month
  Total: ~$30/month (EU)

Production setup (HA, backups, monitoring):
  Primary DB (4 core, 16GB RAM): $80/month
  Replica DB: $40/month
  Backups: $10/month
  Monitoring (Grafana cloud): $0 free tier
  Total: ~$130/month

Time Costs (Hidden)

This is what most self-hosting comparisons miss:

Initial setup:        4-8 hours
Monthly maintenance:  2-4 hours (updates, monitoring, occasional issues)
Incident response:    2-8 hours/incident
Schema migrations:    Same as cloud (no difference)
Backup verification:  1 hour/month

First year total:     48-96 hours of DevOps work
At $100/hour rate:   $4,800-9,600 in engineer time

Self-hosting "saves" $25-200/month
But costs $400-800/year in hidden DevOps time

Cost Comparison by Scale

Monthly users / data	Supabase Cloud	Self-hosted (infrastructure)	Self-hosted (total w/ time)
< 1,000 users / 1GB	$25/month	$30-60/month	$160-280/month
10,000 users / 10GB	$27/month	$30-60/month	$160-280/month
50,000 users / 50GB	$31/month	$60-130/month	$180-340/month
200,000 users / 200GB	$50-80/month	$80-200/month	$200-400/month
1M users / 1TB	$150-250/month	$200-400/month	$350-600/month

Takeaway: self-hosting becomes cost-competitive around 200K+ users or when your data exceeds 200GB. For most early-stage SaaS, Supabase Cloud is cheaper when you count engineer time.

When Self-Hosting IS the Right Call

Reason 1: Data Sovereignty

HIPAA (US healthcare):
  → Must not send patient data to third-party processors without BAA
  → Supabase Cloud: BAA available on Team plan ($599/month)
  → Self-hosted: you control all data, no BAA needed with Supabase

GDPR (EU strict interpretation):
  → Some legal teams require data to never leave your servers
  → Supabase Cloud EU region (Frankfurt): satisfies most GDPR requirements
  → BUT some enterprise customers contractually require "data stays on our VPS"
  → Self-hosted: satisfies these requirements

Defense / Government:
  → Air-gapped environments
  → Security clearance requirements
  → No cloud permitted — self-hosted is the only option

Reason 2: Enterprise Contracts

When enterprise customers ask:

"Where is our data stored?"
"Can we audit your data infrastructure?"
"Do you offer a dedicated instance?"

Self-hosting answers all three. You can host a dedicated Supabase instance for each enterprise customer on their preferred cloud or data center.

Reason 3: Custom Postgres Extensions

-- Some extensions not available on Supabase Cloud:
CREATE EXTENSION pg_cron;        -- Built-in Postgres cron (cloud: restricted)
CREATE EXTENSION pg_net;         -- HTTP calls from Postgres (cloud: restricted)
CREATE EXTENSION timescaledb;    -- Time-series data (not on Supabase Cloud)
CREATE EXTENSION citus;          -- Horizontal sharding (not on Supabase Cloud)
CREATE EXTENSION plv8;           -- JavaScript in Postgres (cloud: restricted)

If your data model requires TimescaleDB for time-series or Citus for horizontal sharding, self-hosting is the only option with Supabase.

Reason 4: Cost at Very Large Scale

At 1M active users with 1TB data:
  Supabase Cloud Pro: ~$150-250/month
  Self-hosted (3-server HA): ~$200-300/month infrastructure
  + 2-4 hours/month maintenance

At 10M users with 5TB data:
  Supabase Cloud: $500-1,000/month
  Self-hosted (robust infrastructure): $400-800/month
  + 4-8 hours/month maintenance

Above $500/month cloud → worth evaluating self-hosted

Setting Up Self-Hosted for Production

A production-ready self-hosted setup needs more than docker compose up:

# docker-compose.production.yml additions:
services:
  db:
    image: supabase/postgres:15.8.1.060
    volumes:
      - ./data/postgres:/var/lib/postgresql/data:Z
    restart: always
    # RAM allocation:
    deploy:
      resources:
        limits:
          memory: 8G

  # Add automatic backups:
  backup:
    image: ghcr.io/adrienpoupa/rclone-backup:latest
    environment:
      CRON: "0 3 * * *"    # 3am daily
      SOURCE: /data/postgres
      DESTINATION: b2:your-bucket/postgres-backups
    volumes:
      - ./data/postgres:/data/postgres:ro
    restart: always

Reverse proxy + SSL (Caddy):

# Caddyfile — automatic HTTPS:
supabase.yourdomain.com {
  reverse_proxy kong:8000
}

Monitoring:

# Add to docker-compose.yml:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana-oss:latest
    ports:
      - "3001:3000"
    volumes:
      - grafana-data:/var/lib/grafana

Migration Path: Cloud → Self-Hosted

If you start on cloud and need to migrate:

# Export from Supabase Cloud:
# 1. Database dump:
pg_dump "postgresql://postgres.[ref]:[password]@db.[ref].supabase.co:5432/postgres" \
  --no-acl --no-owner \
  -f supabase-backup.sql

# 2. Storage files:
supabase storage download --bucket-name your-bucket

# 3. Auth users (Supabase dashboard → Export):
# Dashboard → Authentication → Users → Export CSV

# Import to self-hosted:
psql "postgresql://postgres:your-password@localhost:5432/postgres" \
  < supabase-backup.sql

# Update environment variables in your app:
NEXT_PUBLIC_SUPABASE_URL="https://supabase.yourdomain.com"
NEXT_PUBLIC_SUPABASE_ANON_KEY="your-self-hosted-anon-key"
SUPABASE_SERVICE_ROLE_KEY="your-self-hosted-service-key"

Auth migration note: Supabase uses GoTrue internally. Your user passwords and OAuth tokens transfer cleanly in the database dump — users don't need to re-authenticate.

The Decision Framework

Start here: Are you pre-revenue or < $10K MRR?
  YES → Use Supabase Cloud Pro ($25/month)
        Don't spend engineering time on infrastructure
  NO  → Continue evaluating...

Do you have a data sovereignty requirement (HIPAA, specific contracts)?
  YES → Self-hosted (or Supabase Cloud + BAA on Team plan)
  NO  → Continue evaluating...

Is your monthly Supabase bill > $200/month?
  YES → Evaluate self-hosted cost (infrastructure + engineer time)
  NO  → Stay on cloud

Do you need a custom Postgres extension not available on Cloud?
  YES → Self-hosted
  NO  → Stay on cloud

Do you have dedicated DevOps capacity (or a willing backend engineer)?
  YES → Self-hosting is a reasonable option
  NO  → Cloud is safer

Default recommendation: Supabase Cloud Pro ($25/month)
Switch to self-hosted when: data sovereignty required, OR cloud bill > $200/month AND you have DevOps capacity

What Boilerplates Assume About Your Supabase Setup

Most boilerplates that target Supabase are written and tested against Supabase Cloud, not self-hosted. This has practical implications if you buy a boilerplate with plans to self-host.

Boilerplates using Supabase typically rely on the JavaScript client library (@supabase/supabase-js), which connects via the REST API that Supabase Cloud exposes. The same client works with self-hosted Supabase, but you'll need to update the environment variables to point at your self-hosted instance. The critical change: NEXT_PUBLIC_SUPABASE_URL changes from https://[ref].supabase.co to https://supabase.yourdomain.com. Everything else — auth, storage, real-time subscriptions — works identically.

The more subtle issue is boilerplates that use Supabase-specific features that behave differently in self-hosted configurations. Edge Functions on Supabase Cloud are served from Deno Deploy; in self-hosted, they run in a Deno container you manage. Storage on Supabase Cloud uses Supabase's S3-compatible backend; in self-hosted, you configure the storage backend yourself (S3 or local disk). If a boilerplate uses these features, verify the self-hosted equivalents work before committing to the configuration.

Auth.js / NextAuth boilerplates that use Supabase only as a database (not for Supabase Auth) are fully portable — the database connection string is the only thing that changes between cloud and self-hosted.

Practical Operations for Self-Hosted Supabase

Running self-hosted Supabase in production requires operational discipline that cloud users never need to develop. The most important practices:

Automated backups are non-negotiable. The Docker Compose setup has no backup configuration by default. You need to configure pg_dump or WAL-based backup to an offsite location — Backblaze B2, S3, or Wasabi. Test restores quarterly, not just backups. A backup you've never tested is a backup you can't trust.

Health monitoring prevents surprise outages. Self-hosted Supabase runs eight Docker containers; any one can fail without immediately obvious symptoms. Configure uptime monitoring (Better Uptime, Uptime Robot, or self-hosted Uptime Kuma) to alert when the REST API or Auth endpoints stop responding. Add PostgreSQL-specific monitoring to track connection counts, lock waits, and slow queries — problems that don't show up in a simple HTTP health check.

Update discipline is a security requirement. Supabase releases security patches for the Docker Compose images. Self-hosted users who ignore updates accumulate vulnerabilities. Subscribe to the Supabase GitHub releases feed and schedule monthly maintenance windows to update. The update process is: docker compose pull && docker compose up -d. Test in a staging environment before updating production.

Storage and connection management become your responsibility. Supabase Cloud handles PostgreSQL connection pooling via Supavisor automatically. In self-hosted, you configure the pool size yourself based on your VPS's RAM. Too few connections causes timeout errors under load; too many connections exhausts the database's per-connection memory. Start with max_connections = 100 in PostgreSQL config and monitor actual connection usage before tuning.

The Hybrid Architecture: Cloud Auth + Self-Hosted Database

One option many teams miss is the hybrid approach: use Supabase Cloud for authentication and storage while running your own PostgreSQL instance for the primary application database. This splits the infrastructure by what you value most about each component.

Supabase Auth is one of the strongest reasons to use Supabase — it handles email/password, OAuth (Google, GitHub, Apple), magic links, phone auth, and multi-factor authentication with a battle-tested implementation. Replicating this yourself is significant work, and rolling your own auth is a well-documented source of security vulnerabilities. Paying $25/month for Supabase Auth while running a $14/month Hetzner PostgreSQL instance is a reasonable infrastructure architecture that captures Supabase's best feature while controlling database costs.

The technical implementation is straightforward: use the Supabase Auth client (@supabase/supabase-js) for authentication flows, then use a separate Postgres connection string (Neon, Railway, or self-hosted) for your application data. The supabase.auth.getUser() call still works; you just don't query Supabase's Postgres for your application data.

This hybrid approach is particularly useful for teams that tried Supabase Cloud but found the database pricing unpredictable at scale, or who need specific Postgres extensions unavailable on Supabase Cloud, but don't want to replicate Supabase's auth implementation themselves. You keep the expensive-to-replicate parts on cloud and self-manage the commodity parts.

Realistic Timeline for Self-Hosting

Teams that decide to self-host Supabase frequently underestimate the time investment required. A realistic timeline for a production-ready self-hosted setup:

Initial setup (8-16 hours): provisioning a VPS, installing Docker, configuring the Supabase Docker Compose stack, setting up SSL via Caddy or Nginx, configuring DNS, and running the first test deployment. First-time infrastructure engineers routinely spend 16+ hours on this phase.

Hardening (4-8 hours): implementing automated backups, configuring monitoring and alerting, setting up a staging environment that mirrors production, and establishing the update procedure. These are not optional for production — they're the difference between a self-hosted setup and a self-hosted disaster waiting to happen.

Ongoing maintenance (2-4 hours/month): applying Supabase Docker image updates, reviewing backup integrity, responding to monitoring alerts, and debugging occasional infrastructure issues. This time cost is real and competes directly with product development.

The total first-year time investment is 80-130 hours. For a developer billing at $100/hour, that's $8,000-13,000 in opportunity cost — significantly more than five years of Supabase Cloud Pro at $300/year. Self-hosting is only economically rational when your cloud bill exceeds $200-300/month, you have specific compliance requirements, or you have dedicated infrastructure engineering capacity. For most SaaS products in their first two years, the math consistently favors cloud over self-hosting when you count all costs honestly.

The right choice between these options depends on your specific requirements, team expertise, and production constraints. Test each option with a realistic subset of your use case before committing — what works for one team's workflow may not fit another's.

Compare SaaS boilerplates by infrastructure requirements at StarterPick.

See how Supabase compares to Neon as a database choice: Best SaaS boilerplates with Neon and PlanetScale 2026.

Find free and open-source boilerplates that support self-hosted backends: Best free open-source SaaS boilerplates 2026.

Read about the infrastructure decisions in the ideal SaaS stack: Ideal tech stack for SaaS in 2026.

The SaaS Boilerplate Matrix (Free PDF)