The case for a small cloud
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.
Small is a position, not a stage
Drift is a hyposcaler, and the word is doing work rather than being cute. The hyperscalers are organised around the idea that more is the direction of travel: more services, more regions, more of your architecture living inside someone else's catalogue, priced per part. Drift is the argument that a cloud can be finished instead of perpetually expanding, and that for most applications the extra was never load-bearing.
So small here is not a stage on the way to large, and it is not a shortfall to apologise for. It is the thing being chosen. A platform you can hold in your head is one you can reason about, price, defend and leave, and every constraint further down this page is bought deliberately to keep it that way.
It also decides the architecture rather than following from it: one image for every tenant, one binary per slice, one file to declare an application. That is why a slice costs tens of megabytes rather than a gigabyte and a half, and the price on what it costs is the same decision arriving on your invoice.
The honest boundary of the claim: small describes the surface you operate, never the difficulty of your problem. The section below on what Drift does not do is the other half of that sentence.
The parts you did not have to buy
A short catalogue is not a short list of parts. The things that make a deployment safe are all present in a slice; none of them is something you select, size, wire together or pay for as a line.
| What you would otherwise buy and configure | On Drift |
|---|---|
| A virtual network, subnets, a security group | Your slice sits behind a default-deny boundary. There is nothing to open, because nothing was open. |
| A certificate, and its renewal | Issued and renewed for every hostname, your own domains included. |
| Encryption at rest, and the key handling under it | On for every Backbone primitive. The key never reaches your code. |
| An API gateway, and CORS between your site and your API | Same origin. There is no CORS to configure because there is no second origin. |
| An identity provider, and a contract with one | Deed runs inside your slice. There is nobody to register with. |
| Isolation from the other tenants on the box | A namespace, a network policy, and a kernel-sealed process per invocation. |
This is the part that reads as "handled for you, somewhere out of sight", and it is worth being exact instead. None of it is absent and none of it is hidden. It is not optional. A hyperscaler sells each row separately, charges for it, and leaves it off by default, so a safe deployment is something you assemble and can get wrong. Drift's position is that a wall you can misconfigure is worse than a wall you cannot, and that if a setting only has one correct value it should not have been a setting.
The cost of that position is the next section but one, and it is real: you cannot reshape any of it either.
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, 8MB to 256MB — 16MB to 256MB for a compiled language. |
| 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. |
| Deploying never resizes | A Driftfile fills the slots your slice already has; it cannot add one, and applying it against a slice that does not exist is refused. Changing the shape is a separate act, in the browser form that prices it. |
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.
The products you are actually choosing between
Nobody evaluates Drift against AWS. If you are reading this page you probably have one of these open in another tab, so here they are by name, with what each one does better than Drift stated first.
PocketBase is a single Go binary with SQLite, auth, realtime, file storage and an admin UI, and it runs on a four-euro VPS. The feature overlap with a Drift slice is high and the price is unbeatable, because it is zero. It is also years more proven than Drift is: it has been running in production for thousands of people while Drift is in closed alpha with no independent audit.
What Drift answers with is the thing that starts the moment PocketBase is running: you are the operator. The binary is free, and the VPS it sits on is yours to patch, back up, renew certificates for, and get paged about. Drift costs money precisely because that job is ours. If you enjoy that job, or your deployment is small enough that it never really shows up, PocketBase is a genuinely good answer and you should take it.
Supabase has a far bigger ecosystem than Drift will have for years, gives you real Postgres rather than a per-slice SQL database, is self-hostable, and offers EU regions. On features, it wins.
Drift's answer is jurisdiction and operation. An EU region belonging to a US company is a location, not a jurisdiction: the data sits in Europe while the entity holding it answers to a legal system that can compel disclosure. That distinction is the whole of Made in Europe, and it is either decisive for you or irrelevant. And the self-hosting escape hatch has the PocketBase property again: self-hosting means operating it.
Appwrite is the closest structural analogue to Drift, with a comparable spread of primitives behind one SDK, self-hostable, and with a hosted cloud. Its SDK surface and community are both larger than ours.
Drift's answer is jurisdiction again, plus the bill. Drift is prepaid against the shape you declare, with no request metering, no egress line, and no invoice that can come in above the number you agreed to. That is a structural difference rather than a pricing promotion, and What it costs shows the whole of it on one page.
The honest summary
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 Made in Europe.