Self-hosted Supabase for EU data residency

Does self-hosted Supabase solve EU data residency?

Choosing an EU region for a Supabase Cloud project does not by itself settle transfer exposure. A Supabase Cloud project is hosted in one main region chosen from 17 AWS regions, but the provider's operations, remote access and legal reach still determine whether personal data leaves the EEA. Self-hosting Supabase in an EU data center or sovereign cloud that you select can resolve the question, provided your organization owns the operations: the servers, the access paths, the logs, the backups and the patching. The stack is Apache-2.0 and runs from the Docker Compose configuration in the supabase/supabase repository, but Supabase describes self-hosted Supabase as community-supported, so the support contract you have today will not carry over.

The rest of this page separates three questions that are often merged. The first is location: where the database, Storage objects and logs physically sit. The second is access: who can view or administer that data from outside the EU, including support staff and remote troubleshooting, which EDPB Guidelines 05/2021 treat as transfers even when data is only displayed on a screen. The third is legal reach: whether a provider with a parent or operations in a third country can be compelled to disclose data, which EDPB Recommendations 01/2020 treat as a limit that technical measures may not overcome. Self-hosting moves the first two questions under your control. The third depends on who operates the infrastructure and which jurisdictions their staff and parent companies answer to, so confirm it with your legal team and processor contracts.

Before you decide, write down each data flow and map it to these three questions. Check where Auth, Postgres, Storage, Realtime and any analytics or log pipeline store data, including Vector or Logflare if you enable them, and confirm that backups and any monitoring tools stay in the EU as well. Ask whether the community support channels, which include GitHub Discussions, GitHub Issues, Discord and Reddit, meet the response expectations of your risk register, and whether you need a paid operator or an implementation partner to fill that gap. Your Data Protection Officer and counsel should review the result before any personal data is moved.

What EU data residency requires from a backend

A self-hosted backend moves residency from a vendor setting to a set of decisions you own. The cards below cover where data sits, who can reach it remotely, how a foreign authority request would be handled, and how you would leave the platform later. Each one maps to a provision in the GDPR, the EDPB transfer guidelines, or the EU Data Act.

Fix where data is stored

Under GDPR Article 44, any transfer of personal data to a third country must meet the Chapter V conditions, and that includes onward transfers. For a self-hosted Supabase stack, the database, Storage buckets, backups and log sinks all count as places data lands. Ask which EU region or sovereign cloud each one uses, and confirm that Postgres replicas and off-site backup copies stay inside that boundary too.

Control remote access from outside the EEA

EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when a support engineer only views data on a screen. Storage outside the EEA is also a transfer. Review which vendor staff, contractors or managed-service operators can reach production hosts, consoles or database sessions, and from which countries.

Plan for third-country authority requests

EDPB Guidelines 05/2021 (Example 12) explain that an EU processor subject to third-country law is not itself a transfer, but complying with a foreign authority's request would be. Article 48 of the GDPR allows such an order to be enforced only under an international agreement such as a mutual legal assistance treaty. Recommendations 01/2020 add that where a provider needs data in the clear and foreign powers go beyond what is necessary, no effective technical measure may exist. Assess this exposure before you pick the operator.

Keep the right to switch providers

The EU Data Act, applicable since 12 September 2025, gives customers the right to move from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Article 32 also asks providers to prevent third-country governmental access to non-personal data held in the Union. Write exit terms into your contract, and test that you can export databases, Storage objects and Auth users in a usable format.

Where Supabase Cloud region choice stops

Choosing a region gets you part of the way to EU data residency, and no further. Each Supabase Cloud project is hosted in one main region chosen from 17 AWS regions, so selecting an EU region keeps the project's database and storage at rest in the EU. That is the easy part. Where the data sits is not the same as who can reach it. Under EDPB Guidelines 05/2021 (version 2.0), remote access from a third country counts as a transfer, even when the person only views data on a screen for support or administration, and so does storage in a cloud outside the EEA. A support engineer or administrator located outside the EEA who can open project data therefore triggers Chapter V of the GDPR, whatever region the project was created in.

