Cloudflare Dynamic Workers Makes Sandboxes 100x Faster

BBetter Stack
AI/미래기술창업/스타트업컴퓨터/소프트웨어

Transcript

00:00:00(upbeat music)
00:00:01So Cloudflare have recently announced dynamic workers,
00:00:04a lower level worker primitive
00:00:06that can be programmatically created by an existing worker.
00:00:09They're a hundred times faster and more memory efficient
00:00:12than a traditional container since they run on V8 isolates.
00:00:16And because they're so cheap,
00:00:18you can spawn as many as you want
00:00:20for running AI generated code, development previews,
00:00:23custom automations, and much more.
00:00:25I mean, they even said you can run 1 million dynamic workers
00:00:29per second if you wanted to.
00:00:31But does the fact that you can only run
00:00:33JavaScript on them limit their usage?
00:00:36Hit subscribe and let's find out.
00:00:37(upbeat music)
00:00:40Last year, I made a video about Cloudflare sandboxes,
00:00:44which are basically short-lived Linux containers
00:00:47that run on a durable object.
00:00:49If that made no sense to you,
00:00:50then go ahead and check out the video.
00:00:52But they're perfect if you want a full OS container
00:00:55with a file system and the ability to run almost any language
00:00:59and any binary.
00:01:01But if you want something a bit faster,
00:01:03actually a lot faster and much lighter
00:01:06with the ability to run unlimited concurrent sandboxes
00:01:09in something that has the same limits as a regular worker,
00:01:12then you may want to reach for a dynamic worker.
00:01:15Let's go through how to set one up.
00:01:16So here is a basic worker I've just created with Wrangler,
00:01:19filled with some TypeScript errors,
00:01:21maybe because I forgot to run Wrangler types.
00:01:23But in our Wrangler configuration file,
00:01:26I've added this worker loaders array
00:01:28with a binding is called loader.
00:01:30Now this can be called anything you want,
00:01:32but I've chosen loader because it's more conventional.
00:01:34And this binding allows us to create
00:01:37and control other workers.
00:01:38So in the updated code, we have a new worker constant,
00:01:42which uses the loader binding with these values.
00:01:45Now you can kind of imagine this as a Wrangler config file
00:01:49for the nested worker,
00:01:50but here the compatibility date tells the worker
00:01:53what runtime version it should be using.
00:01:55And here is the code that it's going to run.
00:01:57So as you can see, the code is very similar
00:01:59to a worker itself.
00:02:00It has a fetch function
00:02:02with a request env and context arguments.
00:02:05And all it's doing here is responding
00:02:06with hello world from the sandbox.
00:02:08We've then prevented all network access,
00:02:10running the fetch function with the request arguments
00:02:13from the initial worker and returning the results.
00:02:16So if we run our worker locally and then curl localhost,
00:02:19we should see hello from the sandbox.
00:02:21But if we run that same curl request again,
00:02:24we'll get an error.
00:02:24And this is because right now
00:02:26we're loading a brand new worker.
00:02:28But what we can do instead is get an existing worker,
00:02:31which will give a name of worker one
00:02:33and then run the code as an async function.
00:02:35Meaning now if we run curl, we get hello from the sandbox.
00:02:38But if we run it again, it gets the information
00:02:41from the existing worker one sandbox.
00:02:43Now, what I've just shown
00:02:45was of course a very simple example,
00:02:47but you can do some cool things with dynamic workers
00:02:50like define custom bindings,
00:02:52like this chatroom post method to create a stub,
00:02:55which the worker communicates with using cap and web,
00:02:57which yes, we've made a video about,
00:02:59so go and check it out if you're interested.
00:03:00You can use NPM dependencies like Hono
00:03:03and bundle them using the create worker function.
00:03:05And you can even intercept outbound requests
00:03:08to do things like inject credentials.
00:03:10But one of the big reasons for using dynamic workers
00:03:13is to run code generated by AI agents.
00:03:17So let's try and do that.
00:03:18Here is some code from the E2B cookbook
00:03:21that uses the anthropic SDK to run Sonnet 3.5
00:03:25with this system prompt and a custom tool
00:03:28to execute some Python in a Jupyter notebook.
00:03:31So the way this works is it will detect
00:03:33when the custom tool is used
00:03:34and then run that inside the E2B sandbox,
00:03:38which we can see the code for that over here.
00:03:40Now it runs it with this very specific prompt
00:03:42to calculate the value of pi using the Monte Carlo method
00:03:46on a thousand iterations.
00:03:47And because it has access to the file system,
00:03:50it can create this image PNG
00:03:52and save it for it to be downloaded by the user
00:03:54or whatever the user wants.
00:03:56Unfortunately, dynamic workers don't have access
00:03:58to a file system,
00:04:00even though they can create a virtual one
00:04:02with this shell library.
00:04:04But because they run through a worker,
00:04:06we can provide details to it like an R2 bucket,
00:04:08which is Cloudflare's version of S3
00:04:11that the image can be saved in.
00:04:12So if we look at the code,
00:04:14which is similar to the one from E2B,
00:04:16we can first see the system prompt that is being used.
00:04:19And the custom Python execution tool
00:04:22that in this case doesn't use a Jupyter notebook,
00:04:25but does generate an SVG of the visuals.
00:04:28And here we have the code for the worker
00:04:30that as well as running JavaScript can also run Python.
00:04:33So we can see here it's using the Sonnet 4.6.
00:04:35Here's the prompt that gets used.
00:04:37Here the agent's code gets executed in the sandbox.
00:04:41And the response from the sandbox
00:04:43goes back to the main worker,
00:04:45which looks through it for the SVG code
00:04:47and then saves it in R2.
00:04:49So if we visit that URL, it takes a while,
00:04:51but it does generate the page
00:04:53with the relevant information from Claude.
00:04:55And if we scroll down,
00:04:56we can see this SVG that's being loaded from R2.
00:05:01It does look very different from the E2B one,
00:05:03but I trust that Claude Sonnet
00:05:04has produced the correct information.
00:05:06And of course I did mention that it's also possible
00:05:09to programmatically spawn as many dynamic workers as you want,
00:05:13which you can do with code like this.
00:05:16That is a for loop that creates brand new workers
00:05:19based on the value from the API.
00:05:21And it also checks if a worker already exists
00:05:23and reuses it if it does.
00:05:25The code it runs is basically a console log
00:05:27and a response from the worker
00:05:29with the specific ID of the worker
00:05:31based on the index from the for loop.
00:05:32So with the code running,
00:05:34I could spawn 50 brand new dynamic workers
00:05:36and we can see they all get created instantly.
00:05:40That was very fast.
00:05:41Now let's try it with 10,000,
00:05:43but I'm not gonna do it locally
00:05:44because I don't want to blow up my machine.
00:05:46So I've deployed my parent worker to Cloudflare
00:05:49so I can use their infrastructure.
00:05:50So here I'm going to spawn 10,000 different workers.
00:05:53And if I hit enter, they all get made insanely quickly.
00:05:56We can see there's a page of 30 of them over here
00:05:59so I can keep going to view all the different worker IDs.
00:06:03And actually the more I go, the more pages it shows.
00:06:05And I can communicate with a specific worker
00:06:07like worker 1156,
00:06:09which responds with hello from worker 1156.
00:06:12So that's a quick overview of dynamic workers
00:06:15that are already being used by Cloudflare for code mode
00:06:18and Zite for running LLM generated apps.
00:06:21But I should mention that while they're free now,
00:06:24they won't be free forever.
00:06:25So even though you can run a million dynamic workers
00:06:28per second, you may want to hold off
00:06:30unless you have deep pockets.
00:06:32And while we're on the topic of Cloudflare,
00:06:34if you want to learn more about their open source VIVE SDK
00:06:38that lets you build app generators like vZero and Lovable,
00:06:42then check out the next video.

