Skip to content

Commit 9c8216b

Browse files
committed
draft docs: multi workers development
1 parent 728882a commit 9c8216b

File tree

1 file changed

+138
-0
lines changed

1 file changed

+138
-0
lines changed
Lines changed: 138 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,138 @@
1+
---
2+
pcx_content_type: concept
3+
title: Multi Workers development
4+
sidebar:
5+
order: 3
6+
head: []
7+
description: Learn how to develop with multiple Workers using different approaches and configurations.
8+
---
9+
10+
import { Aside, PackageManagers, Steps, WranglerConfig } from "~/components";
11+
12+
When building complex applications, you may need to run multiple Workers during development. This guide covers the different approaches for running multiple Workers locally and when to use each approach.
13+
14+
## Single dev session
15+
16+
You can run multiple Workers in a single dev session by passing multiple configuration files to your dev server.
17+
18+
<Steps>
19+
20+
1. Create separate configuration files for each Worker:
21+
22+
**Primary Worker**
23+
24+
<WranglerConfig>
25+
```toml
26+
name = "app-worker"
27+
main = "./src/index.ts"
28+
29+
[[services]]
30+
binding = "API"
31+
service = "api-worker"
32+
```
33+
</WranglerConfig>
34+
35+
36+
**Auxiliary Worker**
37+
38+
<WranglerConfig>
39+
```toml
40+
name = "api-worker"
41+
main = "./src/index.ts"
42+
```
43+
</WranglerConfig>
44+
45+
2. Start a dev session:
46+
47+
**Using Wrangler**
48+
49+
<PackageManagers
50+
type="exec"
51+
pkg="wrangler"
52+
args="dev -c wrangler.jsonc -c ../api/wrangler.jsonc"
53+
/>
54+
55+
The first config is treated as the primary Worker, exposed at `http://localhost:8787`. Additional configs run as auxiliary Workers, available via service bindings or tail consumers from the primary Worker.
56+
57+
**Using the Vite plugin**
58+
59+
Configure `auxiliaryWorkers` in your Vite configuration:
60+
61+
```js title="vite.config.js"
62+
import { defineConfig } from "vite";
63+
import { cloudflare } from "@cloudflare/vite-plugin";
64+
65+
export default defineConfig({
66+
plugins: [
67+
cloudflare({
68+
configPath: "./wrangler.jsonc",
69+
auxiliaryWorkers: [
70+
{
71+
configPath: "../api/wrangler.jsonc",
72+
},
73+
],
74+
}),
75+
],
76+
});
77+
```
78+
79+
Then run:
80+
81+
<PackageManagers type="exec" pkg="vite" args="dev" />
82+
83+
</Steps>
84+
85+
Use this approach when:
86+
87+
- Workers are closely related or part of the same application
88+
- You want the simplest development setup
89+
- You need to access a Durable Object namespace from another Worker using `script_name`
90+
91+
## Multiple dev sessions
92+
93+
You can also run each Worker in a separate dev session, each with its own terminal and configuration.
94+
95+
```sh
96+
# Terminal 1
97+
cd app-worker
98+
wrangler dev
99+
```
100+
101+
```sh
102+
# Terminal 2
103+
cd api-worker
104+
wrangler dev
105+
```
106+
107+
These Workers run in different dev sessions but can still communicate with each other via service bindings or tail consumers **regardless they are started with `wrangler dev` or `vite dev`**.
108+
109+
Use this approach when:
110+
111+
- Each Worker uses a different build configuration
112+
- Different teams maintain the Workers
113+
- A Worker only occasionally accesses another, and you prefer the flexibility to run them separately
114+
115+
While this setup offers flexibility, there are some limitations to be aware of when using bindings across Workers running in separate dev sessions:
116+
117+
| Bindings | Wrangler (single config) | Wrangler (multi config) | Vite (no auxiliaryWorkers) | Vite (with auxiliaryWorkers) |
118+
|------------------|:-------------------------:|:----------------------------:|:--------------------------:|:----------------------------:|
119+
| Service Bindings || 🔜 |||
120+
| Durable Objects | ⚠️ ||||
121+
| Tail Consumers || 🔜 |||
122+
123+
✅ = Full support.<br>
124+
⚠️ = Fetch only. RPC is not supported.<br>
125+
🔜 = No support yet. Coming soon.<br>
126+
❌ = Not supported.<br>
127+
128+
## Hybrid approach
129+
130+
You can also combine both approaches — for example, run a group of Workers together through `vite dev` using `auxiliaryWorkers`, while running another Worker separately with `wrangler dev`.
131+
132+
This allows you to keep tightly coupled Workers in a single dev session, while treating independent or shared Workers as separate sessions. However, the same limitations for bindings apply when Workers are run across multiple dev sessions. Refer to the table above for what's supported when Workers aren't started in the same dev command.
133+
134+
Use this approach when:
135+
136+
- You have an independent Worker that is shared across multiple applications
137+
- You are integrating with a legacy Worker that you don't want to refactor yet
138+
- Your project structure benefits from the flexibility of both approaches

0 commit comments

Comments
 (0)