The provider's legal home matters as well. The CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data is inside or outside the United States. A region selector does not change that duty for a US-linked company. EDPB Recommendations 01/2020 also state that where a provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Your assessment of this exposure should be documented before you commit to the hosted plan. Ask Supabase in writing for its data processing terms, its list of sub-processors with their locations, and the countries from which its staff can access customer projects for support. The supplied material does not tell you those answers, so do not assume them.

Make the decision with those written answers in hand. If the processor terms do not give you the access locations and sub-processor list you need, self-hosted Supabase in an EU data center or sovereign cloud you choose removes the provider from the access path, but it moves the operating duties to your team, including the logging, backups and upgrades covered in the other sections of this page. Ask your legal and privacy team to record the transfer analysis either way, and ask your auditor which evidence they expect to see for remote access from outside the EEA.

Which open-source options fit an EU residency requirement

Self-hosted Supabase in a data center you control or lease in the EU keeps project data, backups and logs in a location you choose. The stack is the Apache-2.0 repository published with a Docker Compose configuration, so the same services that run on Supabase Cloud can run on your hardware. Residency is satisfied by the location, but compliance also depends on who can administer the systems and where support traffic flows.

Location control: You select the facility and the country, and Postgres, Storage and log volumes stay there unless you copy them elsewhere.
Docker Compose deployment: The documented method is Docker Compose, with the minimum of 4 GB RAM, 2 CPU cores and a 40 GB SSD listed in the Docker guide, and 8 GB RAM, 4 cores and 80 GB recommended.
Single project per Studio: Self-hosted Studio manages one project, so separate environments or tenants need separate stacks.
Backups you build: Managed backups and point-in-time recovery are not available when self-hosting, so you design dumps, WAL archiving and tested restores.
Community support only: Support comes through GitHub, Discord and Reddit, and enterprise support is directed to Supabase's Growth Team.

Confirm with your data protection officer that the facility, remote administration and any vendor support sessions all sit inside the scope you have documented. Ask your data center provider for its certifications and where its staff access systems from.

What you take on when you self-host Supabase in the EU

Self-hosting moves hardware sizing, secrets and logging from the vendor to your team. The Docker self-hosting 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. Those are starting points, not capacity plans. Size the host for your expected Postgres load, Storage volume and Realtime connections, and confirm with your own load tests. The guide also says unused services such as Realtime, Storage, imgproxy or Edge Runtime can be removed from docker-compose.yml, which is a decision to document rather than a default to accept silently.

Never start the stack with the placeholder values in .env.example. The guide provides scripts that generate the database password, the JWT secret, the JWT key pair and the other service secrets, and the JWT keys must match what Auth, PostgREST, Realtime and Storage expect. Record where these secrets are kept, who can read them and how they rotate. Protect Studio with the HTTP basic auth set through DASHBOARD_PASSWORD, and keep the Studio and API gateway ports off the public internet unless you have a reason to expose them. Your EU residency argument fails if an administrative console is reachable from outside your network.

Logging is also yours to design. The Compose services include optional Logflare and Vector for analytics and logs, and you decide where those logs are stored, how long they are kept and whether they contain personal data such as IP addresses or user identifiers. Those logs must stay in the EU too. Before updating, read the 0.8.3 entry in the self-hosted Supabase changelog: it flags one-way Storage database migrations that require a database backup before you update. Take and test that backup first, because a rollback path may not exist.

Backups, logging and support you must rebuild

Self-hosting Supabase moves four operating jobs from the vendor to your team: recovering data, retaining logs, keeping services patched and getting help when something breaks. Each card below names one of these jobs, what it means for EU data residency, and what to confirm before you commit to a design.

Backups and point-in-time recovery

Managed backups and point-in-time recovery are not available in self-hosted Supabase, so the database backup process is yours to design, run and prove. A restore you have never tested is not a backup, and the copy must stay in the EU location you chose, which means the backup target, its encryption keys and its access accounts need the same residency review as the primary database. Ask whether your recovery point and recovery time targets are written down, and schedule a restore into a clean environment at a regular interval. Changelog notes for some Storage releases require a database backup before updating, so make that step part of every upgrade runbook.

