The essentials
Two cumulative conditions determine the real exposure of a backend: the location of the hosting AND the jurisdiction of the company that operates it. An American hyperscaler in the eu-west-1 region remains subject to the CLOUD Act. Aurabase documents both: verified production infrastructure in Germany and Finland, operated by Aurabase SAS, a company incorporated under French law.
GDPR and CLOUD Act: do not confuse the two regimes
The GDPR (EU Regulation 2016/679) governs the processing of personal data, regardless of the provider. The CLOUD Act is an American law that authorizes US federal authorities to request data held by a company incorporated under American law — even if this data is physically stored in Europe. These are two separate legal regimes, and confusing one with the other is the most costly mistake a CTO can make when evaluating a vendor.
A supplier can be perfectly compliant with the GDPR on paper (signed DPA, up-to-date processing register) while remaining exposed to the CLOUD Act if its parent company is American. Checking an “EU” region in a hosting panel only solves half the problem.
What GDPR actually requires from a backend
Beyond the general principle, four concrete obligations apply directly to the technical architecture of a backend: a legal basis for processing, the minimization of the data collected, the right to erasure (Art. 17) and the right to portability (Art. 20).
On a Postgres backend, these obligations translate into verifiable technical capabilities: Row Level Security makes it possible to restrict access to data to the strict necessary perimeter (minimization applied at the row level), and a standard pg_dump export covers portability — an open SQL format, not a proprietary export to be reconstructed.
The role of the DPA in the chain
The Data Processing Agreement (DPA) is the contract which legally governs your supplier as a subcontractor of personal data within the meaning of Art. 28 GDPR. It must exist, be dated, and list the supplier's subcontractors itself — without an up-to-date DPA, your own processing register (Art. 30) remains incomplete. See the Aurabase DPA page and the Aurabase GDPR page.
What non-compliance costs
Art. 83 GDPR provides for two levels of administrative fine: up to 10 million euros or 2% of global annual turnover for the least serious breaches (missing register, missing DPA), and up to 20 million euros or 4% of global turnover – whichever is greater – for violations of the fundamental principles of processing. This contractual risk weighs on the data controller, not only on its subcontractor: choosing a poorly documented backend provider remains your exposure, not theirs.
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) authorizes American judicial authorities to compel a company incorporated under American law to provide data that it holds or controls — wherever that data is physically hosted in the world. The scope is extraterritorial by construction: it is the nationality of the company which triggers the obligation, not the location of the data center.
Some of these requests are accompanied by a confidentiality clause (gag order) which prevents the company concerned from informing the end customer. It is this precise point – the absence of recourse or notification on the European client side – which distinguishes the CLOUD Act risk from a simple question of server location. For the complete decision grid applied to the choice of a BaaS, see our dedicated article: why the CLOUD Act changes the choice of your BaaS.
AWS, GCP, Azure in the EU region: an incomplete guarantee
Choosing a eu-west-1 (AWS), europe-west1 (GCP), or European Azure region reduces latency and meets data residency requirements — but does not change the nationality of the company operating these platforms. AWS, Google Cloud and Microsoft Azure remain companies under American law, subject to the CLOUD Act regardless of the region chosen by their customers.
The EU-USA Data Privacy Framework governs data transfers to certified American companies, replacing the Privacy Shield invalidated by the Court of Justice of the European Union (Schrems II judgment, 2020). This framework addresses the issue of transfer of data to the United States — it does not eliminate the CLOUD Act exposure of a U.S. company hosting data in the EU, which remains a separate jurisdictional subject.
This is not a questioning of the technical quality of American hyperscalers — it is a question of legal structure. A technically excellent service can remain legally exposed, and the two judgments are independent of each other.
What Aurabase checks and documents
The Aurabase production infrastructure is verified in Germany (Nuremberg, Falkenstein) and Finland (Helsinki), at Hetzner — no other locations are confirmed at this time. Aurabase SAS, the company which operates it, is a French company based in Paris.
A dedicated deployment environment at Scaleway (Paris region) exists in the Aurabase infrastructure repository, ready to be applied — but it is not, as of today, an active production deployment. To remain honest on this point: do not expect “France hosting” from Aurabase until this deployment is confirmed in production; the correct wording remains “EU sovereignty”, with the Scaleway Paris option available on request.
Checklist before signing with a backend provider
This checklist applies to any backend provider, including Aurabase — check each response on the provider's public compliance page rather than the sales promise in a sales email.
01Where are the production servers physically located?
Location alone is not enough, but it remains the first question to ask — demand a precise answer (country, host), not “in Europe”.
02What is the nationality of the company operating the service?
A company incorporated under American law remains subject to the CLOUD Act, even with servers in the EU. Check the head office and legal structure, not just the trademark.
03Is a DPA (Data Processing Agreement) available and up to date?
Mandatory as soon as a subcontractor processes personal data on your behalf (Art. 28 GDPR). Its absence or seniority is a warning signal.
04Are sub-processors publicly declared?
A serious supplier lists its own subcontractors (hosting provider, emailing service, etc.) — an absent or opaque list complicates your own Art register. 30.
05Which law governs the contract in the event of a dispute?
A contract subject to the law of a third country can complicate an appeal, even if the accommodation is in the EU.
06Does the supplier document a dedicated and dated compliance page?
A compliance page kept up to date is a more reliable signal of seriousness than an isolated mention on the home page.
To delve deeper into the associated technical security posture, see the Aurabase Security page.
Self-hosting vs EU sovereign BaaS: which option to choose?
An SME subject to the GDPR generally chooses between three options: build and host its own backend, use an American BaaS with an EU region option, or choose an end-to-end sovereign EU BaaS. Self-hosting gives maximum legal control but transfers all operational burden (security patches, backups, availability) to an internal team that must already exist.
An EU sovereign BaaS — infrastructure and parent company both in the EU — shifts this operational burden to the provider without reintroducing the CLOUD Act exposure of a US hyperscaler to the EU region. This is a relevant compromise for a team that does not have the capacity to maintain its infrastructure itself, without wanting to trade off its compliance against its product velocity.