Key Takeaway

Cloudflare Dynamic Workers provide an incredibly fast, scalable, and cost-effective way to run programmatically-created sandboxes, enabling high-performance execution of AI-generated code and custom automations.

Highlights

Cloudflare Dynamic Workers are a new low-level primitive that can be programmatically created by existing workers.

They are 100x faster and more memory-efficient than traditional containers because they utilize V8 isolates instead of full operating systems.

Users can potentially spawn up to 1 million dynamic workers per second for tasks like AI-generated code execution and custom automations.

Dynamic workers allow for granular control, including custom bindings, NPM dependency bundling, and intercepting outbound requests.

While they lack a native file system, they can interact with Cloudflare R2 buckets to store and retrieve persistent data like images or SVGs.

The technology is already being implemented in production by platforms like Cloudflare's Code Mode and Zite for running LLM-generated applications.

Timeline

Introduction to Cloudflare Dynamic Workers

Cloudflare has introduced dynamic workers, a low-level worker primitive that can be programmatically created by another worker. These workers are 100x faster and far more memory-efficient than standard containers because they operate on V8 isolates rather than full Linux operating systems. Because they are so lightweight, they are ideal for running AI-generated code, development previews, and custom automations. The speaker notes that users can potentially spawn up to one million of these workers per second if needed. This section establishes the high performance and low overhead that makes dynamic workers a powerful new tool in the Cloudflare ecosystem.

