EU Hosting for Developers: Data Residency, GDPR, and DPAs in Practice

It usually starts with a single question. A prospective customer, halfway through a security review, asks where their users' data is stored. Or a deal you thought was closed goes quiet because their legal team wants a Data Processing Agreement before signing. Or you read the words "data controller" in a support ticket and realize you're not entirely sure which one you are. Up to that point, "we host in Europe" felt like enough. It rarely is, and the gap between that phrase and what it actually requires is where a lot of small teams get caught.

This is the practical version, written for the person who has to configure the infrastructure rather than the person who writes the privacy policy. It covers what EU hosting really means, the GDPR concepts you can't avoid as a developer, why a DPA matters and shouldn't cost you a sales call, and how to assemble a stack that keeps data on EU soil without surprises. None of it is legal advice, but all of it is the groundwork that makes the legal advice cheap.

What "EU hosting" actually means (and what it doesn't)

The phrase gets used loosely, so it's worth pinning down. EU hosting means your data is physically stored and processed on servers located inside the European Union, and that it stays there. That second half is the part people skip. A provider that lets you pick a Frankfurt region for your primary database has met the first half. If that same provider replicates backups to Virginia for durability, caches responses at edge nodes outside the EU, or routes logs through a US analytics pipeline, your data has left the EU regardless of where the main server sits.

So the useful test isn't "can I choose an EU region?" Almost every large platform offers one. It's "does every copy of my data, including backups, logs, and derived data, stay in the EU by default, without me having to audit each feature?" A US-headquartered platform with an EU region has bolted European hosting onto a fundamentally global architecture. It can work, but the burden is on you to find every place data might leak out and lock it down. An EU-native platform inverts that: EU residency is the default and staying inside the border is the path of least resistance, not the thing you have to fight for.

Data residency, data sovereignty, and why the difference matters

Two terms get used interchangeably and shouldn't be. Data residency is about location: where the bytes physically live. Data sovereignty is about jurisdiction: whose laws can reach those bytes. You can have the first without the second, and that gap is the whole reason this topic is more than a checkbox.

Here's the concrete version. A US-owned cloud provider stores your data in its Frankfurt region. Residency: satisfied, the data sits in Germany. But under the US CLOUD Act, a US company can be compelled to hand over data it controls no matter where in the world that data sits. So the data resides in the EU while remaining reachable by a non-EU jurisdiction. That's residency without sovereignty, and it's exactly the tension the Schrems II ruling put a spotlight on when it struck down the Privacy Shield framework in 2020.

None of this makes a US-owned provider illegal to use. Transfers like these are meant to be covered by a legal mechanism, today the EU-US Data Privacy Framework and Standard Contractual Clauses before it, and plenty of compliant companies rely on exactly that. The catch is that this is the same class of mechanism that has already been struck down twice, first Safe Harbor, then Privacy Shield, so a stack built on it depends on an adequacy decision that has a history of not holding. Keeping data on infrastructure that's both located in and operated within the EU sidesteps the question: there's no cross-border transfer to justify in the first place, and one fewer legal assumption that can change under you.

GDPR in one page, for developers

You don't need to memorize the regulation, but you do need two concepts, because they decide what your obligations are and who carries them.

The first is the split between a data controller and a data processor. The controller decides why and how personal data is processed; the processor acts on the controller's instructions. If you run a SaaS app that collects user data, you are the controller for your users' data. Your hosting provider, which stores and processes that data on your behalf, is your processor. This isn't a label you get to choose; it follows from what you actually do, and it matters because GDPR assigns different duties to each. As the controller, you're accountable for the whole chain, including your processors.

The second concept is personal data itself, which is broader than most developers assume. It's not just names and emails. IP addresses, cookie identifiers, device IDs, and user-generated content all count. That matters because personal data hides in places you don't think of as a "database": your application logs, your error-tracking tool, your email delivery records, your object storage. If a system touches any of those, it's in scope, and "the main database is in the EU" doesn't cover it.

• You (the app) are the controller — accountable for lawful basis, user rights, and choosing compliant processors.
• Your host is a processor — must process data only on your instructions and protect it, formalized through a contract.
• Personal data is everywhere — logs, backups, caches, email records, and uploads all count, not just the users table.

The DPA: the contract that makes your host legal to use

A Data Processing Agreement is the contract that binds your processor to GDPR's requirements. Article 28 of the GDPR is explicit: if you use a processor, the relationship must be governed by a contract that sets out what data is processed, for what purpose, for how long, and the security measures around it. In plain terms, if your hosting provider handles personal data for you and there's no DPA in place, you, as the controller, are not compliant. That isn't optional paperwork. The contract is what makes using the provider allowed at all.

This is where a lot of developer-focused platforms quietly fail their smaller customers. The DPA exists, but it's gated behind an enterprise plan, a sales conversation, or a manual request that takes a week. For a solo founder or a small team, that turns a legal necessity into a procurement obstacle, and plenty of people ship without one simply because getting it was too much friction. That's the wrong default. A DPA costs the provider nothing to include, and every customer handling EU data needs one, so it should come standard.

On Runsite, a signed GDPR Data Processing Agreement is included on every plan: no upgrade, no negotiation, no sales call. It's part of the account by default, which means the moment you need to answer that security-review question, the answer is already in place rather than a two-week detour.

What actually has to stay in the EU

"Keep data in the EU" is easy to say and easy to violate in pieces, because a real application is more than one service and each piece stores data somewhere. Here's the full surface area to account for, because a stack is only as EU-resident as its leakiest component:

• Application runtime — the containers running your code, plus their environment variables and in-memory state. Personal data flows through here on every request.
• The database — the obvious one, but with a catch: its backups and point-in-time-recovery snapshots have to stay in-region too, and they're frequently the part that leaks.
• Object storage — user uploads, exports, and generated files, which almost always contain personal data.
• Caches and sessions — a session store holds tokens and user identifiers; a cache can hold anything you put in it.
• Logs and derived data — access logs with IP addresses, error traces with request payloads, email delivery records. Personal data by GDPR's definition, and easy to forget.

Building an EU-only stack

The clean way to handle all of that is to run the whole stack in one EU region on infrastructure operated by an EU entity, so residency is the default for every layer rather than a setting you toggle per service. On Runsite everything runs in Frankfurt, Germany, and nothing falls back to non-EU infrastructure. Here's how the pieces map to the surface area above.

Your web services and static sites run their containers and store their build artifacts, environment variables, and logs in the EU. For static sites, public assets are cached at edge locations worldwide for speed, but the source of truth (your build output) stays in Frankfurt. The edge holds public files, not your private data.

Your managed PostgreSQL keeps the database, its WAL archive, and every automated backup in the same region, so a point-in-time restore never pulls data across a non-EU boundary. The backup leak described above simply can't happen here. Redis holds your cached data and user sessions in the EU, which matters precisely because session stores are full of tokens and identifiers. Object storage keeps every uploaded object in Frankfurt, encrypted at rest with AES-256, with no replication to non-EU regions.

The pieces that run on their own schedule stay inside the border too. Cron jobs execute in the EU, so whatever rows or files they touch are processed there, and their logs are stored there. Even transactional email, which quietly carries personal data in every authentication and billing message, is accepted, signed, queued, and delivered from the EU, with message bodies retained only briefly for troubleshooting. Assemble those and you have a stack where the honest answer to "where does our data live?" is a single region, not a spreadsheet of per-service exceptions.

The traps that leak data out of the EU

Most residency failures aren't dramatic. They're a default setting nobody changed, on a platform designed for a global footprint. These are the ones worth checking on any stack:

• Backups in a different region. The database is in the EU; its backups replicate to a US region for durability. This is the single most common leak, because it's a default that's invisible until you go looking.
• Edge caches holding private responses. A CDN that caches personalized API responses — not just public assets — is storing personal data at edge nodes that may sit anywhere in the world.
• Third-party subprocessors. Your error tracker, analytics, or email sender may forward data to the US. Each one is a subprocessor you're responsible for, even though it's not "your" server.
• A US parent company. Even with EU servers, a US-owned provider is reachable under the CLOUD Act — the residency-without-sovereignty gap. For some buyers this alone is disqualifying.
• Logs shipped elsewhere. Access and error logs full of IP addresses routed to a non-EU logging service is personal data crossing the border through the back door.

The short version

EU hosting means more than a region dropdown. It's the guarantee that every copy of your data (runtime, database, backups, storage, caches, logs, email) stays inside the EU, on infrastructure a non-EU jurisdiction can't reach into. Under GDPR you're the controller and your host is your processor, which means you need a DPA in place and you're accountable for every place personal data lands. The way to make that manageable is to stop treating residency as a per-service setting to police and run the whole stack in one EU region by default, with the DPA already signed. Deploy your app on EU infrastructure that keeps data in Frankfurt with a GDPR DPA on every plan, and the next time someone asks where your data lives, you'll have a one-word answer.