Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -67,17 +67,33 @@ To upload and deploy the user Worker to the dispatch namespace, running the foll
npx wrangler deploy --dispatch-namespace testing
```

### 4. Create a dispatch Worker
### 4. Create a dynamic dispatch Worker
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never loved this "dispatch Worker" phrasing. It makes it seem like this Worker is special, when it really isn't, and I've seen that confuse users a few times now. This is just a regular Worker which happens to have a WfP namespace binding. I can choose to call a user Worker in that namespace, possibly with a request over fetch. But I don't have to, and it's not like I concede everything over to it when I do so. I can do other stuff before and after calling it! I can do RPC!

It's fine in a guide specifically about how to create a hosting platform where this request-delegation is the pattern, but using it as the "getting started" guide for all of Workers for Platforms does WfP a disservice, imo. It doesn't very accurately portray a setup for hosted bots, or LLM-authored script isolation/tool calling or anything like that.


[Dispatch Workers](/cloudflare-for-platforms/workers-for-platforms/reference/how-workers-for-platforms-works/#dynamic-dispatch-worker) are used to execute user Workers from the dispatch namespace. You will now create a dispatch Worker and add logic it needs to route to the user Worker created in step 2.
A [dynamic dispatch Worker](/cloudflare-for-platforms/workers-for-platforms/reference/how-workers-for-platforms-works/#dynamic-dispatch-worker) is a specialized routing Worker that directs incoming requests to the appropriate user Workers in your dispatch namespace. Instead of using [Workers Routes](/workers/configuration/routing/routes/), dispatch Workers let you programmatically control request routing through code.

#### Why use a dynamic dispatch Worker?

* **Scale**: Perfect for routing thousands or millions of hostnames to different Workers, without needing to rely on [Workers Routes](/workers/configuration/routing/routes/)
* **Custom routing logic**: Write code to determine exactly how requests should be routed. For example:
* Map hostnames directly to specific Workers
* Route requests based on subdomains
* Use request metadata or headers for routing decisions

* **Add platform functionality**: Build in additional features at the routing layer.
* Run authentication checks before requests reach user Workers
* Sanitize incoming requests
* Attach useful context like user IDs or account information
* Transform requests or responses as needed

**To create your dynamic dispatch Worker:**

Navigate up a level from your user Worker's project directory:

```sh
cd ..
```

Create your dispatch Worker. In this example, the dispatch Worker is called `my-dispatcher`.
Create your dynamic dispatch Worker. In this example, the dispatch Worker is called `my-dispatcher`.

<PackageManagers type="create" pkg="cloudflare@latest" args={"my-dispatcher"} />

Expand Down Expand Up @@ -121,8 +137,9 @@ export default {
},
};
```
This example shows a simple dynamic dispatch Worker that routes all requests to a single user Worker. For more advanced routing patterns, you could route based on hostname, path, custom metadata, or other request properties.

Deploy your dispatch Worker:
Deploy your dynamic dispatch Worker:

```sh
npx wrangler deploy
Expand Down
Loading