EU data residency and AI app builders: who hosts where

You built an app on an AI platform, it stores customer details, and someone just asked you a simple question you can’t answer: where does that data physically live? For most teams the honest answer is “wherever the platform put it by default,” and that default is usually a data centre in the United States.

Data residency is the question of which country your data sits in. Under GDPR it matters because moving personal data out of the UK or EU triggers extra legal steps. This post walks through how the popular AI app builders tend to handle hosting location, and how to check your own setup instead of guessing. Treat the platform details as general background, not a promise: providers change regions and options often, so always verify against the current dashboard.

Why hosting location is a legal question, not just a technical one

GDPR lets personal data move freely inside the UK and EU. The moment it goes to a country outside that zone, you need a lawful basis for the transfer. The common ones are an “adequacy decision” (the EU has decided that country’s laws protect data well enough) or “Standard Contractual Clauses” (a set of contract terms the provider signs to promise equivalent protection).

The US sits in an awkward spot. There’s a framework called the EU-US Data Privacy Framework that some US companies join to make transfers lawful, but not every provider is certified, and the legal ground has shifted more than once in the last decade. So “our data is in the US” isn’t automatically a violation, but it is automatically a thing you have to be able to explain, with the transfer mechanism named.

The practical trap: most AI app builders spin up your database in a US region by default because that’s where the platform itself runs. If you never changed it, that’s where your customers’ data is, whether or not you meant to make that choice.

How the major AI builders tend to handle hosting location

This is general knowledge about how these platforms are commonly set up. Regions and options change, so use this to know what to look for, then confirm in your own account.

Lovable builds apps that typically use a backend-as-a-service platform for the database. That platform lets you pick a region when you create a project, including several in the EU (Frankfurt, Ireland, London). The catch is that the region is chosen at project creation and isn’t trivially changed later, so an app created without thinking about it may sit in a US region.
Apps on a backend-as-a-service platform generally (many AI builders lean on one) inherit whatever region the underlying project uses. The database location is a property of that project, so that’s where to check.
v0 and similar platforms run on usage-based hosting with a global edge network. Your app’s compute can run in many locations, and any attached database (Postgres, KV, blob storage) has its own region setting. The default region for a new database is often a US East location unless you pick otherwise.
Replit hosts on its own infrastructure, historically US-centric. If your app stores data in a Replit-managed database, assume US unless the product documentation for your specific plan says otherwise.
Bolt and similar browser-based builders usually connect to a backend you choose (often a backend-as-a-service platform again), so the residency question rolls back to that backend’s region.
A NoSQL backend-as-a-service platform lets you choose a location when you create the database, and some of those are in the EU, but the choice is permanent once set, and older or default projects frequently sit in the US (us-central).

The pattern across all of them: the platform gives you a choice, the default is often US, and the choice is frequently locked in at creation. So the important moment already passed when the project was created. Your job now is to find out what was chosen.

How to check where your app’s data actually sits

You don’t need to trust a general article. Check your own setup:

Find the database. Identify what your app uses to store data: a backend-as-a-service project, a NoSQL backend-as-a-service project, a Postgres instance, a usage-based hosting platform’s storage product. This is where personal data lives, not the front-end host.
Open the region setting. In a backend-as-a-service platform it’s under the project’s general settings, shown as a region like us-east-1 or eu-central-1. In a NoSQL backend-as-a-service platform it’s the database location. In usage-based hosting storage it’s listed per store. Write down the exact region.
Translate the region code to a country. eu- prefixes and cities like Frankfurt, Ireland, London mean EU or UK. us-, ap-, and similar mean outside the EU. If it’s outside, you have a transfer to account for.
Check for a transfer mechanism. If data is outside the UK/EU, look at the provider’s DPA for Standard Contractual Clauses or a Data Privacy Framework certification. That’s what makes the transfer lawful. No mechanism plus non-EU data is the gap.
Check your backups too. Data residency includes backups. A database in Frankfurt with backups copied to a US bucket has a US transfer hiding in the backup pipeline. Find out where backups are stored.
Write it down. The output of this exercise is one sentence per data store: “Customer data is in [region], backups in [region], transfer covered by [mechanism or ‘stays in EU’].” That sentence is what a security questionnaire wants.

What to do if your data is in the wrong place

If you find personal data in a US region and you’d rather it were in the EU, moving it usually means creating a new database in an EU region and migrating the data across, because most platforms lock the region after creation. That’s a real migration, not a settings toggle. It’s very doable, but plan it as a project with a maintenance window, not a five-minute change. Our post on when an app has outgrown its platform’s hosting covers the signals that it’s time to make that move.

Or, we do it for you

Figuring out where every piece of your app’s data lives, backups included, and moving it to EU hosting if it isn’t already there, is a standard part of what we do. We host customer apps on EU infrastructure (a VPS provider in Germany) with the residency question answered on day one. See our for-SME page.

FAQ

No. It’s allowed if you have a lawful transfer mechanism, most commonly Standard Contractual Clauses or the provider being certified under the EU-US Data Privacy Framework. What’s not allowed is moving data to the US with no mechanism at all and no record of the decision. The problem is usually missing paperwork, not the location itself.

My app is EU-based but uses a US analytics tool. Does that count?

Yes. Any third party that receives personal data, including an analytics or email provider, is a data transfer if it’s outside the EU. Each one needs its own lawful basis. Analytics tools are a common blind spot because they feel separate from “the database.”

Can I just move my backend-as-a-service project to an EU region?

Not directly. Most of these platforms set the region at project creation and don’t offer an in-place region change. Moving means creating a new EU project and migrating the data over. It’s a known, well-trodden migration, but it’s a migration, so plan for it.

Do backups need to be in the EU too?

If they contain personal data, yes, the same residency rules apply. A common oversight is an EU database whose backups get shipped to a US storage bucket. Check where backups land as carefully as where the live database sits.