Use cases
Four questions people tend to arrive with, and the path each one takes. Every path below ends in something running on a real slice, so you can follow one to a URL rather than to a diagram.
Put an API, a database and a site online without running a server
The problem. You have a small application: a page, an API behind it, and somewhere to keep the data. Getting that online usually means a web server, a database to provision, a reverse proxy in front, a certificate to renew, and CORS rules between the frontend and the API.
On Drift. All three live in one slice and share one origin. Your page fetches /api/messages with no cross-origin request, because there is no second origin. Nothing is provisioned and nothing is renewed.
| The piece | What runs it |
|---|---|
| The API | Atomic, one flat source file per function |
| The data | Backbone, SQL or NoSQL, already there |
| The page | Canvas, same origin as the API |
The path. Getting started builds exactly this, a guestbook with a form, an API and a database, from an empty folder to a public URL. It is the shortest complete path on Drift and the one to walk first.
From there, Write a function covers the handler shape, SQL and NoSQL cover the two data models, and Canvas covers serving the page.
Move a workload off Azure, and see the bill first
The problem. You are running Function Apps with a Cosmos or Storage account behind them, the monthly cost is hard to attribute, and any migration proposal starts with a rewrite you cannot justify.
On Drift. drift migrate azure reads your resource group without changing anything, prices the same workload on Drift, and can then produce a deployable project from it. The read-only stages are safe to run against production on the first day, because nothing in the pipeline writes to Azure.
- Command
drift migrate azure estimate -g <group>- What it does
- Prices the group as it stands, against what it would cost here
- Command
drift migrate azure snapshot -g <group>- What it does
- Exports the group to a portable
azure_export/folder, read-only
- Command
drift migrate azure transform- What it does
- Turns that export into a deployable
drift_workspace/, fully offline
- Command
drift migrate azure apply- What it does
- Deploys the workspace to your active slice
The path. Start at step 1 on a group you already own. It answers the cost question on its own, and it commits you to nothing: steps 1 and 2 only read, and step 3 does not need a network at all. The full command surface is in the CLI reference.
The estimate is a comparison, not a quote
Ship a verifiable identity app that outlives its vendor
The problem. You are building something where identity is the product rather than a login screen: a credential wallet, a device-bound account, an app that must keep working if you stop paying whoever hosts it. An identity provider you rent is the one dependency you cannot afford.
On Drift. Deed is a peer of the other three services, not a bolt-on. Every primitive is called from your own functions through the SDK, against your own slice. There is no identity provider to register with and no account anywhere but yours.
| Primitive | What it covers |
|---|---|
| KeyAuth | Passwordless login with a device key pair |
| Link | Enrolling a second device by signed attestation |
| End-to-end encrypted data that follows an identity between devices | |
| Vault | A recovery blob the slice itself cannot read |
| JWT | Tokens signed and verified with your slice's own key |
The path. Read Deed for how the five fit together, then build the login with KeyAuth and add a second device with Link. The client half of the encryption is e2ee.js, a zero-dependency ES module you copy into your own JavaScript, described on the Deed page.
Encrypt before you call
Why it survives you leaving. Everything above runs inside your slice, and drift slice snapshot download gives you the whole thing back: the source with every Drift-generated wrapper stripped out, the data, the identities and the site. That is the same property the migration path above relies on, pointed the other way.
Build it, ship it, hand it over
The problem. You build applications for other people. Every client is a small app that has to live somewhere for years, and each one quietly makes you their infrastructure department: their hosting bill, their certificate renewal, their 2am page, long after the invoice was paid. Handing the work over properly usually means either running it forever or writing a migration document nobody reads.
On Drift. One slice per client. The slice is the unit of isolation, the unit of billing and the unit of handover, so a client's application never shares a database, a domain or a bill with another client's.
| The question | The answer |
|---|---|
| Where does each client's app live? | Its own slice, its own data, its own domain |
| What does one cost? | The shape you declared, prepaid, no metering. What it costs |
| What do you actually hand over? | drift slice snapshot download: a folder of their code and their data |
| What if they leave you? | They already have everything. Nothing to extract, nothing to negotiate |
The path. Build the first one on Getting started, then give each client their own slice with drift slice create. When the engagement ends, drift slice snapshot download produces the handover artifact: their source with every Drift-generated wrapper stripped out, their database contents, their secrets and their site, in a plain tar.gz. It is a deliverable rather than an export, and it is the same command whether you are handing over, backing up or leaving.
Transferring a running slice between accounts does not exist yet
Why the GDPR question gets easier. Your client's DPO will ask where the data sits and who can reach it. The answers are on one page you can send them rather than a conversation you have to have: Data processing has the agreement and the full sub-processor list, and it is short because the stack is genuinely European.