EU hosting: what it actually means for compliance

Customers and partners ask more often where data lives than they did a few years ago. That is legitimate. Personal data in a SaaS, a customer portal or a marketing site is not "just content". It is orders, emails, identifiers, support threads and logs that can reconstruct a person.

The problem is that the conversation often collapses into a binary: Danish hosting or "US cloud". That is a bad map. A Danish vendor can still send backups to a US tool, let support log in from a third country, or use a CDN that caches pages with personal data. A US-owned platform can run compute and storage in the EU, have a DPA and a documented transfer mechanism — and still be the wrong choice if you mirror production into an analytics tool without a basis.

If you take the decision as a flag on a map, you build a system you cannot explain the day someone asks for documentation. If you take it as a data map — what you store, where it lives, who can open it — you can both pick a stack and sleep at night.

This is not legal advice. It is the engineering conversation you need before a lawyer can say anything useful. Without an honest map, the DPA is a document you sign without understanding.

Residency is the simple part: the bytes you call primary sit on disk in an EU region. Frankfurt, Amsterdam, Stockholm, Ireland. That is a real and often necessary choice. It is not the same as the processing being lawful, you having a legal basis, or nobody outside the EU being able to see the data.

GDPR asks first: what is the purpose, what is the basis, how long do you keep it, and can the person get access and erasure. A server in Herning does not help if you store more than you need, or if you cannot delete a user because backups are eternal and unlabelled.

Then come subprocessors. Your host is one processor. Analytics, email, error tracking, auth, payments, AI APIs and support tools are others. Each of them has their own sub-processors. "We host in the EU" is an incomplete answer if your error tracker sends stack traces with emails to a US SaaS without a DPA.

Finally there is access. A database in Frankfurt that a support engineer in a third country can open through an admin panel is still a transfer. So is a CI system that pulls production dumps, or a staging environment that is a copy of production. Those are the paths we see teams forget while they argue about the region dropdown.

First question: which personal data does the product process, and why? A marketing site with a contact form is a different problem from a customer portal with orders, documents and organisation members. If you cannot list the categories on one page, you are not ready to pick a host. You are ready to clean up scope.

Second question: where does the primary copy live, and where do the secondary ones live? Primary database, object storage, search index, logs, backups, CDN cache, preview databases. This is where "we run in the EU" often crumbles. The CDN caches HTML with names. The log platform lives in the US. The backup bucket was created in the wrong region because the default was us-east-1.

Third question: who can read data without going through your application? Platform support, your own ops team, an agency, an AI tool that receives dumps, a subprocessor with break-glass. If the answer is "we do not know", you have an access problem — not a hosting problem.

Once those three are answered, the stack choice becomes concrete. Then you can say: primary data in the EU, logs in the EU, no production dumps in CI, a DPA with named subprocessors, and support access only through your own IdP. That is a design. "Find a Danish host" is a hope.

A classic "Danish host" — managed VPS or a Danish datacentre — gives you a short contract and often support in Danish. That is right when the workload is simple and you control what leaves the box. It is wrong when you think the datacentre replaces DPAs on all the SaaS tools the app already uses. Hosting is one line. The product is ten.

AWS, GCP and Azure can run primary data in eu-central, eu-north or equivalent. You get region control, encryption, and a DPA you can point to. You also get a catalogue of services that default to global endpoints, and a support organisation that is global. That is defensible when you lock region, turn off accidental global features, and know how you handle a support escalation. It is indefensible when you click next in the wizard and assume an EU account means EU everything.

Vercel and Cloudflare are more often what a Next.js product actually runs on. Compute and edge are global or regional by product; storage and databases (Postgres, R2, KV, blob) can be placed in the EU. The right question is not "is Vercel legal in Denmark". The right question is: where does your database live, where do uploads live, what does the platform log, and which subprocessors sit in their DPA. A marketing site without accounts is a different risk picture from a SaaS with users.

Hybrid is what we most often recommend when the product is real: frontend and cache close to users, primary database and files in an EU region you can point to, and third-party tools chosen on purpose — not because they came in the starter template. The comparison between Vercel and Cloudflare is about operations and model, not a magic compliance stamp. Neither removes your duty to know your own subprocessors.