Shared tenancy is a promise about code you cannot read. Every email.eu customer gets their own drive instance, with its own database and its own storage bucket. What that buys, what it costs us, and the access hook that turned out to be the right place for every permission decision.
"Multi-tenant" is the word for hundreds of companies sharing one system, kept apart by a column in a database that says which company each row belongs to. It is how most software you use is built, and it works, right up until a query somewhere forgets to filter on that column.
You cannot audit that from the outside. You are trusting that every query, in every feature, written by every engineer who ever worked there, remembered. The honest summary of shared-tenancy security is that it is a promise about code you cannot read.
Our drive is not built that way. Every customer gets their own.
When your workspace is created, we stand up a complete drive for you. Your own instance of the software, at your own address, with its own database and its own storage bucket.
Not your own row in our database. Your own database. Not a folder in a shared bucket. Your own bucket.
So the question "could another customer's files end up visible to us, or ours to them" has a structural answer rather than a procedural one. There is no query that could return another company's files, because another company's files are not in the store being queried. Isolation is not a filter that has to be applied correctly every time. It is the shape of the system.
Blast radius. A problem confined to one instance is confined to one customer. Not a class of problem that, by construction, affects everyone at once.
Deletion that means deletion. When you leave, your drive is torn down: instance, database, bucket. There is no archived remnant of your files sitting inside a shared store waiting for a retention policy that may or may not be honoured. That promise only works because the isolation is real.
Honest answers to due diligence. When a customer of yours asks where their data sits and who else can reach it, you can answer specifically instead of forwarding a vendor's compliance PDF.
The cost, which we should state, is that this is more expensive to operate than one big shared system. More instances, more databases, more moving parts. We chose it anyway because the alternative is asking you to trust code you cannot see, and that is exactly the trust that our whole approach exists to avoid asking for.
Here is a design detail that is more interesting than it sounds.
The drive software has no built-in way to enforce a hard per-user storage limit. Plenty of systems are like this: they will show you usage, and they will not stop anybody. Which is a problem when storage is part of what a plan buys.
So each instance asks us. Every time somebody opens the drive or uploads a file, the instance calls back to our control plane with "this person, this workspace, may they?" and we answer yes or no. That one hook turned out to be the right place for every access decision, not just storage:
Answering all of that in one place means access control lives in the system that actually knows the truth about members, plans and payments, instead of being copied into every product and drifting.
There is a subtlety we got right on the second reading of the documentation, and it is the sort of thing that decides whether a system is trustworthy under stress. When we want to deny access, we have to answer clearly "no". If we instead returned an error, the drive would treat the whole check as broken and show the user a failure page. A denial and a malfunction are different events and must look different, or every hiccup in our control plane becomes an outage for you. So a refusal is an explicit, well-formed no, and errors are reserved for things that are actually errors.
The quota is a workspace pool, sized by how many people you have. On Starter that is 100 GB per person, on Business 2 TB per person, and it covers mail and files together.
Pool rather than per-person is deliberate. In every real company, storage use is wildly uneven: the designer has 400 GB of assets and the sales lead has 4 GB of PDFs. A strict per-person cage means the designer is blocked while most of what you paid for sits unused. Pooling means you buy for the company and the company distributes it, which is how it actually gets used.
Files sync, share by link, and open in a real collaborative editor for documents and spreadsheets. It speaks standard protocols, so you can reach it from your computer's file browser and pull everything out whenever you like, which is the portability point applied to files.
The software underneath is La Suite Drive, the open-source drive built by the French public administration, which we run and contribute back to. We wrote about why we build on that ecosystem rather than writing our own from scratch.
One boundary worth naming: files are encrypted in storage, but they are not encrypted in a way that makes them unreadable to us, unlike mailbox encryption at rest where you hold the key. If a file is sensitive enough that no operator should be able to read it, encrypt it before it goes in. We would rather tell you the boundary than let you assume a stronger one.
Drive is on every plan, with the pool sized by your plan.