Logs, analytics and retention

Logflare and Vector are optional components in the Docker configuration, so logging only exists if you deploy and configure it. Request logs can contain personal data such as IP addresses and user identifiers, which makes retention and access control a GDPR question as well as an operations one. Decide where logs are stored, who can read them, how long they are kept and how they are deleted, and confirm that none of these steps sends log content to a third-country service. Test the pipeline with a deliberately failing request to confirm that errors are captured before you rely on it for an incident.

Security patching and version pinning

Each self-hosted Docker configuration release pins specific upstream services, so Auth, PostgREST and Realtime versions arrive when you pull and recreate the containers. Security fixes, such as those flagged for Storage and Realtime in the 0.8.3 changelog, reach you only when your team applies them. Set a monitoring routine that watches the changelog and upstream advisories, test each update in a staging copy with your own data shape, and keep a rollback plan. Confirm who is accountable for patch timing inside your organization, because the vendor will not patch your running instance.

Support and escalation paths

Self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, and there is no service-level commitment in those channels. Enterprises are directed to contact Supabase's Growth Team, but any commercial support, response time or indemnity you need must be written into a contract, so ask for that document before you assume it exists. Name an internal owner for production incidents, define how you escalate a data-exposure event under your GDPR breach process, and check whether a third-party integrator would provide the on-call cover you need.

How to deploy self-hosted Supabase in an EU facility

This sequence moves a Supabase Cloud project into a self-hosted Supabase stack in an EU facility you choose, with the hosting, secrets, access, logging, backup and cutover decisions recorded at each stage.

Confirm the EU host and its operator jurisdiction
Choose the EU data center or sovereign cloud and document who operates the facility, the hypervisor and the network, and which legal jurisdictions can compel those operators. Ask the provider in writing where support staff access originates and whether remote access from outside the EEA is possible. Ask your counsel to review the answers against the transfer analysis for your data. The step is done when you hold a signed record of the operator, the physical location of every system holding personal data, and the list of who can reach them.
Build the Docker Compose host
Provision a Linux host in the chosen facility sized against Supabase's documented minimums and its recommended specification, then clone the Supabase repository and copy the Docker configuration from its docker directory. Pin the configuration to a specific release tag rather than tracking the default branch, and record the bundled upstream service versions in your change log. Remove services your application does not use, such as Realtime, Storage, imgproxy or Edge Runtime, by editing docker-compose.yml. The step is done when docker compose config validates and the stack starts with the services you kept.
Generate secrets and JWT keys
Replace every placeholder value in the example environment file before first start, using the secret generation scripts supplied with the configuration. Generate the JWT key pair and the database, dashboard and API keys, then store them in your organization's secrets manager rather than in a shared file. Set the dashboard password and confirm the placeholder values are gone. The step is done when a search of the environment file finds no example values and the keys are recorded in your key register with an owner and a rotation procedure.
Restrict Studio and network paths
Limit Studio and the database port to administrative networks, place the API gateway behind TLS with a certificate issued for your domain, and enable HTTP basic authentication for Studio. Decide which client networks reach the API and the Storage endpoints, and block all other inbound paths at the host firewall and at the facility perimeter. Confirm the operator's remote administration path is logged and restricted to named staff. The step is done when a scan from outside the approved networks shows only the intended ports and a test login to Studio fails without credentials.
Set log retention and tested backups
Decide how long gateway, Auth, database and analytics logs are kept, where they are stored inside the EU facility, and who can read them. Configure the optional analytics and log services only if you need them, and check that logs do not capture bearer tokens or personal data you do not need. Self-hosted Supabase does not provide managed backups or point-in-time recovery, so schedule database dumps and Storage object copies to the EU location and run a restore into a separate host. The step is done when a restore test completes, the restored row counts match the source, and the retention settings are written into your records of processing.
Migrate data using the platform restore guides
Follow Supabase's documented path for moving a platform project to self-hosting, which covers restoring the database dump and copying Storage objects over the S3-compatible interface. Export roles, schema and data from the Cloud project, restore them into the self-hosted Postgres instance, then copy Storage buckets and objects. Reconfigure JWT keys, auth providers, Edge Functions and domains, since these do not move automatically. Keep the Cloud project in place until verification passes. The step is done when a row-count and checksum comparison on sampled tables and a sample of Storage objects match the source.
Cut over DNS and verify
Lower the DNS time to live ahead of the change window, then point your application domain to the EU gateway and update redirect URLs and OAuth callbacks that reference the old project. Run smoke tests covering sign-in, reads and writes, file upload and download, and any realtime features you kept. Confirm the Cloud project is no longer receiving traffic before deciding when to retire it, and keep a tested rollback path for the duration of the agreed window. The step is done when all smoke tests pass from the production network and traffic logs show no requests reaching the old Cloud endpoint.

