Why Drift?
Drift does not make your app smaller. It makes the surface you operate smaller. Those are different claims, and only the second one is true, which is what tells you whether Drift is the right call.
A real application (auth, a database, file uploads, a frontend) is about the same amount of code on Drift as it is on Postgres behind a web server behind a reverse proxy. What changes is everything around that code: the part that is not your product, and the part you would otherwise own for as long as it runs.
What disappears
Not the architecture. The setup, and then the long tail of operating it. On Drift you never write or run:
| The usual | On Drift |
|---|---|
| Dockerfile, container registry, image builds | One Driftfile, one deploy. |
| nginx/Caddy, TLS certs, certbot renewals | HTTPS on your slice's URL, renewed for you. |
DATABASE_URL, connection pools, a migration runner | drift.Backbone.SQL("app"): the DB is declared and reachable by name. |
| CORS preflight config between frontend and API | Same-origin /api/*: Canvas serves the site, no CORS exists. |
| A box you own: patches, backups, secret rotation, the 2am page | None of it. The slice is operated for you. |
The last row is the one that matters. A compose file for the same application is not large: a database, your app, a reverse proxy, perhaps forty lines. The weight was never the configuration. It is that from the moment it runs, you are the operator: the renewals, the backups, the upgrade that breaks at midnight. What Drift removes is that obligation, not the forty lines.
What Drift does not do
Drift does not make the hard part of your application easy, because the hard part was never the plumbing. Concurrent ledger integrity, a permissions model with real edge cases, a merge that has to converge. That difficulty is yours and it stays yours. What you get is sharp primitives to build it on: SQL transactions, locks, queues and a realtime hub. What you get back is the attention you were spending elsewhere.
A deploy feeling small is a side effect rather than the point.
What you give up
The smaller surface is bought with constraints, and they are real. Read this list before you commit rather than after.
| The constraint | What it means for you |
|---|---|
| A slice runs as one thing | Always on, never doubled. Nothing scales up or down behind you and there's no count to pick: the capacity dial is memory per invocation, 32MB to 256MB. |
| A function is the only child process | Starting a second process is refused by the kernel. Shelling out to ffmpeg, or to any other tool, isn't available from inside a function. |
| Six languages | Go, Python, Node.js, Ruby, PHP, Rust. If yours isn't one of those, it isn't there. |
| No reach into private networks | Outbound calls to RFC-1918, link-local and CGNAT addresses are blocked whatever your Driftfile says, so a function can'tdial your office VPN or a cluster-internal host. |
| You pay for the shape, not the traffic | The bill is the capacity you declared, prepaid per month. An idle slice costs exactly what a busy one costs. |
| Deploys never shrink | A Driftfile declaring less than the live slice is refused, because shrinking deletes data the manifest can't know about. Shrinking is a separate command with --allow-destructive in its name. |
Every one of them buys the last row under What disappears: the box you do not own. Whether that is a good trade is a question about your application, and the answer is sometimes no.
Who it is for
Drift is worth most to whoever would otherwise be the operator: the solo builder, the small team, the side project meant to outlive the attention you have for it. If you would rather ship features than maintain a database and a certificate, the trade is in your favour. If running infrastructure is your craft, you may not need any of this, and that is a fair answer.
Drift runs in Europe with no US-owned dependency in the data path, so never operating it costs you nothing in sovereignty; see Security.