Skip to content

Commit 7b7b7a5

Browse files
committed
docs: multi workers development
1 parent 728882a commit 7b7b7a5

File tree

1 file changed

+99
-0
lines changed

1 file changed

+99
-0
lines changed
Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
pcx_content_type: concept
3+
title: Developing with multiple Workers
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 want 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 command
15+
16+
<Aside type="tip">
17+
18+
We recommend this approach as the default for most development workflows as it ensures the best compatibility with bindings.
19+
20+
</Aside>
21+
22+
You can run multiple Workers in a single dev command by passing multiple configuration files to your dev server:
23+
24+
**Using Wrangler**
25+
26+
<PackageManagers
27+
type="exec"
28+
pkg="wrangler"
29+
args="dev -c ./app/wrangler.jsonc -c ./api/wrangler.jsonc"
30+
/>
31+
32+
The first config (`./app/wrangler.jsonc`) is treated as the primary Worker, exposed at `http://localhost:8787`. Additional configs (e.g. `./api/wrangler.jsonc`) run as auxiliary Workers, available via service bindings or tail consumers from the primary Worker.
33+
34+
**Using the Vite plugin**
35+
36+
Configure `auxiliaryWorkers` in your Vite configuration:
37+
38+
```js title="vite.config.js"
39+
import { defineConfig } from "vite";
40+
import { cloudflare } from "@cloudflare/vite-plugin";
41+
42+
export default defineConfig({
43+
plugins: [
44+
cloudflare({
45+
configPath: "./app/wrangler.jsonc",
46+
auxiliaryWorkers: [
47+
{
48+
configPath: "./api/wrangler.jsonc",
49+
},
50+
],
51+
}),
52+
],
53+
});
54+
```
55+
56+
Then run:
57+
58+
<PackageManagers type="exec" pkg="vite" args="dev" />
59+
60+
**Use this approach when:**
61+
62+
- You want the simplest setup for development
63+
- Workers are part of the same application or codebase
64+
- You need to access a Durable Object namespace from another Worker using `script_name`, or setup Queues where the producer and consumer Workers are seperated.
65+
66+
## Multiple dev commands
67+
68+
You can also run each Worker in a separate dev commands, each with its own terminal and configuration.
69+
70+
<PackageManagers
71+
comment="Terminal 1"
72+
type="exec"
73+
pkg="wrangler"
74+
args="dev -c ./app/wrangler.jsonc"
75+
/>
76+
77+
<PackageManagers
78+
comment="Terminal 2"
79+
type="exec"
80+
pkg="wrangler"
81+
args="dev -c ./api/wrangler.jsonc"
82+
/>
83+
84+
These Workers run in different dev commands but can still communicate with each other via service bindings or tail consumers **regardless of whether they are started with `wrangler dev` or `vite dev`**.
85+
86+
<Aside type="note">
87+
88+
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`. This allows you to keep tightly coupled Workers running under a single dev command, while keeping independent or shared Workers in separate ones. However,
89+
running `wrangler dev` with multiple configuration files (e.g. `wrangler dev -c ./app/wrangler.jsonc -c ./api/wrangler.jsonc`) does **not** support cross-process bindings at the moment.
90+
91+
</Aside>
92+
93+
**Use this approach when:**
94+
95+
- You want each Worker to be accessible on its own local URL during development, since only the primary Worker is exposed when using a single dev command
96+
- Each Worker has its own build setup or tooling — for example, one uses Vite with custom plugins while another is a vanilla Wrangler project
97+
- You need the flexibility to run and develop Workers independently without restructuring your project or consolidating configs
98+
99+
This setup is especially useful in larger projects where each team maintains a subset of Workers. Running everything in a single dev command might require significant restructuring or build integration that isn't always practical.

0 commit comments

Comments
 (0)