intertwingly

It’s just data

Routing to Identity

LLM conversations are cells. Each has a unique identity, carries its own state, needs to be routed specifically, is active in bursts, and is fundamentally disposable. The explosive demand for this pattern forced infrastructure providers — Cloudflare with Agents, Fly.io with Sprites, Akamai's Fermyon with Spin — to build first-class support for identity-routed, stateful, hibernatable compute. They built it for AI. It turns out it's the right infrastructure for any application where data partitions along human-scale collaboration boundaries.

A kanban board. A dance competition. A chat room. A game lobby. These aren't side projects lacking the budget for Postgres. They're applications whose domains naturally partition — and where the partition boundary was always the right place to put a database. The cell pattern, shared-nothing architecture, SQLite as a distributed primitive — the ideas aren't new. The infrastructure to make them cheap and effortless finally is.

SQLite isn't for side projects. It's for applications where the natural unit of collaboration is small and the way you scale is by creating more units, not bigger ones.

A Different Architecture

Kubernetes routes to capacity — any healthy pod can serve any request. Cell orchestration routes to identity — a request for this team's board or this event's scores must reach the specific instance that holds that data. These are fundamentally different problems, and everything downstream follows from which one you're solving.

When you route to capacity, you separate compute from storage, make pods fungible, and scale by adding replicas. When you route to identity, compute and storage fuse together — a SQLite file lives with the code that serves it. You scale by creating more cells, not bigger ones. Cells sleep when idle, wake on demand, and can be disposed of when they've served their purpose.

Gaps

Each platform has built part of the cell architecture. Fly.io has the durable, hibernatable compute (Sprites) and the deployable artifact (Machines), but no switchboard. Fermyon has the fastest serverless runtime and built-in SQLite, but remains committed to stateless functions routed to capacity. Cloudflare is the only one that currently unifies all three — the deployable class, the programmable edge router, and instantiate-on-first-reference lifecycle — into a single primitive.

But the trajectory is clear. The pressure that pushed all three providers toward stateful, hibernatable, identity-aware compute — LLM conversations that need to be routed to this specific instance — doesn't stop at the use case that created the demand. Once the infrastructure exists to route by identity, sleep when idle, and wake on demand, it becomes the natural home for any application whose data partitions along human-scale collaboration boundaries. The platforms that haven't assembled all the pieces yet are one or two decisions away from doing so. The pattern is inevitable; only the timeline varies.

Fly got the runtime right but hasn't assembled the orchestration. Fermyon prioritizes speed over state. Cloudflare got the architecture right but constrained the runtime.

Durable Objects run in V8 isolates — you get JavaScript, TypeScript, or languages that compile to WebAssembly. No Ruby, no Python with its full ecosystem, no Rails, no Django, no Phoenix. You can't apt-get install imagemagick. You can't run a process that shells out to ffmpeg. The sandbox that makes instantiate-on-first-reference so cheap and fast is the same sandbox that locks you out of the broader software ecosystem.

Implementation Approaches

For my showcase application, I started out with Phusion Passenger's multi-tenant support. I generated nginx configuration files to describe my events. Cumbersome, but workable. Biggest issue was that any change required restarts. When I moved to fly.io I generated different configurations for each machine, with fly-replay rerouting requests between machines. More cumbersome, and at times difficult to debug.

Last year, I wrote Navigator to replace this. It was a substantial investment, but got me new features like suspend and hot reloading. Not being a part of the platform limits what I am able to accomplish. Example: a request comes in. It wakes up a random machine to process the request. That machine routes the request to the proper machine. Primarily for that reason, I've so far stopped at one machine per region, with multiple tenants per machine.

In theory, I could use the same Navigator with Kamal and commodity servers like Hetzner or Digital Ocean. In practice, I would likely pair them with CloudFlare workers instead, with CloudFlare routing to the correct machine. Since VPS and real servers don't spin up on demand, I likely would still pack multiple events per machine.

As of early 2026, CloudFlare comes closest to being the ideal target. There are a few cases like Print On Demand that I would likely still delegate to fly.io, but the rest could all be Durable Objects. There's only one minor detail - you have to rewrite your entire application in JavaScript. Fortunately, that looks increasingly tractable.

Summary

Things are rapidly converging.

LLM tools didn't just drive the infrastructure pattern — they make it easier to build applications that use it. If you can tell Claude "build me a small self-contained app that uses SQLite and runs on a single node," and deploy it to a Fly Machine or a Durable Object in minutes, the barrier to creating a new cell drops to almost zero. The same technology that created the demand for cell infrastructure also lowers the cost of populating it with applications. That's a feedback loop, not just a one-time catalyst. It doesn't stop there: LLMs didn't just drive the demand for cell infrastructure, LLMs accelerated building the transpiler (Claude Code turning weeks into days), the transpiler makes cells writable in Rails patterns, and the Big Tent culture of JavaScript is why none of this requires anyone's permission.