Sovereignty
The US CLOUD Act explained for Laravel developers
What the US CLOUD Act of 2018 says, why an EU region of an American cloud is not sovereign, and what it means for Laravel teams and their clients.
In this post
When a client asks whether their Laravel app is "sovereign", the conversation usually ends up at one US law: the CLOUD Act. It explains why "we host in Frankfurt" is not a complete answer, and why the owner of your cloud matters as much as its address.
This article explains what the CLOUD Act is, what it does and does not do, and what it means for the way you host a Laravel app. It is general background for developers, not legal advice.
What is the US CLOUD Act?
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a US federal law passed in March 2018. It requires providers of communication and cloud services under US jurisdiction to hand over data in their "possession, custody, or control" when served with a valid US warrant or order, no matter where in the world that data is stored. The location of the server does not decide whether the law applies; control over the data does.
Where it came from
Before 2018, US law enforcement used the Stored Communications Act to ask providers for data such as email. In the Microsoft Ireland case, Microsoft refused to hand over mailbox contents stored in a data centre in Dublin, arguing that a US warrant did not reach data stored abroad. The case went up to the US Supreme Court.
Congress answered before the court did. The CLOUD Act added a rule to the Stored Communications Act that a provider must disclose data it controls "regardless of whether" it is located inside or outside the United States. The Supreme Court then dismissed the Microsoft case as moot.
The Act did two more things:
- It created a way for the US to sign executive agreements with other countries, so that their authorities can ask US providers for data directly, and the other way round.
- It gave providers a limited way to challenge an order, mainly when the customer is not a US person and the order would conflict with the law of a country that has such an agreement with the US.
Why an EU region is not enough
The big American clouds all offer European regions: Frankfurt, Dublin, Paris, Amsterdam. Your database can sit in one of them, and your data stays physically in the EU. For latency and for many GDPR questions, that is useful.
For the CLOUD Act, it changes little. The provider running that region is a US company, or is controlled by one. If a US authority serves it with a valid order for your data, the fact that the disk is in Frankfurt does not by itself stop the order. The provider can challenge it in the cases the law allows, but the decision is not yours, and you may not be told.
| Setup | Data in the EU | Provider under US jurisdiction | Reachable through a CLOUD Act order |
|---|---|---|---|
| US cloud, US region | No | Yes | Yes |
| US cloud, EU region | Yes | Yes | Yes |
| European cloud, EU region | Yes | No, unless it has a US presence that brings it under US jurisdiction | Far less likely |
That is the core of the argument the EU-sovereign hosting guide builds on: sovereignty is about three things, where the data is, who owns the provider and who holds the contract. A European region only answers the first.
Note
The CLOUD Act is about law enforcement requests. US intelligence surveillance, such as under Section 702 of FISA, is a separate legal basis with its own rules. Both point at the same practical question: is the company holding your data subject to US law?
How it collides with the GDPR
The GDPR has its own rule for this situation. Article 48 says that a court judgment or authority decision from a country outside the EU, requiring a controller or processor to transfer personal data, is only recognised or enforceable in the EU when it is based on an international agreement, such as a mutual legal assistance treaty.
So a US provider holding EU personal data can be caught between two laws: US law that requires disclosure, and EU law that does not recognise the order as a basis for it. How that conflict plays out in a particular case is a legal question, and the details depend on the facts. For you as a developer, the useful conclusion is simpler: when you pick a provider that has to answer to both, you accept that this conflict can land on your data.
What about the Data Privacy Framework?
The EU-US Data Privacy Framework, adopted in 2023, is an adequacy decision: it allows personal data to be transferred from the EU to US companies that certify under it, without extra safeguards for each transfer. It was built in response to concerns about US surveillance.
It does not repeal or limit the CLOUD Act. A certified US provider is still a US provider. The framework makes a transfer lawful under the GDPR; it does not change what US authorities can require of the company that holds the data. Its two predecessors, Safe Harbor and Privacy Shield, were both struck down by the EU Court of Justice, and the current one has been challenged as well. Many teams therefore prefer an architecture that does not depend on it.
What it means for a Laravel app
Every part of a Laravel app that holds or sees data counts, not just the server. Go through your stack and ask, for each part: is the company that runs it subject to US jurisdiction?
| Part of the app | Typical data | Question to ask |
|---|---|---|
| Runtime and database | Everything | Who owns the cloud? |
| File storage | Uploads, invoices, exports | Who owns the bucket's provider? |
| Queue | Job payloads | Same provider as the app? |
| Secrets | APP_KEY, database password, API keys |
Where does the secret store run, and who can read it? |
| CDN and DNS | Every visitor's request and IP address | Who owns the edge? |
| Deploy tool | Your code, your secrets, keys to your cloud | Does it sit in the request path, or keep your secrets? |
| Mail, payments, errors, analytics | Names, addresses, request data | Who owns each service? |
A Laravel app on a European cloud that sends every exception, with the request attached, to an American error tracker has moved that data back into reach. The EU-sovereignty checklist turns this table into one page you can hand to a client.
Tip
Grep your
config/services.php,config/logging.phpand.env.examplefor API hosts and SDKs. That list is your first draft of who sees your data.
What it means for your clients
If you build Laravel apps for clients, they are usually the controller of the personal data in them, and they carry the responsibility under the GDPR. More of them are asking where their data lives and who could be made to hand it over: public bodies, healthcare, education, legal and financial services in particular.
Answering honestly means listing the providers, where each one stores the data, which country each company is in, and the exceptions you know about. "Hosted in the EU" is true for many setups; "out of reach of US law" is a much stronger claim, and only holds when every provider in the list is European-owned. The GDPR and hosting post covers the contracts you need along the way.
How Brewless fits in
Brewless runs Laravel apps on Scaleway (France) with bunny.net (Slovenia) in front, both European companies with headquarters in the EU. The accounts are yours, so the contracts with both providers are in your name. Brewless itself is Dutch, hosted at Scaleway in Paris, and is not in the path of your visitors' traffic. It keeps the names and revisions of your environment variables, not their values; those stay in your own Secret Manager. See how Brewless works for exactly what it records.
That covers the hosting. What your app calls is still up to you, and the European alternatives post lists options for the usual services.
Summary
- The CLOUD Act (2018) lets US authorities require US providers to hand over data they control, wherever it is stored.
- An EU region of a US cloud keeps data in the EU but leaves it within reach of a US order.
- The GDPR (Article 48) does not recognise such an order on its own, which puts US providers between two laws.
- The Data Privacy Framework makes transfers lawful under the GDPR; it does not change the CLOUD Act.
- For a Laravel app, check the owner of every part that holds or sees data, not only the server.
This is general background, not legal advice. For a specific contract or app, talk to a lawyer who knows data protection.
Frequently asked questions
What is the US CLOUD Act?
The Clarifying Lawful Overseas Use of Data Act is a US federal law from March 2018. It says that a provider of communication or cloud services under US jurisdiction must hand over data in its possession, custody or control when served with a valid US warrant or order, regardless of whether that data is stored in the US or abroad.
Does the CLOUD Act apply to an AWS, Azure or Google Cloud region in Frankfurt?
Yes, as far as the data is controlled by the US company that runs it. The location of the data centre does not decide whether the law applies; the provider's control over the data does. That is why an EU region of an American cloud is not the same as a European provider.
Does the EU-US Data Privacy Framework solve the CLOUD Act problem?
No. The Data Privacy Framework is an adequacy decision for transferring personal data from the EU to certified US companies. It does not change what US law can require of those companies, so data held by a US provider stays within reach of a CLOUD Act order.
Is a European provider completely out of reach of US law?
Not automatically. A European company with a US subsidiary or substantial business in the US can face questions about US jurisdiction too. A provider owned and headquartered in the EU, without that US exposure, is far less likely to be compelled under the CLOUD Act.
Is this legal advice?
No. This article is general background for developers. For a decision about your own app or a client contract, ask a lawyer who knows data protection and the jurisdictions involved.