Base44, GDPR and data residency: where your app’s data lives

A practical overview, not legal advice. If your obligations are complex, for example special-category data or public-sector clients, talk to a data protection professional.

Where Base44 keeps data by default

Base44’s privacy and security documentation is direct about this: all Base44 servers are currently in the United States, and data for every workspace is stored in the US by default. Transfers out of Europe are covered by data processing agreements with Base44’s vendors, relying where applicable on adequacy decisions, Standard Contractual Clauses or the EU-US Data Privacy Framework. Base44 publishes a Data Processing Agreement for its customers.

You can check where each of your apps stores its data under your workspace’s Settings → Basic information → View data residency for all workspace apps.

The EU and UK data residency option

Since 16 April 2026, workspaces on the Elite or Enterprise plan can choose to store app data in an EU or UK cluster instead of the US. The documentation sets out the conditions carefully, and each one matters:

• It only applies to apps created after you change the setting. Existing apps stay where they are.
• It’s rolling out gradually, and may not be available in your workspace yet.
• It covers storage, not processing. Requests may be handled by Base44 services in another region before the result is saved in your chosen region.
• It covers your app’s data and users (the Data and Users sections of the dashboard). Uploaded media files, your Base44 account details and billing information stay in the US regardless.

Moving an existing app to the EU

For an app created before the setting changed, Base44’s documented route is: change the workspace residency, clone the app (the clone is created in the new region), export each table from the original as CSV, and import it into the clone. The documentation adds that app users aren’t copied when you clone and can’t be exported, so your users have to sign up again on the cloned app.

A layer-by-layer view

Data residency isn’t one setting; it’s a stack. Here’s where each layer lives in each setup:

For many European apps, the lines that matter most are files and processing. A clinic’s uploaded documents or an HR tool’s contracts are often the most sensitive data the app holds.

Responsibilities that stay with you

Whichever platform you use, you are usually the controller of your users’ personal data, and the platform is your processor. That means these jobs are yours:

• A lawful basis for each kind of processing, and a privacy notice that tells your users what you do, who your processors are and where data goes.
• A processing agreement with each processor: your hosting provider, database, email service, AI provider and analytics.
• Records of processing, and a transfer assessment where data leaves the EU.
• Data subject rights. People can ask for a copy of their data or for its deletion. Base44’s guide to deleting a user’s data describes removing the user from the Users section and then finding and deleting their records in every table, one by one.
• Breach notification, usually within 72 hours of becoming aware of a breach.

One more item deserves attention on Base44 specifically. Its documentation says that on plans other than Enterprise, workspace data can be used to train AI models, with no opt-out setting, and that the Enterprise exclusion covers personal information people submit through your app’s forms. If your app collects personal data from EU residents, consider how that fits your lawful basis and what your privacy notice says.

Running your app where you choose

When the app runs on your own accounts, residency stops being a plan feature and becomes a setup decision. With Unbase44, choosing where the app runs is part of setup: you choose a provider and a region, and the app, its database and its files all run there:

• Railway, with the app, its MongoDB database and its file storage in one account, in the region you choose.
• Hetzner, with your app and database on a server in one of its EU data centres or its US locations (coming soon).
• MongoDB Atlas for a managed database, in whichever region you choose (coming soon).
• AWS, in any of its regions (coming soon).
• Any Linux server you can reach over SSH, including one with a local European hosting company.

Processing happens where your server runs, AI calls go to the provider and region you connect, and emails go through your own email provider. And unlike cloning into a new Base44 region, your users keep their accounts and passwords: each person’s first sign-in on the new app is checked against Base44 once, then stored as your app’s own hash.

You still need processing agreements with the providers you choose; the difference is that you choose them, and you can name them in your privacy notice.

A short checklist

• Look up your app’s current residency in the workspace settings.
• List every place personal data goes: records, users, files, emails, AI calls, analytics, error tracking.
• Check each against where you’re allowed to send it.
• Update your privacy notice and your records of processing.
• If you’re moving, decide the region before you migrate, and keep the old app running until users have signed in to the new one.