Sovereignty
GDPR roles and DPAs when you host Laravel with Brewless
Who is controller, processor and sub-processor when a Laravel app runs on Scaleway and bunny.net through Brewless, and which data processing agreements to sign.
In this post
- Who is controller and who is processor when you host Laravel with Brewless?
- The roles in one minute
- How the Brewless setup splits the data
- The roles, per party
- What Brewless can come across
- Which DPAs you need
- What the Brewless DPA says, in short
- When you are an agency
- In your records of processing
- Summary
A European host is only half of a GDPR answer. The other half is paperwork: who is responsible for which data, and which contracts say so. A DPO will ask for both.
This post maps the GDPR roles for a Laravel app hosted with Brewless on Scaleway and bunny.net, and lists the data processing agreements you need. It is general information, not legal advice.
Who is controller and who is processor when you host Laravel with Brewless?
The business that runs the app is the controller for its users' personal data. Scaleway and bunny.net are that business's processors, under contracts it holds directly. Brewless is a processor only for the personal data it can come across while working on its instruction, and a controller for the account data of the team that uses it.
The roles in one minute
The GDPR distinguishes two roles that matter here:
- Controller: decides why and how personal data is processed. Responsible towards the people the data is about.
- Processor: processes personal data on behalf of a controller, following its instructions. Needs a contract with the controller that meets Article 28, usually called a data processing agreement (DPA).
A processor that hires another processor for the same data makes that one a sub-processor, with the controller's permission and the same obligations passed down.
Which role a company has follows from what it actually does with the data, not from what a contract calls it.
How the Brewless setup splits the data
Brewless deploys into accounts you own. That splits the personal data into two kinds, as the privacy statement describes:
Your app's data. The database, files, queue, logs and visitor traffic live in your Scaleway project and your bunny.net account. Visitor traffic goes from bunny.net straight to your containers; Brewless is not in that path and keeps no copy of your app's data.
Data Brewless holds itself. Your team's accounts, sign-ins, the audit trail, provider keys (stored encrypted), billing details and the names of your variables. Not the values: those stay in your own Secret Manager.
The roles, per party
| Party | Role for your app's users' data | Role for your team's account data | Contract |
|---|---|---|---|
| You (the business running the app) | Controller | Your team are the data subjects | — |
| Scaleway (France) | Your processor | — | Directly with you |
| bunny.net (Slovenia) | Your processor | — | Directly with you |
| Brewless (Coding Agency, the Netherlands) | Your processor, for what it comes across on your instruction | Controller | Brewless terms, with the DPA as part of them |
| Brewless's own providers | Sub-processors of Brewless | Processors of Brewless | Between them and Brewless |
The important line is the second and third: because the Scaleway project and the bunny.net account are yours, those providers are not sub-processors of Brewless. The data processing agreement says so explicitly: you have your own agreements with them.
What Brewless can come across
Brewless can reach your accounts with the keys you connect, and a few things it does there on your instruction can touch personal data. The data processing agreement lists them:
| What you ask | What Brewless can come across | What Brewless keeps |
|---|---|---|
| Show the logs of an environment | Log lines, which may hold personal data | Nothing; they are read from Scaleway and shown |
| Run a one-off command | Whatever the command prints | Which command ran and who ran it; not its arguments or output |
| See, change or push variables | The values, on their way from or to your Secret Manager | Names and a checksum, never a value |
| Deploy, roll back, scale, add a domain | The configuration of your resources | References and settings, no app data |
So the processing is reading and passing on, for as long as you use Brewless. What personal data that involves depends on what your app logs and prints, which you decide.
Tip
The less personal data your app writes to its logs, the less any tool that shows those logs can come across. Log IDs, not email addresses.
Which DPAs you need
For a Laravel app hosted with Brewless, the minimum is three:
- Scaleway. Your processor for the runtime, database, files, queue, secrets and builds. Scaleway offers a DPA for its customers; conclude it under your own account.
- bunny.net. Your processor for DNS, CDN, certificates and Shield, which see every visitor's request. bunny.net offers a DPA as well; conclude it under the account you connected.
- Brewless. Its data processing agreement is part of the terms of service, so it applies once you use Brewless.
Then one for every other service your app sends personal data to: mail, payments, error tracking, analytics, SMS. The European alternatives post lists options for each, and the EU-sovereignty checklist has a column for who holds each contract.
Note
Check how each provider's DPA is concluded. Some apply automatically with the terms, others have to be accepted or signed in the account settings. Keep a copy, with its date, with your records.
What the Brewless DPA says, in short
- Brewless handles your app's personal data only to do what you instruct through the console, the command line client or the API.
- It handles that data inside the European Economic Area only.
- Its own sub-processors are listed in the privacy statement, all established in the European Union. Brewless tells you by mail at least 30 days before adding or replacing one, so you can object.
- A data breach involving data it handles for you is reported without undue delay, and at the latest within 48 hours after Brewless found out.
- It helps you answer requests from people about their data, as far as what it can see and do allows.
- When you stop, your app's data was never with Brewless and stays in your accounts. Disconnecting a provider removes its key from Brewless at once.
When you are an agency
Agencies often host apps for clients. Then there is one more layer:
- The client is usually the controller.
- The agency is their processor, and needs a DPA with the client.
- Where the provider accounts are matters:
- Accounts in the client's name. Brewless can connect a Scaleway project in a client's own account. The client then holds the contract and DPA with Scaleway directly, and with bunny.net when the bunny.net account you connect is the client's too. The agency and Brewless remain processors for what they do on instruction.
- Accounts in the agency's name. Scaleway, bunny.net and Brewless are then sub-processors of the agency, and the client should know and agree to them.
The first option keeps the contracts with the party that owns the data, and lets the client keep the app running if the agency relationship ends. See Connecting providers for how several projects are connected.
In your records of processing
Your Article 30 record of processing should name each processor. For the hosting part, that is:
| Processor | Purpose | Location | DPA |
|---|---|---|---|
| Scaleway SAS | Hosting of the app, database, files, queue, secrets, builds | Region you chose: France, the Netherlands, Poland or Italy | With Scaleway |
| BunnyWay d.o.o. (bunny.net) | DNS, CDN, TLS, firewall | Slovenia; edge locations as configured | With bunny.net |
| Coding Agency (Brewless) | Deploying and operating the app on instruction | European Economic Area | Brewless terms |
Summary
- You are the controller for your app's users' data.
- Scaleway and bunny.net are your processors, under your own contracts; they are not Brewless's sub-processors.
- Brewless is a processor for what it comes across on your instruction, with a DPA in its terms, and a controller for your team's account data.
- You need DPAs with Scaleway, bunny.net and Brewless, plus every service your app sends personal data to.
- Agencies should prefer provider accounts in the client's name.
This is general information, not legal advice.
Frequently asked questions
Is Scaleway a sub-processor of Brewless?
Not for your app. Your app runs in your own Scaleway project, under your own contract with Scaleway, so Scaleway is your processor. Brewless also runs its own control plane at Scaleway, and for that Scaleway is a sub-processor of Brewless.
Which data processing agreements do I need when I host Laravel with Brewless?
One with Scaleway and one with bunny.net, under your own accounts, because they store and serve your app's data. And Brewless's data processing agreement, which is part of its terms and covers the personal data Brewless can come across on your instruction.
Does Brewless process my app's personal data?
Only in passing, on your instruction. When you open logs, run a command or look at a variable, Brewless reads it from your provider and shows it to you, without keeping the content. It keeps no copy of your app's database, files or logs.
I am an agency hosting a client's Laravel app. What is my role?
Usually the client is the controller and you are their processor. If the Scaleway and bunny.net accounts are in your name, the providers are your sub-processors and Brewless is one too. If the accounts are in the client's name, the client holds those contracts directly.
Where does Brewless handle personal data?
Inside the European Economic Area only, according to its data processing agreement. Its own sub-processors are listed in its privacy statement and are all established in the European Union.