Evidence a regulator or auditor will ask for

A regulator or auditor will want to see where personal data sits, who can reach it from outside the EEA, and whether you can recover it and explain every change. The cards below cover the records that connect those answers. DeployOpen prepares this evidence, but independent auditors and certification bodies, not DeployOpen, issue any audit report or certification.

Data location register

List every facility that stores or processes personal data, with its city, operator and legal entity, plus each sub-processor that touches it. Include backup copies, object storage, log pipelines and the Studio host, since each is a separate location. Ask each sub-processor to confirm in writing where its staff and support tooling can reach the data. Refresh the register whenever a server, backup target or vendor changes.

Transfer impact assessments

Document whether any remote access from a third country, including support sessions that only display data on a screen, counts as a transfer under the EDPB Guidelines 05/2021. For each foreign provider, assess CLOUD Act exposure under EDPB Recommendations 01/2020, which concludes that no effective technical measure can cover access in the clear where third-country powers exceed what is necessary and proportionate. Record the conclusion and the date you reviewed it.

Foreign disclosure request position

Write down how your organization would respond to a third-country court order or administrative demand for personal data. Under GDPR Article 48, such a demand is recognized in the EU only when it rests on an international agreement in force with the Union or a Member State, so your legal team should decide in advance how to handle requests outside that path. Keep this position with the register and confirm it with counsel.

Restore test records

Keep dated records of restores into a separate environment, showing which backup was used, how long the restore took, which Postgres and Storage objects were checked, and who signed off. Self-hosted Supabase has no managed backups or point-in-time recovery, so these records are the only proof that your own backup process works. Repeat the test on a schedule and after any major change to the database or storage layout.

Docker Compose change records

Log each upgrade to the self-hosted Supabase Docker configuration with the release tag, the upstream service versions it pins, the reviewer and the rollback plan. Note any release that requires a database backup before updating, as the 0.8.3 changelog does for one-way Storage migrations. Keep the pre-change backup reference with the record so an auditor can trace each production change.

Questions EU teams ask before self-hosting Supabase

Is an EU Supabase Cloud region enough for data residency?

It depends on what your residency rule requires. Each Supabase Cloud project is hosted in one main region chosen from 17 AWS regions, and several of those are in the EU, so the data at rest can stay in the EU. Residency is not only about where bytes sit, though. Under the EDPB's Guidelines 05/2021, remote access from a third country, even only viewing data for support, counts as a transfer, and so does storage outside the EEA. Ask Supabase in writing which entities can access project data, where support staff operate, and how backups and logs are stored. Then compare those answers with your transfer assessment.

How much effort does self-hosting Supabase take, and what drives it?

The main effort is operating the stack, not installing it. Self-hosted Supabase runs as Docker Compose services, including Studio, an Envoy API gateway, Auth, PostgREST, Realtime, Storage, Postgres and Supavisor, and each Docker configuration release pins specific upstream versions that you pull and recreate yourself. The version 0.8.3 changelog, for example, flags security fixes for Storage and Realtime and one-way Storage database migrations that require a backup first. Effort rises with the number of services you keep, your upgrade cadence, your backup and restore testing, monitoring, and the security review of your own secrets and network. Ask for a written breakdown of these items in any quote.

