An EU-sovereignty checklist for a Laravel SaaS

Sooner or later a client, a tender or a data protection officer asks for it in writing: which parties see our data, where, and under which law? A sentence like "hosted in the EU" does not answer that. A table does.

This post is that table, for a typical Laravel SaaS. Copy it, fill it in for your app, and hand it over. It builds on How to host a Laravel app EU-sovereign, which explains the setup; this one is about writing it down.

What does an EU-sovereignty checklist need to show?#

For every part of your app that holds or sees data, it needs three facts: where the data is stored, which company runs that part, and in which country that company is headquartered. Add the exceptions you know about. That is enough for a DPO to judge the setup, and it is honest about the parts you cannot control.

The reason ownership matters, and not just location, is the US CLOUD Act: a US provider can be required to hand over data it controls, wherever that data is stored. The CLOUD Act explained covers that in detail.

How to fill it in#

Start from the code, not from memory:

# Every outside service your app talks to
grep -rhoE "https?://[a-z0-9.-]+" config/ app/ | sort -u
grep -E "^[A-Z_]+_(KEY|SECRET|TOKEN|DSN|URL)=" .env.example
composer show --direct

Every SDK in composer.json, every host in config/services.php and every DSN in .env.example is a candidate row. Then add what does not show up in code: where builds run, where secrets are stored, and the tools your team uses.

The checklist#

Leave nothing blank. "Not used" is a valid answer; an empty cell is not.

Notes per row#

1–5. Runtime, database, files, queue, cache. Keep them at one provider, in one region, so data does not cross between companies on its way from the web container to the database. On serverless, sessions and cache belong in the database or a cache service, since the container's disk does not outlive it.

6. Secrets. Ask where the values are stored and who can read them. A deploy tool that keeps a copy of your .env is a party that holds your database password.

7. Builds. A build sees your full source code and often build-time secrets. Hosted CI and hosted build servers count as a party here, with their own owner and location.

8. CDN, DNS, firewall. The edge sees every request before your app does, including IP addresses and often cookies. Check where the edge locations are, whether they can be limited to Europe, and where DNS is answered.

9. Deploy tool. It holds keys to your cloud. Check whether it sits in the request path, whether it stores secret values and logs, and what happens to your app if you stop using it.

10–14. Mail, payments, errors, logs, analytics. These often carry the most personal data per request. Error trackers in particular receive request bodies, headers and user IDs by default. See European alternatives for the services a Laravel app calls.

15. Fonts and scripts. Each external font or script sends the visitor's IP address to whoever serves it. Self-host them through Vite and the row is answered.

16–17. Support and team tools. These are about your organisation, not the app's runtime. List them separately so the reader can see the difference, but list them.

Warning

Do not mark a row as sovereign because the data centre is in the EU. The "Company HQ" column is the one that answers the CLOUD Act question.

An example, filled in#

This is the hosting part for a Laravel app deployed with Brewless, as described in the Brewless documentation:

And the notes that belong with it:

• Brewless is not in the path of visitor traffic: requests go from bunny.net straight to your containers.
• Brewless keeps the names and revisions of your environment variables, not their values. Logs are read live from Scaleway and not stored by Brewless.
• bunny.net answers DNS lookups from its worldwide network and uses a few US-based tools for its own support and email, which see account details, not your visitors' traffic.
• Queues are not available in Warsaw or Milan yet, and file storage is not yet in Milan, so check the regions before you pick one.

Rows 10 to 17 depend on your app and your team, and Brewless does not answer them.

Tip

Put the filled-in checklist in your repository, next to brewless.yml. A pull request that adds a new SDK is then the natural moment to add a row.

What to hand over#

A one-page document with:

1. The filled-in table.
2. The exceptions, each in one sentence: what data, which provider, which country, and why you accept it.
3. The data processing agreements you hold, and with whom. GDPR and your hosting stack explains which ones those are.
4. The date, and who is responsible for keeping it current.

A DPO can work with a short list of known exceptions. What they cannot work with is a claim of full sovereignty that turns out not to hold the first time someone looks at config/services.php.

Summary#

• List every part that holds or sees data, from runtime to team tools.
• For each, write down location, operator, company headquarters and who holds the contract.
• Build the list from the code: SDKs, hosts and DSNs.
• Write the exceptions down instead of leaving them out.
• Keep it in the repository and update it with every new outside service.