Data residency for AI-generated websites in the EU: what actually sits where

"Where does the data live?" sounds like one question and is really two. One is legal: which country's laws govern the data. The other is physical: which machine, in which building, holds the actual bytes. The first is a matter of contracts and corporate jurisdiction. The second is a matter of geography you can literally point at on a map. This post is about the second one, residency in the concrete sense, applied to a site an AI built for you. Not the abstract layers of governance, which are covered separately in data sovereignty for AI-built websites, but the plain inventory: for each moving part of the site, where does the byte physically sit.

Follow one page load

The clearest way to find out what sits where is to trace a single visit. A person in Antwerp opens your AI-built site, and here is the chain of bytes that fires.

First, their browser asks DNS where your domain points. That query hits a nameserver, and the nameserver's location is the first residency fact, usually overlooked because DNS feels invisible. Then the browser connects to the host that serves your site and pulls the HTML, the stylesheet, the images, the scripts. Those files sit on a specific server in a specific data centre: residency fact two, and the one most hosts advertise. If the page loads a font, a map or a video from somewhere else, the browser fetches those too, from wherever those providers keep them: residency fact three, and the one AI tools quietly introduce. Finally, if the visitor submits the contact form, their message travels to whatever endpoint the form points at, and lands in whatever storage receives it: residency facts four and five.

A single page view has already touched five physically distinct locations. "The site is hosted in the EU" describes at most one of them.

The inventory, part by part

Broken out, an AI-generated site has these physical residency points, and each deserves a straight answer rather than a shrug:

• The served files. The HTML and assets a visitor downloads. This is the layer everyone checks. It is also the easiest to get right and the least likely to be the problem.
• The account and deploy data. Your login, your site's configuration, the record of every deploy. This lives in a database, and that database sits on a machine somewhere. On several large platforms the files sit on EU edge nodes while this database runs on another continent.
• The build pipeline. If your site is built from source rather than served as-is, the build runs on a machine that briefly holds all your code. Where that build machine lives is a residency point people forget entirely because it is transient.
• The snapshots and backups. Every previous version of the site, captured and stored. Backups are data too, and a backup restored from another jurisdiction is data that left and came back.
• The logs. Access logs and error logs contain visitor IP addresses, which are personal data. Where logs are stored and for how long is a real residency question, not an operational footnote.
• Form submissions. The actual personal data visitors type. AI tools routinely wire generated forms to a handler the model knew about, which is frequently not in the EU.
• Analytics. Same story: a tracking snippet included by default puts every visitor IP into a provider's storage, wherever that provider keeps it.

A residency review that stops at the first bullet has checked the one point least likely to leak and skipped the six where AI defaults most often send data elsewhere.

The one flow that legitimately leaves

Here is the honest exception, and it matters because pretending otherwise would be dishonest. For an AI-generated site, the generation step itself usually runs on a model provider's infrastructure, and the largest ones are outside the EU. When you describe your site to an assistant, that prompt goes to wherever the model runs.

This is fine, and it is worth being clear about why. What travels during generation is your instructions and the resulting code, not your visitors' personal data. No customer email, no visitor IP, nothing a person entrusted to your site is involved at build time, because there are no visitors yet. Residency is about where your operational data lives once the site is running and real people are using it. The build-time trip to a model provider is a separate event that touches none of that. So the sensible posture is precise rather than absolute: the generation can happen anywhere, and everything the running site does with real people's data stays in the EU. Conflating the two leads people to either fret about the wrong thing or wave the whole question away.

How to verify without taking anyone's word

Residency claims are checkable, and vague answers should be treated as failed checks.

1. Open your live site's source and list every external hostname. Each script, font, image or form action pointing at a domain that is not yours is a byte flow to account for. This is a ten-minute job and it finds the analytics and form leaks immediately.
2. Ask your host, in writing, where each part runs, not just the files. Files, database, build machine, backups and logs, itemised. A host that can answer per component is a host that thought about it. A host that answers only "our servers are in Europe" has answered one bullet of seven.
3. Check for a Data Processing Agreement and a subprocessor list. Any layer touching personal data should be covered by a DPA, and the subprocessors should be named. If you cannot get the list, you cannot know where the data goes.

Whatever the audit finds, fix the forms and analytics first. They are the two points where real visitor data flows today, and they are the two AI tooling most often sends abroad by default.

What actually sits where on VibeDeploy

VibeDeploy is built so the inventory has one answer. The operating company is Serso BV, a Belgian entity, and every physical point above sits inside the EU: served files, account and deploy database, build pipeline, snapshots, and logs all run from EU data centres. Contact forms deliver through a built-in relay on that same infrastructure, so no external form handler enters the map, and analytics are first-party and privacy-preserving, with hashed IPs, so there is no third-party analytics store to place at all. The only flow that ever leaves is the generation step, which is your choice of AI tool and which never sees a visitor's data. The DPA is public and the subprocessor list is published alongside it, so the verification steps above resolve to reading two pages rather than chasing a sales rep.

Pricing is flat rather than metered, starting at 15 euro per month with a 14-day trial and no card up front, on the pricing page. If your project is still on localhost, the path onto this infrastructure is in deploy localhost to production, and once it is live, the reversibility layer that keeps every version inside the same jurisdiction is in deploying AI-built sites to EU infrastructure. Residency for an AI-built site is not a mystery. It is an inventory with a fixed number of rows, and every row has a place you can name.