Comparison with Traditional Sandboxes

The speaker compares dynamic workers to Cloudflare's existing sandbox solution, which uses short-lived Linux containers running on durable objects. While the traditional sandbox is perfect for full OS capabilities, file systems, and running any binary, dynamic workers offer a significantly faster and lighter alternative. Dynamic workers allow for unlimited concurrent sandboxes within the same limits as a regular worker, providing a more streamlined execution environment. This section explains when to choose a dynamic worker over a full container, highlighting the trade-offs between speed and OS-level features. It sets the stage for the technical setup and configuration steps that follow in the demonstration.

Technical Setup and Basic Implementation

Setting up a dynamic worker involves adding a worker loaders array with a binding, such as "loader", to the Wrangler configuration file. This binding allows a parent worker to create and control nested workers using code that looks remarkably similar to standard worker functions. The speaker demonstrates how to define compatibility dates and the specific JavaScript code that the dynamic worker will run, such as responding with a simple "hello world". A crucial feature mentioned is the ability to assign names to workers, allowing developers to reuse specific sandboxes across multiple requests. This section provides a practical look at how the loader binding facilitates the programmatic instantiation and persistence of these high-speed workers.

Advanced Features and Custom Bindings

Beyond simple execution, dynamic workers support advanced capabilities like defining custom bindings and using NPM dependencies like Hono. The speaker explains that dependencies can be bundled using the create worker function, providing flexibility for complex application logic. Additionally, developers can intercept outbound requests from the dynamic worker to inject credentials or manage security protocols. The section also mentions the use of Cap'n Proto for communication between the worker and other services. These features illustrate that despite being a "lower-level primitive", dynamic workers are highly extensible and capable of handling production-grade application requirements. This flexibility is a key selling point for developers building complex serverless architectures.

Running AI-Generated Code and File Storage

A major use case for dynamic workers is executing code generated by AI agents, such as those using the Anthropic SDK. The speaker demonstrates this by having an agent generate code to calculate the value of pi and produce a visual representation. Although dynamic workers do not have a native file system, the speaker shows how to work around this by using Cloudflare R2 buckets for storage. In the example, the AI agent generates SVG code which is then saved to R2 and displayed on a web page. This highlights the synergy between Cloudflare's various services and how they can be combined to create a complete AI application environment. The section concludes with a verification that the generated output from Claude Sonnet is accurate and accessible.

Scalability Testing and Future Outlook

To showcase the extreme scalability of the platform, the speaker performs a test spawning 10,000 unique dynamic workers on Cloudflare's infrastructure. The workers are created almost instantly, and the speaker demonstrates that they can communicate with a specific worker ID immediately after creation. While this power is impressive, the speaker cautions that while currently free, these workers will eventually have a cost associated with them. The video mentions that companies like Zite are already using this technology for running LLM-generated applications. Finally, the speaker points viewers toward additional resources on Cloudflare's open-source VIVE SDK for building app generators. This closing section reinforces the scale at which this technology can operate while offering a pragmatic view of its future commercial release.

Community Posts

View all posts