Ability to deploy and run Workers-for-Platforms scripts fully-locally with wrangler

[dmaretskyi]

Describe the solution

Problem

We are using Workers-for-Platforms (W4P) in our project, where users write scripts and deploy them via either our web app.

Currently, the workflow looks like this:

1. User writes a script.
2. The script is deployed through our API.
3. Our API interacts with the Cloudflare API to deploy the script to a Workers-for-Platforms namespace.
4. Scripts can then be invoked through the Dispatch Namespace API in the W4P SDK.
5. When invoked, scripts also receive bindings to other services (e.g., our database).

This works fine in production, but testing locally is very difficult:

• The only way to run Workers-for-Platforms in Dispatch Namespaces right now is through the Wrangler CLI with a --dispatch-namespace argument.
• That means testing requires going through Wrangler directly instead of keeping our current workflow of deploying via our API.

We would like to run this entire workflow locally:

• Run the database service locally.
• Run the deployment API locally.
• Use that local API to deploy scripts into a local W4P Dispatch Namespace.
• Have Wrangler run the Workers locally, with service bindings available (e.g., to the local database).

---

Motivation

• Enable local development and testing of the entire W4P workflow without relying on Cloudflare’s remote API.
• Ensure that developers can use the same workflow locally and in production (API-driven deployment, Dispatch Namespace invocation, service bindings).
• Improve speed and developer experience (no remote deployments needed for testing).

---

Proposed Solution

Introduce a way to deploy Workers-for-Platforms scripts fully locally via Wrangler.

For example:

• Add a method such as DispatchNamespace.deploy() that:
  • Deploys a Worker to the local WorkerD environment.
  • Persists it in the local state of the Dispatch Namespace (Wrangler + WorkerD state).
• Allow invoking that Worker locally via the Dispatch Namespace API.
• Ensure service bindings (e.g., database) are available in the local environment.

Code snippet:

export default {
  async fetch(req, env) {
    const deployResult = await env.DISPATCHER.deploy(manifest, modules);
    ...
  },
};

When deployed to a production environment this would use the "upload script to Dispatch Namespace API" and when running locally this would upload the worker modules to a locally running instance of workerd.

---

Considerations

• Local persistence of Dispatch Namespaces and their deployed Workers would need to be defined and stored in Wrangler state.