Is self-hosted Supabase the same as the local CLI stack?

No. The local CLI environment is intended for development; the official self-hosting path has separate production responsibilities.

What managed features are absent?

Official docs list gaps including managed branching, managed backups and PITR, advanced metrics, ETL, and the platform management API.

Infrastructure guide

Self-Hosted Supabase with Docker: What You Gain and What You Inherit

Q: How much RAM is required?

Official guidance lists 4 GB minimum and recommends 8 GB or more for small-to-medium production workloads.

Q: What must be backed up?

Protect Postgres, Storage objects, configuration, secrets, and the exact deployment material needed to reproduce the stack.

Use the official release-pinned Supabase Docker stack while planning for the cloud feature gaps, capacity, backups, security, and upgrades you inherit.

Published and reviewed by OpenAlt · September 25, 2026

Detailed image of illuminated server racks showcasing modern technology infrastructure. — Photo by panumas nikhomkhai on Pexels

TL;DR

Self-hosted Supabase gives you control over data location, networking, versions, and infrastructure boundaries. The official Docker deployment is the fastest recommended self-hosting path, but it is a single-project installation—not a private copy of every Supabase Cloud capability.

You inherit upgrades, backups, monitoring, security, capacity planning, disaster recovery, and support responsibility. Before committing, budget at least 4 GB RAM, 2 CPU cores, and 40 GB SSD. The recommended starting point is 8 GB RAM, 4 or more cores, and 80 GB or more storage.

Use the official, release-pinned Docker bundle. Do not build production infrastructure from an unpinned community one-file Compose template.

Cloud vs. self-hosted

The short answer: self-hosting reduces platform dependency, but replaces managed convenience with operational ownership.

Area	Supabase Cloud	Self-hosted with Docker
Pricing	Hosted service pricing based on plan and usage	No Supabase software license fee; you pay infrastructure, storage, bandwidth, monitoring, and operations
Projects	Multiple projects and managed environments	One self-hosted project per deployment
Updates	Managed platform upgrades	You schedule, test, and execute updates
Backups	Managed backups and point-in-time recovery options	You design, verify, and retain backups
Branching	Managed database branching	Not provided as a managed feature
Metrics	Advanced managed metrics and operational tooling	Logs and your own monitoring; advanced metrics are not included
Storage	Hosted object storage and platform-managed operations	Storage files default to the server filesystem
Data control	Provider-managed infrastructure	You control location, network, access, and retention
Platform API	Available for platform management	Platform management API is not included

If control is your priority, review OpenAlt’s Supabase profile, compare self-hosting platforms, and read the self-hosting beginner guide before choosing a host.

Preflight capacity

Start with the official minimum: 4 GB RAM, 2 CPU cores, and 40 GB SSD. For a production-like workload, use at least 8 GB RAM, 4 or more cores, and 80 GB or more storage.

Capacity planning must include more than database size. Account for Postgres growth, Storage objects, WAL and temporary files, Docker images, logs, backups, upgrades, and headroom for traffic spikes. A disk that barely meets the initial requirement can become an outage when backups or logs consume the remaining space.

Also decide where the server lives, how it receives updates, which ports are exposed, how TLS is terminated, and how administrators reach Studio. If the host is disposable, your backup and restore process must be tested before production data arrives.

Obtain the official Docker bundle

The official Docker path is distinct from the local Supabase CLI stack. Local development can use a CLI-managed environment; production self-hosting should use the documented Docker deployment.

Obtain the current release-pinned files from the official Docker self-hosting guide. Keep the bundle together in a controlled directory and record the release version. Pinned files make the deployed components reproducible and give you a known upgrade target.

Do not replace the official bundle with an unpinned community Compose file. A convenient template may omit services, security settings, migrations, or version constraints that matter during upgrades and recovery.

Generate secrets and configure URLs

Copy the environment template supplied with the official bundle, then create unique credentials for the database, JWT signing, dashboard access, and any other enabled service.

cp .env.example .env
openssl rand -hex 32
openssl rand -base64 48

Use the generated values where the bundle requires secrets. Do not reuse development credentials, commit .env to source control, or send secrets through chat. Store an encrypted administrative copy outside the server; losing the only copy can make recovery difficult.

