Which Supabase fits your situation: hosted plans or your own infrastructure
If a Supabase renewal, plan change, residency rule or lock-in concern is pushing you to reconsider, the answer depends on who should run the platform. Choose Supabase Cloud if you want the vendor to operate backups, point-in-time recovery, branching, service levels and SOC 2 reporting without running infrastructure yourself. Choose self-hosted Supabase if the stack must stay in your own environment and you can accept community support and backups you run yourself. Both options run the same Apache-2.0 stack from the supabase/supabase repository, so your schema, Postgres data model and application code carry across.
Four factors should drive the decision. First, data location: each Supabase Cloud project sits in one main region chosen from 17 AWS regions, while self-hosting lets you pick the data center or sovereign cloud, so test your residency rules against both. Second, recovery: self-hosted Supabase has no managed backups or point-in-time recovery, so you need a restore procedure you have tested before go-live. Third, operating capacity: each Docker configuration release, such as 0.8.3 from October 16, 2026, lists image updates and configuration file changes that your team must apply. Fourth, project count: self-hosted Supabase runs as a single project in Studio, so several applications mean several deployments. The Supabase self-hosting guide sets out these differences in full.
Before you decide, ask Supabase in writing which SLA, SOC 2 report access and backup retention apply to your plan, and confirm current plan contents on the Supabase pricing page, since plan details change. On the self-hosted side, confirm with your security team which safeguards, logging and backup duties you will own, and run a restore drill that proves a recovered project works end to end. If the answers point to managed operations, stay on a hosted plan and review the decision at your next renewal. If they point to your own environment, plan for an operator who owns upgrades, recovery and on-call coverage from the first day.
Which option fits which scenario
This table matches six common situations to the better fit between Supabase Cloud and self-hosted Supabase. Read each row against your own conditions, since the better fit holds only while the stated condition is true. Most of the difference comes down to who operates the platform, backups and recovery.
| Scenario | Better fit | Why |
|---|---|---|
| A small team shipping a prototype | Supabase Cloud | The hosted free tier avoids running Docker, secrets and upgrades while the product is still changing. This holds while the data carries no regulatory obligation that requires your own infrastructure. |
| A regulated workload that must keep data in the client's own data center | Self-hosted Supabase | Each Supabase Cloud project runs in one main AWS region, so a fixed data center is not an option. This holds when you can staff the operations, logging, backups and support that the hosted service would otherwise carry. |
| A team needing managed backups and PITR without DBA staff | Supabase Cloud | Self-hosted Supabase does not include managed backups or point-in-time recovery. This holds unless you can staff database operations or fund a managed Postgres service to provide equivalent recovery. |
| A team needing branching for preview environments | Supabase Cloud | Branching is listed as unavailable in self-hosted Supabase, so preview databases would need to be rebuilt by hand. This holds while preview environments are central to your release process. |
| Multiple unrelated projects under one team | Supabase Cloud or a different platform | Self-hosted Studio runs a single project, with no multiple organizations or projects. Confirm the current project model before choosing, and consider running separate stacks or Appwrite if isolated projects are required. |
| A team with platform engineers and a tested backup routine | Self-hosted Supabase | Your staff can own upgrades, Docker Compose changes and backup restores that the hosted service otherwise handles. This holds when restores have been rehearsed and monitoring covers every service in the stack. |
Where your data sits and who holds the keys
Moving from Supabase Cloud to self-hosted Supabase changes who picks the data location, who runs the hosting, and who owns the security and compliance controls. Each card below covers one of those decisions and what to confirm before you commit.
Data location and region
Each Supabase Cloud project is hosted in one main region chosen from 17 AWS regions, so the region is a decision you make at project creation. Self-hosted Supabase runs wherever you deploy the Compose stack, whether that is an EU data center, a sovereign cloud or your own racks. Check which regions your data, backups and logs must stay in, and confirm where any object storage and log sinks sit, since those are separate from the database host.
Docker Compose as the supported path
Supabase's self-hosting docs recommend Docker Compose, and that is the configuration the Supabase team publishes and versions. Kubernetes deployments run through a community Helm chart or the Supabase Operator, which Supabase does not maintain. If your platform team runs Kubernetes, decide early whether you accept community ownership of the chart or operator, and who patches it when a Docker configuration release changes services.
Secrets and Studio access
Self-hosted Supabase must never start with the placeholder values in .env.example. Supabase provides scripts that generate the secrets and the JWT key pair, and you are responsible for storing them in your own secret store and rotating them. Studio is protected with HTTP basic auth set through DASHBOARD_PASSWORD, so confirm who can reach the admin interface, whether it sits behind your identity provider or VPN, and how that credential is rotated.
Compliance evidence moves to you
On paid Cloud plans, SOC 2 reports and HIPAA terms come from the hosted vendor, and the vendor operates many of the controls behind them. Self-hosting removes that vendor-held attestation: you own the access reviews, logging, change records and backup tests that an assessor will ask for. DeployOpen prepares systems, controls and evidence for assessment, but does not issue audit reports, attestations or certifications, and no certification transfers to a self-hosted deployment by default.
Sovereignty and air-gapped operation
A self-hosted stack can run in a sovereign cloud, an isolated network or an air-gapped environment, which Cloud projects cannot do. The trade-off is that you must source every image, pull and verify each versioned release yourself, and handle updates through an approved internal registry. Ask whether your security team accepts the Docker images through a mirror, how they are scanned, and how a configuration release that requires a database backup before updating is staged.
What you run when you self-host Supabase
Self-hosting Supabase means operating a set of Docker Compose services that the hosted platform runs for you. The Studio dashboard, an Envoy API gateway (Kong remains an optional alternative), Auth (GoTrue), PostgREST, Realtime, Storage, imgproxy for image transforms, postgres-meta, Postgres, the Edge Runtime on Deno, and the Supavisor connection pooler each run as their own container. Logflare and Vector are optional analytics and log components. Before you size a host, list which of these your application actually calls, because the Docker Compose guide says unused services such as Realtime, Storage, imgproxy or Edge Runtime can be removed from docker-compose.yml. Every service you keep is one more container to patch, monitor and back up.
Supabase's Docker guide lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB. Treat the minimum as a lab configuration. Storage growth, WAL retention and the number of concurrent Realtime connections will push the disk and memory figures up, and your own load test is the only reliable way to confirm capacity. Two version facts matter for planning. Postgres 17 has been the default database since 0.6.0 on June 17, 2026, so a fresh install gets that major version. Envoy replaced Kong as the default gateway in 0.8.0 on August 11, 2026, and the Kong override file is slated for removal, so any custom routing written against Kong needs review.
Each Docker configuration release bundles specific upstream versions. Release 0.8.3 pins Auth v2.197.0, PostgREST v14.18 and Realtime v2.143.3, and you pull and recreate those images yourself. Read the changelog before every update because it lists configuration file changes you must apply by hand, and it flagged one-way Storage database migrations that require a database backup first. Also replace the placeholder secrets in .env.example before the first start, since the guide warns against running with them. Confirm the exact pinned versions against the changelog for the release you deploy, because later releases will change them.
How to keep self-hosted Supabase current and recoverable
This sequence keeps a self-hosted Supabase stack on supported Docker configuration releases and recoverable from a tested backup. Each cycle ends with a documented backup, a verified update and a restore test that the operator owns.
Track Docker configuration releases
The platform owner watches the self-hosted Supabase Docker configuration for new versioned releases, such as 0.8.3, which was published on October 16, 2026. Each release bundles specific upstream service versions, so the team logs which release is running and which one is current. The step is done when the running version is recorded in the team's runbook alongside the date of the last check.
Read the changelog for required changes
Before touching the stack, the operator reads the changelog entry for the target release. It lists per-service image updates and changes to configuration files, such as docker-compose.yml and .env, that the operator must apply by hand. The 0.8.3 entry also flags security fixes for Storage and Realtime and one-way Storage database migrations, which is why the update should not be deferred. The step is done when every config change is written into a change ticket.
Take and verify a database backup
Before updating, the operator takes a full database backup with a tool such as pg_dump and stores it outside the host. The 0.8.3 changelog says the one-way Storage database migrations require a backup before updating, so this step is mandatory for that release. The step is done when the backup file is written to separate storage, its size and checksum are recorded, and a restore has been confirmed to start on a scratch host. Self-hosted Supabase has no managed backups or PITR, so this file is the only recovery point.
Apply config changes and recreate containers
The operator merges the configuration changes from the changelog into the environment file and Compose file, keeping the generated secrets and JWT keys already in use. They then pull the new images and recreate the containers, for example with docker compose pull followed by docker compose up -d. The step is done when every service reports a running state and the Compose logs show no startup errors for Postgres, Auth, PostgREST, Realtime, Storage or the gateway.
Verify Auth, Realtime and Storage
The operator runs a short scripted check against each service that changed. They sign in a test user and confirm a token is issued, check that a PostgREST query returns expected rows, open a Realtime subscription and confirm it receives a change, and upload and download a test file through Storage. The step is done when all four checks pass and the results are saved with the release record. If any check fails, the team rolls back to the backup and the previous images.
Test restores on a schedule
Recoverability is only proven by restoring. The operator restores the latest backup into a separate environment, confirms the schema, row counts and Storage objects match the source, and times the process against the recovery goal the business has agreed. The step is done when the restore log and the verification results are filed, and any gap in the backup process is assigned an owner. Ask the vendor or your partner to confirm the restore approach you choose for Storage objects.
What each option costs, by component
Supabase Cloud bills you through recurring plan fees and usage on each project. The Supabase pricing page sets out the Free, Pro, Team and Enterprise plans and what each includes, and those terms change over time, so confirm them on the page before you budget.
- Plan fees: the plan is billed per organization on a recurring basis, and each tier adds features such as backups, branching, SLAs and compliance documents.
- Per-project compute: every project runs its own compute instance, so each additional project adds recurring compute cost, and larger instances cost more while they run.
- Backups and PITR: managed backups and point-in-time recovery are part of the hosted offering, but retention and recovery terms depend on the plan, so confirm them in writing.
- Usage charges: database disk, bandwidth and monthly active users can add variable charges that grow with traffic and data.
- Feature gating: branching, SLAs and the SOC 2 report are tied to specific plans, so check which tier includes each feature you need.
Ask for the plan that covers your required backup retention, SLA and compliance documents, along with the usage assumptions behind any projection.
Self-hosted Supabase has no vendor invoice, but you pay for the infrastructure, the backup tooling and the people who run them. The self-hosting guide documents the Docker Compose path, and the operating work it implies falls to your team or your implementation partner.
- Servers: the Docker guide lists a minimum of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB. Production sizing depends on data volume and concurrency, so load test before you commit to hardware or instances.
- Backup tooling and storage: managed backups and point-in-time recovery are not available, so you pay for backup storage, pg_dump or WAL archiving, offsite copies and recurring restore tests.
- Upgrade effort: each configuration release, such as 0.8.3 on October 16, 2026, requires image updates and configuration changes you apply yourself. Some Storage migrations are one-way, so a database backup must come first.
- Monitoring and on-call: community support is available through GitHub, Discord and Reddit, but it carries no response commitment, so uptime monitoring, log retention and out-of-hours response are your costs.
- Initial setup time: replacing placeholder secrets from .env.example, generating the JWT key pair, protecting Studio with DASHBOARD_PASSWORD and removing unused services are one-time tasks with staff hours attached.
Estimate the hours for each item from your own environment, and confirm the current release and hardware guidance on the self-hosting pages before you finalize the total.
The totals depend on drivers that move each option in different directions. Separate one-time work from recurring work for both options before you compare them, because a low first-year figure can hide a higher run cost.
- Drivers on the cloud side: project count, compute size per project, database size, egress, monthly active users and plan tier.
- Drivers on the self-hosted side: the number of environments that need their own servers, data growth, high availability needs, backup retention, compliance evidence collection and release frequency.
- One-time versus recurring: setup, migration, hardening and first restore tests are one-time. Hosting, backup storage, upgrades, monitoring and support recur every month.
- Features to rebuild: branching, managed backups, PITR, multi-project management, the Management API and ETL each need an owner and a process if you run the stack yourself.
- Quote requests: ask for a line-item scope, the staff hours behind each item, the assumptions on availability and incident handling, and a list of what stays inside your environment.
Use the sibling page on Supabase cloud cost versus self-hosted Supabase for the detailed component model, and request quotes against the same assumptions.
Questions buyers ask before switching
How much does self-hosting Supabase cost compared with Supabase Cloud?
No single figure applies, because the answer depends on what you run and who runs it. Supabase Cloud bills per project for compute, disk, monthly active users, egress and add-ons such as point-in-time recovery, and the Team plan carries its own fee. Self-hosting moves those costs onto your side: servers or cloud instances, storage, backup tooling, monitoring, upgrades and the staff time to operate them. The Docker self-hosting guide lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended, so infrastructure is a small line item while people time is usually the large one. Ask any quote to separate one-time setup from recurring operations, and to state who pays for on-call coverage and for rebuilding managed features.
How long does a move to self-hosted Supabase take and what drives it?
The timeline depends mainly on how much of the platform your project uses. A project with a single Postgres schema, a few auth providers and little Storage can move faster than one with Edge Functions, many buckets, custom domains and tightly coupled client code. The main work items are standing up the Docker Compose stack, restoring the database, copying Storage objects, reconfiguring JWT keys, auth providers, Edge Functions and domains, and then testing each client path. Your team's familiarity with Docker, Postgres and reverse proxies, plus the number of environments that need to match production, also shape the schedule. Agree on a timeline in writing as part of a fixed scope rather than relying on an estimate from a sales conversation.
How much in-house work does running self-hosted Supabase require?
Expect ongoing work in four areas: applying Docker configuration releases, watching security fixes, testing upgrades and keeping backups restorable. The self-hosted Docker configuration ships as versioned releases, such as 0.8.3 on October 16, 2026, and its changelog lists per-service image updates and configuration changes that your operators must apply. That release flagged security fixes for Storage and Realtime, and one-way Storage database migrations that require a database backup before updating. Configuration is mostly done through environment variables, and the guide warns never to start with the placeholder secrets in .env.example. Plan for a named owner, a staging environment for upgrades and someone who can answer for backups and recovery.
Can our own engineers run self-hosted Supabase without an implementation partner?
Yes, many teams do, provided they have Linux, Docker, Postgres and networking skills and the time to build backups, monitoring and an upgrade routine. Supabase's self-hosting docs describe Docker Compose as the recommended method, so the core deployment is documented. The gaps tend to appear in production hardening: secrets generation, Studio protection, TLS, backup restore testing, logging and a rehearsed upgrade path. A partner can take that work under a fixed-scope agreement with written deliverables, or support it on a retainer after go-live. Whichever route you take, ask for the runbooks and restore test results as deliverables, not only the running system.
What support is available for self-hosted Supabase?
Self-hosted Supabase is community-supported. Supabase's self-hosting docs point to GitHub Discussions, GitHub Issues, Discord and Reddit, and direct enterprises to contact Supabase's Growth Team. Community channels answer questions but do not commit to response times or fixes for your environment, so any production incident response has to come from your team, a vendor contract or a partner retainer. Kubernetes deployments through a Helm chart or the Supabase Operator are community projects that Supabase does not maintain. Before you decide, ask Supabase's Growth Team in writing what enterprise support they offer for self-hosted deployments and what it costs.
Does self-hosting Supabase give us SOC 2 or HIPAA compliance?
No. Running the software yourself does not confer SOC 2 or HIPAA status, and DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Self-hosting moves the controls into your scope: access management, encryption, logging, backups, change management and incident response all become your evidence to produce. Supabase's hosted plans offer SOC 2 and HIPAA as part of their own offering, which you would not inherit by self-hosting. DeployOpen can prepare systems, controls and evidence for an assessment, and your auditor decides the outcome. Confirm the exact scope with your auditor before you plan the migration.
Which Supabase features will we lose or have to rebuild?
Supabase's self-hosting docs list several features as unavailable when self-hosting: branching, managed backups and point-in-time recovery, ETL, the Management API, advanced metrics, and analytics and vector buckets. Self-hosted Supabase also runs as a single project, so Studio does not handle multiple organizations or projects. Each of these needs an alternative: a backup routine with tested restores, a monitoring stack, a deployment pipeline for schema changes, and separate stacks for separate projects. Make a written list of the features your application depends on before you start, and mark each as keep, rebuild or drop.
What a move from Supabase Cloud to self-hosted Supabase involves
The sequence moves one Supabase Cloud project into a self-hosted instance you run, with secrets, keys, data, Storage objects and DNS each checked before the cutover. The end state is a verified, self-operated copy of the project with a backup approach you have chosen and tested.
Inventory the project and its dependencies
Your team lists everything the Cloud project depends on: database schema and data, Auth providers and redirect URLs, Edge Functions, Storage buckets and their policies, custom domains, and the apps and webhooks that call the project. Identify which of these the self-hosted stack supports directly and which you must rebuild, since branching, managed backups, PITR and the Management API are not available when self-hosting. The output is a written inventory that the platform owner signs off on before any infrastructure is provisioned.
Stand up the self-hosted environment and secrets
Your infrastructure team deploys the Docker Compose configuration from the supabase/supabase repository on servers you control, sized against the published minimums and the recommended specification for your expected load. Replace every placeholder value in the environment file, generate new secrets and the JWT key pair with the provided scripts, and protect Studio with the dashboard password. Confirm the stack starts and that no service still uses example credentials. Keep a record of the Docker configuration release you deploy so later upgrades can be planned against its changelog.
Restore the platform project into self-hosted
Using the documented restore path, your database team exports roles, schema and data from the Cloud project and restores them into the self-hosted Postgres instance. Restore with the same Postgres major version the target stack runs, and confirm that row counts and key tables match between source and target. Read the restore guide before you start, because it defines the order of steps and the Postgres-specific objects that need attention. The check that closes this step is a clean restore log plus a comparison of schema and row counts.
Copy Storage objects over the S3-compatible interface
Your storage team copies objects from each Cloud Storage bucket into the self-hosted Storage service through its S3-compatible interface, preserving bucket names and object paths so that existing client references keep working. Compare object counts and total sizes per bucket, then spot-check a sample of files with their access rules. Note any bucket policies that must be recreated by hand. The output is a per-bucket reconciliation showing matching object counts and no missing paths.
Reconfigure keys, auth providers and domains
Your platform engineers update client applications to use the new project URL and the new anon and service keys, because the JWT key pair generated in the new environment will not match the Cloud project. Re-enter each Auth provider's client ID and secret, confirm redirect URLs, configure SMTP for email flows, and rebuild Edge Functions in the self-hosted runtime with their environment variables. Set up custom domains and TLS on your own ingress. Verify that a test user can sign up, sign in and reach protected rows on the new instance.
Run parallel verification before cutover
Run the self-hosted instance alongside the Cloud project against a staging copy of your applications. Your QA and security teams exercise sign-in, row-level access rules, Storage downloads, realtime subscriptions and Edge Functions, comparing responses from both environments. Load test to the capacity you expect at peak, because no managed scaling is provided. Record each defect, its fix and the retest result. The step is complete when the open defect list is empty for launch-critical flows and the owner accepts the results in writing.
Freeze writes and cut over DNS
Plan a write freeze window with the business owner, stop writes to the Cloud project, run a final incremental copy of data and Storage objects, and confirm it matches the source. Switch DNS or the load balancer to the self-hosted endpoint, then watch authentication errors, failed queries and client-side error rates. Keep the Cloud project intact until the rollback plan has expired. The output is a documented cutover record with timestamps, final reconciliation results and the rollback decision.
Decide and test the backup approach
Before the Cloud project is retired, decide how the self-hosted database and Storage objects will be backed up, because managed backups and point-in-time recovery do not carry over. Options include scheduled logical dumps, WAL archiving with a tested restore process, or running Postgres on a managed-operator platform, and Storage backups must cover the object store as well. Confirm recovery objectives with your business owner, then run a full restore into a separate environment and check the result. The step closes when a restore has been performed and documented successfully.
When staying on Supabase Cloud is the better decision
Staying on Supabase Cloud is the better decision when your team cannot staff the operating work that self-hosting adds. Self-hosted Supabase is community-supported, and its documentation lists managed backups, point-in-time recovery, branching and the Management API as unavailable when you run it yourself. If you need those features, or a contractual support path, the hosted plans are the stronger fit. Ask your team a direct question before you decide: who will restore a database from backup in a test environment every quarter, and who will be on call when Auth or Realtime fails at night?
Branching-based workflows are a common reason to stay. Supabase Cloud offers branching, which lets developers test schema changes in an isolated copy before they reach production. Self-hosted Supabase does not provide it, so teams that depend on preview databases for each pull request would need to build their own environment provisioning. The same applies to frequent new projects. Self-hosted Supabase runs as a single project, while Studio on the hosted service works across organizations and projects. If your organization creates many short-lived apps, each one is a separate Docker Compose stack to deploy, patch and back up with the self-hosted option.
Self-hosting moves recovery testing, upgrades and incident response to your organization. Each Docker configuration release, such as 0.8.3 on October 16, 2026, lists per-service image changes and configuration edits that your operators must apply, and some database migrations are one-way, so the changelog asks for a backup before updating. Treat the hosted choice as conditional: revisit it when your platform capacity, compliance scope, data residency needs or support requirements change. Write those conditions down, name the owner who reviews them, and confirm current plan features on the Supabase pricing page before each review.
How DeployOpen helps you evaluate and move to self-hosted Supabase
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Supabase, we help you decide whether the hosted plan or a self-hosted stack fits your data, operating and support requirements, and then build the platform in your environment if you choose to move.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which Supabase Cloud features your applications use, such as backups, PITR, branching and Storage, and which you must rebuild.
- The written scope names the target environment, whether a cloud account, data center or air-gapped network you control.
How we build
- We deploy the Docker Compose configuration and trim unused services such as Realtime or Storage where your applications do not need them.
- We replace placeholder secrets, generate the JWT key pair, and protect Studio access before any environment receives user data.
- We plan backups, PITR-equivalent recovery and Storage object backups, then test restores against the self-hosted database.
How we hand over
- We document the environment variables, service versions and upgrade steps, including changelog entries that require a database backup first.
- We run security testing against the APIs, the database exposure and the Storage configuration, and report the findings in writing.
- We prepare the controls and evidence your compliance assessors need, while independent auditors issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover applying Docker configuration releases, monitoring the stack and restoring backups on a schedule you agree.
- Because self-hosted Supabase is community-supported, we help you define who responds to incidents and how upstream changes are reviewed.
