The choice used to be simple: code ran on a server. Then it ran on a fleet of servers. Then it ran on serverless functions in one region. Now, in 2026, "where does the code run" is a real architectural decision with three credible answers — edge, regional origin, and the user's device — and the answer changes per route, not per project.
The three locations
The edge
Cloudflare Workers, Vercel Edge, Deno Deploy, Fastly Compute, Netlify Edge. Code runs in hundreds of data centres globally, milliseconds from the user. V8 isolates rather than full VMs, so cold start is effectively zero. Limited by language (JS/TS, WASM), resource ceilings, and the fact that your database is probably not next door.
The regional origin
An EC2 instance, a Fly machine, a managed container service, a serverless function in one or two regions. Full runtime, full language choice, full filesystem. Latency to the user depends on where they are and where the region is.
The user's device
The browser. Increasingly capable: WASM, WebGPU, OPFS, persistent workers. For some workloads — heavy data manipulation, image processing, certain ML inference — running in the browser is faster than any server-side path, because the data is already there.
The rule we apply
Code runs at the location closest to the data it needs.
If the data is mostly the user's session and a few cached values: edge.
If the data is in your primary database: near the primary database.
If the data is the user's own files: their machine.
Almost every architectural pain point we've audited in 2026 came from violating this rule — running auth checks at the edge that needed to make six database round-trips, or running heavy compute on a regional origin when the inputs were on the user's phone.
What goes at the edge
- Authentication checks against tokens you can verify cryptographically without a database hit.
- A/B test variant assignment.
- Geo-aware routing and personalisation.
- Bot mitigation.
- Static content serving with smart cache control.
- Webhook fan-out where the work is "validate signature, queue downstream."
What stays at the origin
- Anything that does a transaction across multiple tables.
- Anything that needs files larger than the edge runtime's memory ceiling.
- Cron-like background work.
- Anything that needs a non-JS runtime — heavy data work in Python, ML inference on GPUs, native code.
- Anything where consistency requirements demand sticky routing to a specific region.
What goes on the user's device
- Anything operating on data the user already has — local file processing, on-device search.
- Real-time UI work that should not round-trip — undo/redo, autocomplete on user data, immediate validation.
- ML inference on small models that fit in browser memory.
- Anything you want to work offline.
The mistake we see most
Teams discover that edge runtimes are fast and start pushing everything they can to the edge. Three months later they have a complex distributed architecture for what could be a single regional service, and they've introduced subtle bugs where the edge code and the origin code disagree about the state of the world.
The edge is a powerful tool. It is not a free upgrade. Every hop you add to a request path is a hop you have to monitor, version, and debug. We try to keep the request path as simple as the latency budget allows, and no simpler.
How we decide, per route
- What latency does this route owe the user? (Often higher than you'd think.)
- What data does this route need? Where does that data live?
- What's the cost of inconsistency between locations?
- What language and runtime constraints do we have?
The honest answer is usually: most routes stay at the regional origin, a small but high-value set move to the edge, and a growing fraction move to the user's device. The architecture diagram looks worse for it — three locations instead of one — but the user experience and the cost structure are both better.
Bottom line
"Run it at the edge" is not an architectural strategy. It's a tool you reach for when the data and latency profile of a specific route justifies it. The teams getting wins in 2026 picked one or two routes per app, ran them at the edge with discipline, and left the rest alone. The teams burning cycles on edge migrations of routes that didn't need it learned that lesson the slower way.