Why Firebase cannot keep all app data in the EU
A Firebase project cannot keep all of its app data in the EU, and the gap sits in authentication. Firebase Authentication processes data only in the United States, according to Firebase's privacy documentation, so a team that selects a European location for Cloud Firestore still has user records processed outside the EU. Two other rules make this harder to fix later. A Cloud Firestore database's location cannot be changed after provisioning, and unless a Firebase service offers a location choice, Firebase may process and store data anywhere Google or its agents maintain facilities. A compliance or residency policy that says auth, database and files stay in the EU therefore cannot be met by configuration alone on Firebase.
The short answer is to run the stack in an EU data center that you control. Self-hosted Supabase or Appwrite keeps authentication, the database and file storage on the same servers, in the region your organization chooses. PocketBase bundles the same three functions into one executable with embedded SQLite, but it is suited only to smaller apps. Before choosing, confirm with your legal and compliance team which data is in scope, including logs, backups and any support access from outside the EU, because those paths can also constitute transfers. Keep in mind that region selection is a data-location control, not proof of regulatory compliance. Supabase's own regions documentation makes this point, and its general Europe region can include London and Zurich, which are not EU member states, so the region name alone does not settle the question.
Plan the work in three checks. First, map every component that touches personal data, including the Auth service, the database, object storage, function logs and backups. Second, confirm that each one runs in the EU location you chose, and that no managed add-on, monitoring service or support channel sends data elsewhere. Third, ask your data protection officer whether the remaining exposure, such as a third-country authority request reaching your provider, needs a documented assessment. The EDPB's guidelines on Article 3 and Chapter V are the natural starting point for that review. Only an independent auditor can give an assurance opinion, so treat this as preparation rather than proof.
What the EU residency constraint requires
Residency for a Firebase replacement is decided by where every copy of personal data is stored, accessed and processed, not only where the database sits. The cards below set out the transfer rules and the provider exposure that shape how auth, database and file services are placed, so that one EU deployment does not leave a US-operated component holding part of the data.
Every transfer needs a basis
GDPR Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions of Chapter V. Infringements of Articles 44 to 49 can carry fines of up to EUR 20 million or 4% of worldwide annual turnover. For auth, this means the user table, sessions and password hashes must stay inside the EU deployment. Confirm with your counsel which copies, backups and logs count as personal data.
Remote access counts as transfer
The EDPB's Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support or administration, is a transfer. Storage in a cloud outside the EEA is also a transfer. For a self-hosted stack, this means vendor engineers or managed support staff outside the EEA must not open database consoles, Studio or storage buckets containing live data without a documented basis.
Database and file admin access
Admin tools such as Supabase Studio or the Appwrite Console can show rows, user records and uploaded files on screen. Restrict these interfaces to EU-based operators, protect them with access controls and audit their use. Ask any implementation or support partner where its staff sit and whether they can view production data from outside the EEA.
US-law processor exposure
The CLOUD Act provision at 18 U.S.C. 2713 requires US providers of remote computing services to preserve or disclose data in their possession, custody or control, wherever it is stored. The EDPB notes that complying with a third-country authority request would itself be a transfer. Before choosing a hosted option from a US company, check whether it can be bound by this law, and keep keys and admin rights under EU control.
Foreign court orders need a treaty
GDPR Article 48 allows a third-country court judgment or administrative decision demanding personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. Ask your legal team how a hosting or support contract handles such requests, including notice to you and challenge rights, and whether the provider commits to contest requests that lack a treaty basis.
Document the transfer assessment
Controllers should assess third-country exposure before engaging any processor, as the EDPB's Recommendations 01/2020 and Example 12 of Guidelines 05/2021 suggest. Record which components (auth, database, storage, functions, logs, backups) run in the EU, who operates them and which vendor contracts apply. Auditors and data protection authorities will ask for this inventory, and DeployOpen can help prepare the evidence without issuing any certification.
Which open-source platforms keep auth, data and files in the EU
This table compares how self-hosted Supabase, Appwrite and PocketBase keep authentication, database records and files in a location you choose, and what each one leaves to you. Read each row as a question to confirm in your own environment, since placement depends on the data center you select and the services you deploy. The main takeaway is that self-hosting moves all three data types under your control, but it also moves uptime, backups and support onto your team.
| Area | Supabase (self-hosted) | Appwrite (self-hosted) | PocketBase |
|---|---|---|---|
| License | Apache-2.0 for the main repository | BSD-3-Clause | MIT, self-hosted only with no company behind it |
| Auth location | Auth (GoTrue) runs in your Compose or cluster, so user records stay where you host it | Auth runs inside your install, so user records stay where you host it | Auth is built in and stored in the single SQLite-backed instance you run |
| Database location | Postgres 17 is the default, on infrastructure you choose | PostgreSQL is the default for new 2.x installs, with MariaDB and MongoDB also supported | Embedded SQLite file on the host you choose |
| File location | Storage service with imgproxy, on local disk or S3-compatible storage you run | Storage service on the install's volumes or an S3-compatible backend you configure | File fields stored on local disk of the PocketBase host |
| Hosted-only features missing | Branching, managed backups and PITR, ETL and the Management API are unavailable when self-hosting | Built-in datastores have no failover in the Helm chart, so production needs managed or operator-run databases | No documented managed backup, replication or Firebase importer to rely on |
| Operations and support | Community-supported through GitHub Discussions, Issues, Discord and Reddit | Self-run install and upgrades, with the vendor's documentation as the main reference | Volunteer-developed, with no promises of maintenance or support beyond what is available |
| Scaling and resilience | Multiple services to size and monitor, and you own high availability | Single replica datastores by default, so you design replication and failover | Single executable on one host, so scaling is vertical |
| Fit for EU-only data | Good fit when you control hosting and sub-processors, but confirm region and backup locations | Good fit when you control hosting, with the same confirmation of backup and log destinations | Suited to small apps where one EU host is enough, with a documented backup plan |
Where Firebase and the hosted clouds fall short of EU-only processing
Firebase cannot keep all app data in the EU, and the reason is in Google's own privacy documentation. Firebase Authentication runs only from US data centers and processes data exclusively in the United States, so choosing a European location for Cloud Firestore does not move user accounts. The same documentation says that, unless a Firebase service offers a data location selection, Firebase may process and store data anywhere Google or its agents maintain facilities. Before you commit, list every Firebase service in your app (Auth, Firestore, Storage, Functions, Hosting, Realtime Database) and check each one against that statement, because a regional Firestore setting is only one piece of the data flow.
Hosted alternatives need the same scrutiny. Supabase's regions documentation says region selection is a data-location control, not proof of regulatory compliance, and that its general Europe region can include London and Zurich, which are not EU member states. If you choose a Supabase Cloud project in a European region, ask Supabase in writing which facilities hold the database, backups, Storage objects and Auth data, and whether any support or operational access can occur from outside the EU. Appwrite Cloud is also a hosted service, so ask Appwrite the same questions about the region of each project, where backups and logs are kept, and which legal entity operates the service. Keep the written answers with your records of processing.
Treat these answers as the decision point. If a vendor cannot confirm, in writing, where every component of your app stores and processes personal data, the hosted option does not meet a strict EU-only requirement, and a self-hosted deployment in an EU data center you control is the clearer path. Confirm with your legal and compliance team whether the vendor's answers meet your obligations under the GDPR, and ask your cloud provider for the same location commitments on its own infrastructure, since the application vendor cannot promise what the underlying provider does not.
How to deploy self-hosted Supabase or Appwrite in an EU data center
This sequence takes a team from choosing an EU region it controls to a pinned, hardened, backed-up deployment where authentication, data and files stay under its own control. Each step names the check that confirms it is complete.
Choose an EU data center you control
The platform team, with the data protection officer, picks a data center or cloud region inside the EU or EEA that the organization operates or contracts directly, and records the location in the processing inventory. Confirm in writing with the hosting provider where backups, snapshots and logs will be stored, since a region choice alone does not settle where every copy of the data lands. Supabase's regions documentation notes that its general Europe region can include London and Zurich, so pick a specific EU region rather than a broad label. Done when the region, provider and backup location are documented and approved.
Size hosts to documented minimums
The infrastructure team provisions virtual machines or nodes that meet the minimums in each project's documentation: for self-hosted Supabase, 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB, 4 cores and 80 GB recommended; for Appwrite, 2 CPU cores, 4 GB RAM, 2 GB of swap and Docker Compose version 2. Plan for production headroom above these figures and confirm sizing against expected load in a test run. Done when hosts pass a preflight check for CPU, memory, disk and Docker Compose version.
Pin versions and replace placeholder secrets
The platform engineer pins the self-hosted Supabase Docker configuration to a reviewed release, such as 0.8.3, which bundles specific Auth, PostgREST and Realtime versions, or pins the Appwrite image to appwrite/appwrite:2.5.0 rather than a floating tag. Before first start, replace every value from .env.example using the generation scripts, including the JWT key pair, and never boot with placeholder secrets. Done when the environment file contains no default values and the image tags match the approved release record.
Move PostgreSQL, Redis and object storage to resilient services
Appwrite's Helm chart documentation states that its built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so production data should move to managed services or operators. Self-hosted Supabase also runs Postgres in a container by default, so decide whether to point it at a managed or operator-run PostgreSQL cluster with backups and replication. Confirm the chosen database and object store are in the same EU region as the application. Done when the connection strings target the external services and a failover test has been recorded.
Restrict admin access and protect Studio
The security engineer limits access to the Studio and Console to named administrators on a private network or VPN, and sets Studio credentials through DASHBOARD_PASSWORD for Supabase or equivalent admin controls for Appwrite. Remove services the project does not need from docker-compose.yml, such as Realtime, Storage, imgproxy or Edge Runtime, to shrink the attack surface. Done when the admin interfaces are unreachable from the public internet and an access list is on file.
Migrate users and test password hash compatibility
Export Firebase Auth users with the Firebase CLI, which includes the modified scrypt hash parameters, then import them into the target. Appwrite's Users API accepts Firebase's scrypt modified format, and Supabase documents importing users into auth.users with the project's scrypt parameters. Test a sample of real accounts with known passwords on a staging instance to confirm sign-in works without forced resets, and document any accounts that need a reset. Done when staging logins succeed for the test set and the exception list is approved.
Take a backup before one-way Storage migrations
Supabase's changelog for 0.8.3 flags security fixes for Storage and Realtime and notes that some Storage database migrations are one-way and require a database backup before updating. Take a verified full database backup and a copy of the object store before applying any upgrade that changes the Storage schema, and restore the backup in a test environment once. Record the backup identifier and the release notes reviewed. Done when the restore test succeeds and the upgrade runbook references that backup.
Evidence auditors and regulators ask for
A controller defending EU residency needs a written record of where each part of the backend runs, who can reach it from outside the EU, and how the team would restore it. The cards below list the records DeployOpen prepares during an implementation. Auditors, supervisory authorities and certification bodies make their own assessments from this evidence, and DeployOpen does not issue them.
Processing location register per service
Record the physical location of every component: the database, Auth, object storage, functions, backups, logs and analytics. Firebase Authentication processes data only in the United States, so that row must show a non-EU location for any Firebase-hosted service you keep. For the self-hosted stack, name the EU data center or cloud region that hosts each container and volume, and confirm the region with your provider in writing. Region selection on a hosted platform is a data-location control, not proof of compliance, so keep that caveat in the register.
Transfer assessment for third-country processors
List every processor and sub-processor that can reach personal data, and mark those subject to third-country law with extraterritorial reach. Document whether a third-country authority could compel access and what the assessment concluded about supplementary measures. DeployOpen prepares the assessment file, but the controller decides whether to rely on the processor and should record that decision with its legal basis.
Remote access and support log
Keep a record of every administrative session, vendor support action and remote view of production data, including who connected, from which country and for what purpose. The EDPB treats remote access from a third country, even only displaying data on a screen, as a transfer. Logging these sessions shows whether support staff outside the EU touched production data and gives the controller the evidence to answer that question.
Data Act switching rights and dates
Record the customer's right to switch to another provider or to on-premises infrastructure under the Data Act, which has applied since 12 September 2025. The register should show the maximum two-month notice period, the 30-day transition and the date from which switching charges are banned. Keep a copy of the contract clauses that reflect these terms, so the switching plan can be executed without a dispute.
Data processing agreement and sub-processor terms
Collect signed data processing agreements with every hosting provider, managed database operator and support vendor, and track each sub-processor change notice. Confirm that the agreement states the processing location, the transfer mechanism for any non-EU access and the audit and deletion terms. Where a vendor cannot commit to an EU location in writing, flag that gap for legal review before the data is loaded.
Backup and restore test records
Document where backups are stored, how long they are kept and which region holds them, since a backup copy is also personal data. Keep dated restore test results showing that the database, Auth users and files come back together in an EU location. Self-hosted Appwrite's built-in datastores run a single replica without failover, so the record should show the chosen production database and its own backup and failover arrangement.
Questions buyers ask before moving off Firebase for EU residency
Is a hosted EU region enough, or do we need to self-host?
A hosted EU region keeps some data in the EU, but it does not keep all of it there. Firebase's privacy documentation states that Firebase Authentication runs only from US data centers and processes data exclusively in the United States, so choosing an eur3 Firestore location leaves user identity outside the EU. Supabase Cloud regions are a data-location control, not proof of regulatory compliance, and its general Europe region can include London and Zurich, which are not EU member states. Self-hosting in an EU data center you control lets auth, the database and files sit in one place that you select and document. Confirm with your counsel which transfer and processor conditions still apply to any vendor support access.
What drives the cost of a self-hosted Firebase replacement?
Cost splits into one-time work and recurring operations. One-time items are the migration, the rewrite of client SDK calls and security rules, and testing. Recurring items are the servers and storage for the chosen stack, backups, monitoring, upgrades and the people who patch and operate it. Supabase's Docker 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, and Appwrite's installation guide requires 2 CPU cores, 4 GB of RAM and 2 GB of swap. Ask for a quote that lists each component separately, names who pays for each, and states the expected release cadence you will need to absorb.
How long does a migration take, and what changes the timeline?
Duration depends on scope more than on any single tool. The main variables are how many Firestore collections need to become Postgres tables or Appwrite collections, how many Auth users and password hashes must move without resets, how many Storage files need copying, and how much client code and security rules must be rewritten. Supabase documents scripts for Firestore data, Auth users and Storage files, and Appwrite's Migrations feature imports Firebase projects, but both still need testing before cutover. Ask for a fixed-scope plan with written milestones and a clear test phase rather than a single date.
What must our team provide during the engagement?
Your team needs to supply access and decisions that only you can give. Typically that means a named owner for data classification and the target EU location, read access to the Firebase projects and a service account for exports, a list of Firestore collections and security rules, the Auth configuration and any social or enterprise sign-in providers, and staff time for acceptance testing of the rewritten app. You also need to decide who owns the on-call rota and change approvals after go-live. Ask the implementation partner to list these inputs in the written scope so gaps surface before work starts.
Can our own engineers run the self-hosted stack without a partner?
Your engineers can run it, but they should plan for ongoing operations. Self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, and enterprises are directed to contact Supabase's Growth Team. Appwrite's built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without failover in its Helm chart, so production data needs managed services or operators. Each Supabase Docker release pins specific upstream service versions that operators must pull and recreate, and some releases require a database backup before updating. Many teams keep an internal owner and bring in an implementation partner for the migration and periodic upgrades under a retainer.
How do the Firebase Dynamic Links and Extensions deadlines affect timing?
Dynamic Links has already shut down, and Firebase Extensions will shut down on March 31, 2027, after which deployed extensions can no longer be updated, reconfigured or uninstalled. Firebase Dynamic Links shut down on August 25, 2025, so any link resolution that still depends on it needs replacing now. Extensions require an inventory and a plan to rebuild each one as functions or a self-hosted service before the deadline. Because the residency work touches the same data paths, many teams combine both tasks into one plan. Confirm the current deprecation terms in Firebase's own documentation before you set your internal dates.
Does moving data to our own servers also move legal risk to us?
Self-hosting changes who processes the data, so your legal risk moves with it. Under GDPR Article 44, every transfer of personal data to a third country must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even if data is only displayed on screen for support. The CLOUD Act at 18 U.S.C. 2713 can reach data held by US providers wherever it is stored, so a US-controlled vendor with EU hosting still needs assessment. Self-hosting in your own EU infrastructure reduces that exposure, but you still need to review any vendor support access and document the decision with your data protection officer.
How DeployOpen deploys EU-resident backends
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source backends inside your own cloud accounts, data centers or air-gapped networks. For EU data residency, the work starts with a written map of where auth, database rows and files are processed, so every component is placed in a region you choose.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists each data flow for auth, database, files and functions, with its processing location.
- Scope confirms which Firebase services are in use, including Authentication, Firestore, Storage and Functions.
How we build
- We deploy the chosen platform, such as Supabase, Appwrite or PocketBase, into an EU data center or cloud region you specify.
- We configure secrets, admin access and network controls, and we test that auth, data and files stay in the agreed location.
- We rebuild access rules for the new data model and run security testing against the APIs and storage endpoints.
How we hand over
- Handover includes architecture and data flow documentation, runbooks for upgrades and backups, and a record of the tests run.
- We prepare the controls and evidence your compliance team needs, while independent auditors issue any formal assessment.
- Migration steps for users, password hashes and files are documented so your team can repeat or verify them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades are planned against each platform's release notes, with backups taken before changes that require them.
- Ask us to confirm which parts of your EU residency position depend on your legal advice rather than on our deployment.
