Regions and data residency: does it matter where your site is hosted?
For public pages the server's location barely matters. For the data behind them it can matter a great deal. How to tell which case you are in.
The short answer
Where your website is hosted matters far less than it used to for visitors and far more than is realised for data. The public pages are copied to a content delivery network and served from near every visitor, so an origin in one country serves Europe, Asia and America quickly alike. The data behind the site, form submissions, customer records, databases, backups, logs, is different: legal and contractual obligations attach to where it is stored and who can reach it. Ask the two questions separately. The first is a performance detail. The second is a compliance decision, and it deserves a deliberate answer written down.
The two questions
| Question | What it covers | How much it matters | Who decides |
|---|---|---|---|
| Where are pages served from? | Static HTML, images, scripts, styles | Little, with a CDN in front | Performance; usually automatic |
| Where does data live? | Form submissions, databases, functions that process personal data, backups, logs, email sending | A great deal for personal, financial or health data | You, with legal advice, written into documentation |
Mapping where your data goes
- List every place data enters: forms, logins, uploads, checkout, API calls.
- Follow each path: which function handles it, in what region; which service receives it; where that service stores it; who else gets a copy.
- Add the quiet places: logs, error tracking, analytics, backups, email delivery providers.
- Mark each hop with a jurisdiction and a processor agreement, or the absence of one.
- Decide per hop: keep, move to an appropriate region, or remove the hop entirely by collecting less.
- Write it into the setup document so the next person does not have to rediscover it.
Choosing regions on a modern platform
Static assets: leave to the CDN. Functions: pin to the region nearest your users and inside the required jurisdiction; do not leave them on a default in another continent. Databases: same region as the functions, both for latency and for residency. Backups: a different location for resilience, but within the same jurisdiction where residency applies. Third-party services: check where each stores data and whether a regional option exists; prefer services that offer one.
What this means for you
Stop worrying about where the server is for your pages; the CDN has solved that. Start caring about where your data goes: forms, databases, backups, logs, email. Map the path, choose regions deliberately for the dynamic pieces, remove hops that collect more than you need, and write the result down. Location alone does not make you compliant, but an undocumented path almost certainly makes you non-compliant somewhere.
Frequently asked questions
Our visitors are in Europe. Should the server be in Europe?
For the static pages, the CDN already serves them from Europe wherever the origin is. For anything dynamic, functions and databases, a European region reduces latency and simplifies compliance. Modern platforms let you choose the region for those pieces; choose the one nearest your users and within the jurisdiction your obligations require.
Does hosting in the EU make us GDPR compliant?
No. Location is one factor among many. Compliance is about lawful basis, data minimisation, security, processor agreements, retention and rights handling, wherever the data sits. EU hosting removes some complexity around transfers; it does not replace the rest. Check with a privacy specialist for your situation.
Where do form submissions actually go?
Often further than people think: through a function in one region, to an email provider in another, into a CRM hosted somewhere else, with a copy in a form service's logs. Map the path once, and decide deliberately for each hop. It is usually a short list, and it is usually undocumented.
Sources
- Vercel documentation: Regions (accessed 2026-09-11)