Set the public site and API origins to the real HTTPS addresses users will access. Check redirect URLs, cookie behavior, CORS, email links, and OAuth callback URLs. If a reverse proxy terminates TLS, ensure it forwards the correct host and protocol information.

Detailed view of a server rack with a focus on technology and data storage. — Photo by panumas nikhomkhai on Pexels

An IT professional operates a computer in a server room, managing network systems and connected devices. — Photo by panumas nikhomkhai on Pexels

Start and verify the stack

After reviewing the environment file and firewall rules, start the official release-pinned deployment:

sh run.sh start

Treat a successful start as the beginning of verification, not proof that the installation is production-ready. Confirm that the containers remain healthy after restart, the API answers through the intended HTTPS endpoint, authentication can create and refresh a session, database queries work, and Storage can upload, retrieve, and delete a test object.

Inspect logs for repeated errors, authentication failures, migration problems, unhealthy dependencies, and disk warnings. Test the deployment from outside the server’s private network. A dashboard that works only from localhost is not an externally usable production system.

Secure Studio and the API

Studio and administrative APIs should not be treated as ordinary public web pages. Place them behind HTTPS, restrict administrative access by network or identity provider where practical, and use strong, unique credentials.

Expose only the ports required by your architecture. Keep Postgres private unless a specific trusted connection requires it. Apply operating-system security updates, protect SSH, use firewall rules, and monitor authentication logs. Rotate credentials when administrators change or when a secret may have been exposed.

Use least privilege for application keys. Never place a service-role key in browser code, mobile binaries, public repositories, or client-side environment variables. Review Row Level Security policies as part of deployment validation rather than assuming the default schema is safe for every application.

Back up Postgres, Storage, and configuration

A database dump alone is not a complete Supabase backup. Protect three categories:

Postgres data, roles, extensions, schemas, migrations, and required database configuration.
Storage objects, because files default to the server filesystem.
Deployment configuration, including the pinned bundle version, .env secrets, proxy configuration, certificates, firewall rules, and operational notes.

Keep backups outside the production host, encrypt them, limit access, and define retention. Monitor backup jobs and alert on failure. A backup that has never been restored is an assumption, not a recovery plan.

Update and restore deliberately

Follow the official update guide. Read release notes, preserve the current bundle and configuration, take fresh backups, and test the update when possible. Do not treat main as a release branch or pull arbitrary latest images into production.

Your restore drill should answer practical questions: Can you provision a clean host? Can you recreate the exact release? Can you restore Postgres roles and data? Can you restore Storage objects and configuration? Can DNS, TLS, and application secrets be reconnected without improvisation?

Document the time required and the data-loss point you can tolerate. If the drill fails, production is not ready.

When not to self-host

Do not self-host when your team cannot own reliable backups, security patching, monitoring, upgrades, and incident response. It is also a poor fit if you need managed branching, advanced metrics, managed backups or point-in-time recovery, analytics or vector buckets, ETL, or the platform management API.

Self-host when data control, network isolation, regulatory boundaries, predictable infrastructure ownership, or custom operations clearly outweigh the cost. Otherwise, Supabase Cloud is usually the better production default. The firm conclusion is simple: choose self-hosting for an operational reason, not merely because Docker makes installation look easy.

FAQ

Is self-hosted Supabase the same as the local CLI?

No. The local CLI stack is designed for local development and workflows. The official Docker deployment is the recommended path for running a self-hosted environment.

What cloud features are absent?

A self-hosted deployment is a single project and does not include managed branching, advanced metrics beyond logs, managed backups or point-in-time recovery, analytics and vector buckets, ETL, or the platform management API.

How much RAM is required?

The official minimum is 4 GB RAM, with 2 CPU cores and 40 GB SSD. The recommended baseline is 8 GB RAM, 4 or more cores, and 80 GB or more storage.

What must be backed up?

Back up Postgres, Storage files, and deployment configuration. Include secrets, pinned versions, proxy settings, certificates, and recovery documentation.

Is community support enough for production?

Community help can be useful, but it does not replace ownership of availability, security, upgrades, backups, and incident response. Production teams should have an internal runbook and a tested recovery process.