Worker Loaders as a Place

Problem: I kept reading the Dynamic Workers docs and understanding the API without understanding the thing.

What helped: Stop thinking about the API. Start thinking about the room.

Above  →  whoever sent you in (Worker, DO, Agent)
               ┌─────────────────────────┐
               │  THE ROOM               │
               │  sandboxed. yours.      │
               │  loop. compute. play.   │
               └─────────────────────────┘
Below  →  where results go (storage, trace, API)

Sunil Pai taught me to think of Durable Objects as mini servers. That reframe cracked open a whole class of problems I suddenly knew how to solve. I didn't come up with it. He handed it to me and my brain did the rest.

I had another one of those moments recently. This time with Dynamic Workers. Even if the metaphor is wrong, it helped me. So I'm writing it down.

The Room

You get dropped into a room. No doors you can open yourself. You didn't build it. You don't own it. But for the time you're there, it's yours.

Someone above you.. a Worker, an agent, whatever.. decided you needed to exist. They built the room. They chose what to put in it: maybe network access, maybe RPC stubs to talk to storage, maybe nothing at all. Then they said: "Go play."

That's a Dynamic Worker.

The room is a V8 isolate. An isolate is V8's word for a completely independent instance of its JavaScript engine.. own heap, own garbage collector, own everything.. but sharing a process with hundreds of others. Google's Chrome team invented this so browser tabs could run separately without each needing their own OS process. Cloudflare saw that and built Workers on the same idea. Now Dynamic Workers take it one level deeper.. a Worker spawning its own isolates at runtime.

Not a container. Not a process. An isolate starts in ~5ms, uses ~3MB, and can share a thread with the thing that created it. By default it inherits the parent's network access.. but the parent can brick up the windows with globalOutbound: null, intercept every outbound request, or inject credentials the room never sees. The parent decides the shape of the room before you arrive.

Inside? You can do whatever you want. Loop. Transform. Compute. Validate. Break things. The room is disposable.

When you're done, the room disappears. Maybe it leaves a trace. Maybe it hands something back up to whoever summoned it. But the room itself is gone.

Why "Place"

The moment it shifted I was sitting in a physical room thinking about compute. Bare walls. No distractions. Just me and whatever I brought in. And I thought: that's what these are. A place. Not an API. Not a function call. A space you occupy, do work in, and leave.

Once I started thinking "what can I fit in this space?" instead of "what does this API do?".. everything shifted. I stopped reading docs for method signatures and started thinking about the shape of work that belongs here.

What's small enough to live in this room? What can I pull out of the layer above so it stays clean? What doesn't need to persist to the layer below?

The room is between the worlds we already know. It's somewhere else entirely.. a throwaway space. A liquid room. A moment in time that's safe.

Cheap Compute Lives Here

Dynamic Workers are isolates, not containers. They can start inside a request without provisioning a container. I have not measured startup time or cost closely enough to call either negligible.

The room is where cheap compute can live. Loops that would be wasteful in your main Worker? Put them in a room. Transformations that might hang? Room. Validation logic you don't trust? Room. The room is disposable, so the compute inside it is disposable too.

You're not paying for a server. You're not even paying for a function invocation in the traditional sense. You're paying for a blip of V8 time that runs on the same machine, maybe the same thread, as the thing that spawned it.

Worker receives request
  └─→ spawns room (Dynamic Worker)
        └─→ room loops, transforms, validates
        └─→ room hands result back
  └─→ Worker sends response

Room: short-lived. Measure cost in your workload.

What Fits In The Room

Untrusted code. User submits code? Build a room with globalOutbound: null. No network. No secrets. Run it. Return the result. Tear it down.

Agent code execution. Instead of giving an LLM twelve tool calls, give it an API and let it write and execute code. The code runs in a room with only the bindings and network access the parent provides. That narrows what generated code can reach.

Self-healing pipelines. Step fails? Spin up a room to diagnose it. The room gets the broken data, tries to fix it, hands back the result. Each step is its own isolated space. The trace of rooms becomes the audit log.

Execution record. The parent can record the code, provided bindings, input, output, and runtime errors. That is useful evidence about the run, though it is not a proof that no external factor influenced the result.

Canary logic. Run old code and new code in parallel rooms. Same input, two rooms, compare outputs. No deploy. Just two rooms answering the same question.

Terminology

The naming tripped me up. Here's how I think about it now:

Worker Loader = the binding. env.LOADER. The door-builder.

Dynamic Worker = the room. The isolate that gets created. The space you occupy.

load(code) = build a room, use it once, tear it down. Fresh every time.

get(id, callback) = build a room and remember it. Same ID might return a warm isolate. No guarantee.

I use Worker Loaders to create Dynamic Workers. The loader is the mechanism. The Dynamic Worker is the place.

Different Axis

Dynamic Workers are not on the same layer as anything else in the stack. They don't persist. They don't own state. They exist for a task, borrow what they're given, and disappear. But they can reach out.. to storage, to APIs, to other services.. if they were given the stubs.

	Worker	Dynamic Worker
Deployed	Yes. Has a URL.	No. Spawned at runtime.
Code	Known at deploy time.	Provided at runtime as strings.
State	Stateless per request.	Stateless per request. Borrows what it's given.
Network	Full access.	Inherits parent's. Can be locked down.
Bindings	Configured in wrangler.	Passed via RPC stubs at creation.
Think of it as	Your house.	A room you were put in.

Fill The Room

Every time I look at a problem now I ask one question:

"What can I fit in this room?"

The room is short-lived and its capabilities can be bounded. I'm still measuring startup cost, isolation boundaries, and which workloads fit; that's what Lab is for.

Rooms Building Rooms

Passing the loader binding to a child permits nested fan-out. I have not benchmarked the hundred- or thousand-worker cases; startup overhead, limits, scheduling, and the slowest child determine whether it helps.

WORKER LOADERS AS A PLACE