drift Docs
Start
What is Drift?
The tour, if you are new here.
Use cases
Whether Drift does your thing.
Getting started
Nothing to deployed, in one command.
Architecture
How a slice is put together.
What it costs
The free grant, four unit prices, two rules.
Build
Canvas
Static sites, same origin as your API.
Tools
Operate
Auth
Accounts, tokens and scopes.
Security
Boundaries, sandboxing and hardening.
Troubleshooting
Error codes
What went wrong, and what to do about it.
Legal
Acceptable use
What a slice may not be used for.
Data processing
The DPA, and every sub-processor.

Made in Europe

Drift is built in the EU, hosted in the EU, and owned in the EU. It is subject to European law and nothing else.

A European application cloud

Read the EU-native field: OVHcloud, Hetzner, Scaleway, Exoscale, IONOS, STACKIT. Every one of them sells infrastructure. Not one of them sells applications. The sovereign-cloud conversation has produced a dozen good places to rent a virtual machine in Europe and nowhere to deploy a function.

That gap is where Drift sits. You build, deploy, operate and own an application without first assembling a cloud architecture to put it on. The unit of value is not the server. It is the application.

Drift is not a smaller AWS, Azure or GCP either. Hyperscalers offer nearly unlimited infrastructure primitives: regions, GPUs, networking, managed services, enterprise ecosystems. Drift offers none of that and does not intend to. The word for that is hyposcaler, and it is a claim rather than a concession: scale is the thing being declined, not the thing not yet reached.

A service catalogue is the wrong ruler anyway, because it measures the vendor rather than your application. The measures that matter are how much architecture you had to build before your application could run, how much of it you own for as long as it runs, and whose law reaches it while it does. The first two are the case for a small cloud; the third is the rest of this page.

A region is not a jurisdiction

Plenty of services are "available in an EU region" while the company operating them, the support staff who can reach the console, and the legal entity that answers a subpoena are all somewhere else. A region is a location. Jurisdiction is who can compel access.

Nothing your application holds passes through a US-owned dependency, and no parent company in another jurisdiction can be compelled to reach into it. When somebody asks where the data goes, the answer is your slice, in Europe, under European law.

The question The answer
Where does the data physically sit?On European infrastructure, in one European region
Whose law governs it?European law, and no other
Who operates the machines?Drift, in Europe
Can a foreign legal process reach it?There is no foreign-owned link in the slice's data path for one to act on

One exception, and we would rather you heard it from us

Transactional email, the signup code and renewal notices, currently goes out through Microsoft 365, so your account's email address passes through a US-parented company even though the entity and the servers are Irish. Your slice never does: not the source, the database, the blobs, the secrets, the identities or the site. Data processing states the full scope, and the transport is being moved to an EU-owned provider. We apply the argument on this page to ourselves, and this is where it currently costs us something.

Who this is for

Organisations where hyperscaler complexity is painful and hyperscaler scale is unnecessary.

  • SMEs A portal, a workflow, a dashboard, some automation. All of it needed, and none of it worth standing up a cloud architecture team for.
  • Agencies Many client applications at once, each needing somewhere predictable to run and something straightforward to hand over.
  • Public bodies A great many smaller applications surround the core systems, and for those, portability and European hosting are worth something concrete.

For a public body the substance is ownership: build modern applications, keep them, and keep the ability to run them elsewhere. A municipality does not need another large platform contract. It needs applications it understands and controls.

One region today, more of Europe next

Everything currently runs in a single European region.

Multi-region is paid for in complexity: data in more than one place at once, a story for what happens when the copies disagree, and a much larger surface to reason about when something goes wrong. Drift starts from one region so that surface stays small while the platform is young.

The direction is more of Europe. Drift is built to span as much of the EU as it usefully can, and multi-region, with the availability that comes with it, is where it is going. Every region added is another European one, under the same law.

Today this is not multi-region high availability

Security states the limits of the current setup in full, including this one. If your application needs to survive a region failing right now, that is worth knowing before you commit rather than after.

Sovereignty includes the right to leave

A platform you cannot walk away from is not one you are sovereign on, whatever jurisdiction it sits in. Lock-in is the same dependency wearing a friendlier name, and a promise not to exploit it is not the same as not having it.

The exit is a command rather than a support ticket. drift slice snapshot download hands back the whole slice: your function source as you wrote it, your data, your secrets and your site, in an archive whose source tree carries every Drift-generated wrapper stripped out. Nothing in there needs Drift to open it, and taking it is not a negotiation.

The same property makes arriving straightforward, which is what the migration paths are built on.

Using a cloud platform should not mean renting someone else's. An application you build here stays yours in the sense that matters: you can take it and go.

What Drift costs →