Supabase Self-Hosted
IntermediateWeb AppSelf-host the Supabase platform: PostgreSQL, Auth, Storage, Realtime, and Studio on your own server with Docker.
Published 27 September 2026
About Supabase Self-Hosted
Supabase's self-hosted distribution packages the open-source services behind Supabase Cloud as one Docker Compose bundle. PostgreSQL is the core, with Supabase Auth for sign-in, PostgREST for an automatic REST API, Realtime for change streams over WebSockets, Storage with image transformations for files, Edge Runtime for functions, and Studio as the dashboard. An API gateway fronts them all on one port, and Supavisor pools database connections.
The same client libraries work against it: supabase-js and the other SDKs only need your instance's URL and keys, and Row Level Security policies behave as they do on Cloud. What changes is the limits. There are no monthly-active-user caps, storage tiers, or project pauses, only the size of your server, and Studio manages this one instance rather than an organization of projects.
The bundle runs around a dozen containers, so it wants a mid-size server: 4 GB of memory and 2 cores at minimum, 8 GB and 4 cores recommended. Supabase ships self-hosted updates about monthly through an update script, and applying them, backing up the database and storage volume, and monitoring the services are your job.
Exposure follows the family's two paths: a reverse proxy in front of the gateway, or a self-hosted PaaS that bundles one, where a dedicated Supabase template can provision the whole bundle in one step.
Key Features
- ✓The Supabase platform in one bundle: PostgreSQL, Auth, Storage, Realtime, Edge Functions, and Studio
- ✓PostgREST generates a REST API over your Postgres schema
- ✓Row Level Security and the same client libraries as Supabase Cloud
- ✓An API gateway fronting every service on one port, with Supavisor connection pooling
- ✓No MAU, storage, or project-pause limits beyond your own hardware
- ✓Official Docker Compose setup with a monthly update script
When to Use Supabase Self-Hosted
- →Products with EU or sector-specific data-residency requirements for user and app data
- →Teams whose monthly active users or storage make Supabase Cloud's usage billing expensive
- →Companies that want the Supabase developer experience on infrastructure they own
- →Internal platforms that need a backend-as-a-service inside a private network
- →Local or staging environments that mirror a Supabase Cloud project
Pros
- Same APIs and client libraries as Supabase Cloud, so moving between them needs no code changes
- Every database row, auth record, and file stays on your own server
- No usage caps; scaling means resizing the server you already control
- Open-source services you can audit and modify
Cons
- You own platform upgrades, backups, and monitoring that Supabase Cloud would handle
- The official floor is 4 GB of RAM and 2 cores, with 8 GB and 4 cores recommended
- Studio manages one instance, without Cloud's branching, organization, or managed-backup features
- Default secrets and keys must be replaced before the instance goes public
Hosting Options for Supabase Self-Hosted
A flat-rate root VPS where 8 GB instances, Supabase's recommended size, cost around €8-10/mo, a fraction of the big clouds. The cheapest way to run the full bundle with headroom; database backups, storage-volume backups, and the monthly updates are yours to schedule.
A root Droplet with snapshots and a cloud firewall in the panel: about $24/mo for 4 GB, Supabase's minimum, or $48/mo for the recommended 8 GB. Spaces can serve as the S3-compatible backend for Supabase Storage, which moves uploaded files off the Droplet's disk.
The budget VPS in the list: the KVM plan with 2 vCPUs and 8 GB, Supabase's recommended memory, costs about $9/mo on a two-year term, with higher renewal rates. It suits side projects and staging copies; fewer regions than the larger providers, and backups are yours.
An EC2 instance at roughly $50-70/mo for 8 GB, inside the VPC where the rest of the product runs. S3 can back Supabase Storage through its S3 protocol support, and an Application Load Balancer with AWS Certificate Manager can terminate TLS in front of the API gateway instead of the reverse proxy.
A Compute Engine instance at roughly $50-70/mo for 8 GB, inside an existing Google Cloud project. Cloud Load Balancing with Google-managed certificates can terminate TLS in front of the API gateway instead of the reverse proxy, and persistent-disk snapshots give the database volume a simple backup path.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for Supabase Self-Hosted
Routes to Supabase's API gateway from Docker labels and renews Let's Encrypt certificates on its own. Send the whole domain to the gateway on port 8000 rather than to individual services, and set SITE_URL, API_EXTERNAL_URL, and SUPABASE_PUBLIC_URL to the public HTTPS address.
Automatic HTTPS from a few lines of config: one site block proxying to the API gateway covers the whole bundle. Caddy passes WebSocket upgrades by default, which Realtime subscriptions need, so change streams work without extra directives.
Self-Hosted PaaS Options for Supabase Self-Hosted
Free and self-hosted, with a dedicated Supabase template that provisions the whole Compose bundle in one step behind Coolify's bundled proxy. It generates the secrets for you, which covers the most common self-hosting mistake; check how the template tracks Supabase's monthly updates before relying on it.
Supabase Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
Makes self-hosted Supabase reachable over HTTPS through an outbound-only connection, with no inbound ports or static IP, for an instance inside a private network. Point the tunnel at the API gateway, and keep Studio behind Cloudflare Access if it has to be reachable remotely.
Frequently Asked Questions about Supabase Self-Hosted
Why self-host Supabase instead of using Supabase Cloud?
Usage limits and data location. Supabase Cloud's free plan covers 50,000 monthly active users and a 500 MB database but pauses projects after a week of inactivity; Pro is $25/mo with 100,000 users, 8 GB of disk, and 100 GB of file storage, then bills usage beyond that. Self-hosting has no caps and keeps every row and file on your server. In exchange you run backups, monthly updates, and monitoring yourself, and lose Cloud extras such as branching and point-in-time recovery. Small projects are usually cheaper on Cloud.
What does the server need to run?
Supabase's self-hosting guide sets the minimum at 4 GB of memory, 2 cores, and 40 GB of SSD, and recommends 8 GB, 4 cores, and 80 GB or more for real workloads. The weight comes from running around a dozen services together: PostgreSQL, Auth, PostgREST, Realtime, Storage, Edge Runtime, Studio, the API gateway, connection pooling, and logging. Removing services you don't use trims the requirement, and the logging and analytics services are the first candidates.
What needs backing up, and how do upgrades work?
PostgreSQL holds your data and auth users, so schedule pg_dump or volume snapshots and test a restore; the self-hosting guide leaves backups to you. Storage files live on a local volume unless you point Storage at an S3-compatible bucket, and that volume needs its own backup. Supabase publishes self-hosted updates about monthly: the update script pulls the new configuration and merges your changes, and you can also bump individual service images. Back up before each update.
Can I move an existing Supabase Cloud project into this stack?
Yes, with some care. A full pg_dump of the Cloud database carries your schema, data, Row Level Security policies, and the auth schema with its users into the self-hosted PostgreSQL. Storage files move separately, through the S3-compatible API or a script that downloads and re-uploads them. Edge Functions redeploy from your repository, and project settings such as auth providers and SMTP are re-entered as environment variables. Test the move on a copy before switching traffic.
What must change before a self-hosted Supabase goes public?
The defaults in the example environment file. Generate new JWT signing keys with the provided scripts, and replace the publishable and secret API keys, the PostgreSQL password, and the Studio dashboard username and password. The example values are public, so an instance started with them lets anyone mint valid tokens or open the dashboard. Then set the public URL variables to your HTTPS domain, since Auth builds its email and redirect links from them.
Stacks Related to Supabase Self-Hosted
Strapi Self-Hosted
InfrastructureSelf-hosted Strapi: an open-source headless CMS with PostgreSQL, on a server you control.
Grafana Self-Hosted
InfrastructureSelf-hosted Grafana and Prometheus: metrics dashboards and alerting on a server you run.
Airflow Self-Hosted
InfrastructureSelf-hosted Apache Airflow: the standard data-pipeline scheduler on your infrastructure.
n8n Self-Hosted
InfrastructureSelf-hosted n8n on your own server, with full control over the database, the host, and how it's exposed to the internet.
Scores
Popularity4/5
Supabase is among the best-known backend platforms of the current generation, and self-hosting it is an actively documented path.
Learning Curve4/5
The Compose bundle starts everything in one command, but operating it (upgrades, backups, sizing) is real platform work beyond a single-app stack.
Flexibility5/5
Postgres, auth, storage, realtime, edge functions, and the Studio dashboard: the complete backend-as-a-service surface, with SQL as the contract.
Performance4/5
PostgreSQL and the service bundle perform well with adequate RAM; realtime fan-out and storage are the components that stress small instances.
Portability4/5
Standard PostgreSQL underneath and Supabase Cloud as the reference deployment: dumps move like any Postgres, and the cloud product is a supported destination.
Tools in the Supabase Self-Hosted Stack
Supabase Self-Hosted Pricing
The self-hosted Supabase platform is open source and free, so the server is the whole bill, sized for a multi-service bundle: roughly $9-25/mo on a VPS with 8 GB, or $50-70/mo on AWS or Google Cloud. Supabase Cloud's free plan covers small projects and Pro is $25/mo plus usage, so self-hosting pays off when users, storage, or data-residency rules outgrow what Cloud costs.
4 GB of RAM and 2 cores is Supabase's minimum; 8 GB and 4 cores is the recommended starting point for real workloads.
PostgreSQL, Auth, Storage, Realtime, Edge Functions, and Studio with no MAU or storage caps.
Traefik, Caddy, NGINX, Coolify, and Dokploy all self-host free, with free Let's Encrypt certificates.
Supabase Self-Hosted System Requirements
source- CPU
- 2 cores minimum, 4 or more recommended
- RAM
- 4 GB minimum, 8 GB or more recommended
- Disk
- 40 GB SSD minimum, 80 GB or more recommended
- OS
- Linux server or VPS with Docker and Docker Compose
The official minimums run all Supabase components for development and small-to-medium production; removing unused services trims the requirements, and enabling Logs & Analytics raises them.