Can our team run self-hosted Supabase without outside help?

A team with container, Postgres and Linux operations skills can run it alone, but the community-supported model means there is no vendor SLA behind it. Supabase's self-hosting docs direct questions to GitHub Discussions, GitHub Issues, Discord and Reddit, and enterprises to its Growth Team. Several managed features are unavailable when you self-host, including branching, managed backups, point-in-time recovery, ETL and the Management API, so you must rebuild any you need. Assess your in-house skills against that list. Outside help is most useful for the initial hardening, backup design, restore tests and upgrade runbooks.

How long does a migration from Supabase Cloud take?

The duration depends on data volume and scope, and no reliable figure applies to every project. The main variables are the size of the Postgres database, the volume of Storage objects, how many Edge Functions and auth providers need reconfiguring, how many domains and JWT-dependent clients you have, and how much testing your compliance evidence requires. Supabase's documented path covers dumping roles, schema and data with the Supabase CLI, restoring with psql, and copying Storage objects with rclone over S3. Ask for a timeline built from a written inventory of your project, and request a rehearsal migration into a non-production environment before cutover.

What do the Data Act switching rights mean for exit planning?

The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure. Under Articles 25, 29 and 50 of Regulation (EU) 2023/2854, the maximum notice period is two months, the transition period is 30 days, and switching charges are banned from 12 January 2027. For exit planning, this means you can start a documented exit before a contract ends, but you should still confirm with your provider how the process works in your agreement. Keep your own exports and restore tests current so a switch does not depend on the provider's cooperation.

What does a fixed-scope DeployOpen engagement cover?

A fixed-scope engagement covers the items agreed in writing before work starts, such as planning the target architecture, implementing self-hosted Supabase in your cloud account, data center or air-gapped network, integrating it with your identity and applications, hardening it, setting up backups and documentation, and preparing evidence for compliance assessments. Scope, deliverables and timelines are fixed in that written agreement. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do. Ongoing support, upgrades and continuous testing are available as retainers. A quote follows from the written scope, so list your data locations, services and migration sources when you ask for one.

Which hidden costs should we compare against Supabase Cloud?

The costs that often get missed fall into four groups. First, the servers and storage that run Postgres, Storage and the auth service in your environment. Second, backup tooling, off-site copies and restore testing, since managed backups and PITR are not included when self-hosting. Third, upgrade work, because each configuration release may require a database backup before updating. Fourth, on-call and security time for patching, monitoring and incident response. Supabase Cloud costs also recur through its paid plans, so model both sides over the same period. Ask any implementation partner to itemize these components and state who pays for each.

How DeployOpen deploys Supabase under EU residency rules

DeployOpen plans, implements, hardens, documents and supports self-hosted Supabase inside the client's own infrastructure, including EU data centers or sovereign clouds the client selects. We start by mapping where personal data, backups, logs and support access sit today, then build the stack so those locations stay under your control. Engagements are fixed-scope, with the written scope setting what is delivered.

How we scope

We map every place personal data, Storage objects and backups would sit under the chosen EU environment.
The written scope lists which Supabase services are deployed, such as Auth, Storage, Realtime and Edge Runtime.
We record which parties may access the stack remotely, including vendor or DeployOpen staff, before work starts.

How we build

We deploy the Docker Compose configuration in your EU infrastructure and replace all placeholder secrets before first start.
We configure Studio access, JWT keys and logging sinks so that log data stays within the agreed region.
We test restores of the database and Storage objects, and verify that no data path leaves the agreed environment.

How we hand over

You receive architecture, data flow and location documentation that your DPO and auditors can review.
Runbooks cover secret rotation, upgrades to new Docker configuration releases and the one-way Storage migration backup step.
We prepare control evidence for your compliance assessment, while independent auditors and certification bodies issue any formal opinion.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Retainers can cover pulling new upstream service versions, re-running restore tests and reviewing changes to residency assumptions.
Ask any provider which parties can access logs and backups from outside the EU, and confirm it in the written scope.

Self-hosted Supabase alternative for EU data residency