Security & trust

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 rather than having it bolted on afterwards. This page says what the controls are in plain language, gives the numbers where numbers exist, and marks the places where the honest answer is "not yet".

What we protect against

Your workload is an island

Each customer's app runs in its own isolated environment. One tenant cannot read another's database, call another's functions, or send traffic to another's app.

We do not take that boundary on faith. We deploy deliberately hostile workloads whose only job is to try to cross it, and confirm they cannot. Isolation you keep trying to break is the only kind worth claiming.

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. Four controls do the work:

• No second process, ever. A kernel-level syscall filter is installed before your code's first instruction and survives into it. Any attempt to fork, spawn, re-exec, or attach to another process is killed by the kernel, not caught by a convention.
• Read-only root filesystem, non-root, no capabilities. The process that runs your function owns no privileged operations at all, and writes only to the few paths explicitly mounted writable for it.
• Nothing to escalate into. The image is built from scratch: no shell, no coreutils, no package manager.
• Secrets scrubbed from the environment. The environment your function receives is rebuilt from nothing and then explicitly repopulated, so platform credentials are absent rather than merely unlisted.

We test for sandbox escape with a dedicated suite and treat any finding as a release blocker rather than a backlog item.

What your function can reach

The isolation above is about what can reach in. Outbound is a separate question, and the default answer surprises people, so it is worth stating plainly.

Open by default

A slice's egress mode defaults to open: your function can call any public host on any port. Private and reserved address ranges are blocked unconditionally in that mode, so "the whole internet" means the public internet and nothing internal.

Declaring an allowlist

allowlist mode names the hosts a slice is meant to reach. The Driftfile is the source of truth, and atomic sits at the top level:

atomic:
  egress:
    mode: allowlist          # open | allowlist
    hosts:
      - api.stripe.com
      - hooks.slack.com
      - smtp.sendgrid.net:587

Inspect and test the declared list with:

drift atomic egress list                  # active mode, declared hosts, resolved addresses
drift atomic egress test api.stripe.com   # local pattern check: did I spell it right?
drift atomic egress refresh               # re-resolve, for a host whose addresses rotate

There is no add or remove: the Driftfile holds the list, and drift project deploy reconciles it. See the Driftfile reference for the full block.

Limits and what a 429 means

Rate limits protect capacity so one tenant's traffic cannot starve another's. They are not a security boundary, and they are built accordingly.

Over budget is 429 rate limit exceeded. The app budget is counted in one place, so requests spend from a single allowance however they arrive rather than each route granting a fresh one. The window is fixed rather than sliding, which means a burst spanning a window boundary can briefly spend two windows' worth which is a known and accepted trade for a counter that costs one increment per request.

Per-function ceilings, memory and runtime, come from the same tier configuration and are applied to the slice when it is provisioned. On the free tier that is 32 MB per function and a 10-second runtime. Declare your own in the Driftfile.

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 store it came from. The sensitive material is kept one layer away from the code that consumes it.

Traffic between you and Drift is HTTPS, terminated at the edge. Traffic between Drift's own internal components is not individually encrypted; it is confined. The internal network is closed by default, and each workload carries rules naming the specific components allowed to reach it and the specific ports they may use. That is the accurate claim, and it is a different one from "HTTPS everywhere".

Your data is yours, including the exit

Security is not only about keeping bad things out. It is also about not trapping you in. A platform that will not let you leave is one you have to trust; one you can leave any time is one you can verify.

Taking everything with you

drift slice snapshot create
drift slice snapshot list
drift slice snapshot download <id> -o my-app.tar.gz

The archive holds everything the slice is:

• Your source, one folder per element, as you wrote it, with every Drift-generated wrapper stripped out.
• Backbone data: secrets, NoSQL collections, queues, blobs, SQL.
• Deed data: vault, link, pocket.
• Canvas sites, as files.

Cache and locks are skipped, because they are ephemeral by definition. Capture is best-effort per component and each outcome is recorded on the snapshot, so a partial archive announces itself instead of looking complete.

Deleting the account

drift account delete tears down every slice, wipes every record tied to the account including its per-slice databases, and purges its stored files. Because Drift takes no card payments, there is almost nothing we are legally obliged to retain, so erasure can mean what it says.

European by design

How we check our own work

A security claim you cannot see is marketing. So here is exactly what we run, and when.

• Before every release, a single gate must pass: formatting, static analysis, the full unit tier under the race detector, and the scanner set: known Go vulnerabilities, static security analysis, dependency advisories, and filesystem, secret and configuration scanning. Container image scanning and SBOM generation are separate commands on the same surface.
• An outside-in suite attacks the platform's public surface with no inside knowledge.
• An inside-out suite deploys adversarial workloads that try to break the sandbox and reach other tenants. It is destructive by design and never pointed at a live environment.
• Isolation boundaries have their own regression tests, so a boundary we close stays closed.

Reporting a vulnerability

If you find something, we want it. A confirmed finding in isolation, the sandbox, or authentication blocks the release it is found in.

Send it to info@ondrift.eu. There is no dedicated security alias and no published disclosure policy yet, which is itself worth knowing, so please use email rather than a public issue tracker, and give us a reasonable window before publishing.

A report we can act on quickly contains:

• What boundary you crossed, and what you reached on the other side.
• The steps to reproduce it, ideally as a function we can deploy.
• Whether it needs an account, and whether it affects a tenant other than your own.

What we don't claim (yet)

We would rather show you the edges than pretend there are none.

This page changes as those change. If the honesty costs us a sale today, it is the right trade: the whole point of Drift is to be the cloud that tells you the truth.

Authentication → · Driftfile reference →