Security & trust
How Drift keeps your data yours, keeps tenants apart, and contains the code it runs — and how we check our own work.
Drift runs other people's code and stores other people's data on shared infrastructure. That is a responsibility, and the platform is built around it from the first line rather than bolted on after. This page is the plain-language version of how we protect you — framed around what actually matters to you: your data stays yours, your workload stays isolated, and untrusted code stays contained. And, in the same breath, what we don't yet claim.
What we protect against
Three questions cover almost everything people ask us about safety. Here are the honest answers.
| The question | The answer |
|---|---|
| "Can another customer on Drift reach my stuff?" | No. Every workload is isolated — one customer cannot see, reach, or affect another's data, code, or traffic. |
| "Can someone on the internet break in?" | Access is authenticated and rate-limited, and the platform is penetration-tested from the outside on an ongoing basis. |
| "Can anyone read my data in transit or at rest?" | Traffic is encrypted in transit (HTTPS everywhere). Secrets are encrypted at rest, and the key that decrypts them never reaches your running code. |
Your workload is an island
Each customer's app runs in its own isolated environment, kept apart from every other customer at the data, compute, and network level. One tenant cannot read another's database, call another's functions, or send traffic to another's app. We don't just design for that boundary — we attack it: we deploy deliberately hostile workloads whose only job is to try to cross the line, and we confirm they can't. Isolation we take on faith isn't isolation; isolation we keep trying to break is.
Untrusted code, tightly contained
Atomic runs the code you write, which means — from the platform's point of view — it runs untrusted code, and treats it that way. Your function executes inside a confined sandbox: it can't spawn its own processes, can't escape to the host it runs on, and can't reach the rest of the platform. And if something ever did slip past the sandbox, it lands somewhere deliberately barren — no tools, no shell, nothing useful within reach. We test for sandbox escape continuously and treat any finding as a release blocker, not a backlog item.
Your data is encrypted — and the keys stay out of reach
Secrets you store are encrypted at rest, and the key that unlocks them is never handed to your running functions: your code uses a secret without ever holding the means to decrypt the vault it came from. Everything in transit travels over HTTPS. The principle is the same throughout — the sensitive material is kept one layer away from the code that consumes it.
Your data is yours — including the exit
Security isn't only about keeping bad things out. It's also about not trapping you in. A platform that won't let you leave is a platform you have to trust; one you can leave any time is one you can verify.
Take everything with you. One command exports your whole app — source code, data, files, and sites — as an ordinary archive with zero Drift-specific files. It works without us. You are never locked in.
Delete means delete. Erasure actually erases. And because Drift takes no card payments, there are almost no records we're legally obliged to retain — so "delete my account" can mean exactly what it says.
European by design
Drift is built, hosted, and owned in Europe, and subject to European law and nothing else. Your data lives on European infrastructure — not on a US-controlled cloud reachable by foreign legal process.
For anyone who has to answer "where does the data go?", the answer is short: it's on your slice, in Europe. Storing as little about people as the job requires is the default here, not an add-on — privacy is a design constraint, not a settings page.
How we check our own work
A security claim you can't see is just marketing. So we hold ourselves to checks that run on their own, every time:
- Every release is scanned for known vulnerabilities, risky dependencies, code-level security flaws, and supply-chain risks — all must be clean before anything ships.
- The platform is penetration-tested from the outside — the way an attacker with no inside knowledge would see it.
- And from the inside — adversarial workloads that actively try to break the sandbox and reach other tenants.
- Isolation has dedicated regression tests, so a boundary we close stays closed.
This runs continuously, not once before a launch and never again.
What we don't claim (yet)
We'd rather show you the edges than pretend there aren't any. Three things we are deliberately honest about:
- Drift is early. We're in a closed, pre-launch phase — building depth on purpose before opening the doors widely.
- We are not independently audited yet. The testing above is our own, and rigorous — but third-party certification (the formal audits larger organisations ask for) is on the roadmap, not done.
- We are single-region, on purpose. Everything runs in one European region. That's a sovereignty and simplicity choice — it is not multi-region high availability, and we won't pretend it is.
We'll update this page as these change. If that honesty costs us a sale today, it's the right trade — the whole point of Drift is to be the cloud that tells you the truth.
Security at Drift isn't a checkbox or a premium tier. It's the same conviction as the rest of the platform: simple, honest, and yours.