From Dashboard Editor to wrangler dev

In 2018, getting started with Cloudflare Workers meant living in the dashboard's code editor. You could tweak a script in a text area, hit "Update," and see the result. For anything beyond a single-file experiment, though, the workflow quickly became painful.

Building a real project required a manual dance: edit code, run a webpack build, copy the entire bundled output from ./dist/worker.min.js, paste it into the dashboard editor, click update, and only then investigate behavior. Two gaps made this especially rough:

  • Adding a console.log to inspect a variable meant a full rebuild cycle of two to three minutes.
  • Testing with tools like curl or Postman was impossible without deploying, because the preview UI lived in a nested iframe on the dashboard.

The saving grace was that Workers deployed globally in seconds, so iterating against production was fast. Still, the experience left a lot to be desired.

Wrangler Appears

Cloudflare soon shipped Wrangler, the official Workers CLI. Its wrangler preview command automated the build-copy-paste-update loop, opening a browser window with live logs and a test harness. An intern project added wrangler preview --watch to refresh that preview on code changes. But the iframe limitation remained—no custom HTTP clients, no localhost.

The next step was to build a real local development server. Since Wrangler is written in Rust, the team could stand up a server on localhost and proxy requests to a Cloudflare-hosted preview session.

How wrangler dev Works

The proof-of-concept flow for wrangler dev:

  1. Build the Worker.
  2. Upload it via the Cloudflare API as a previewable Worker.
  3. The API creates a preview session and returns an access token.
  4. Start listening for HTTP requests at localhost:8787.

Incoming requests get transformed before being forwarded:

  • Headers are prefixed with cf-ew-raw- (so X-Auth-Header becomes cf-ew-raw-X-Auth-Header).
  • The URL is rewritten to https://rawhttp.cloudflareworkers.com/${path}.
  • The Host header is set to rawhttp.cloudflareworkers.com.
  • A cf-ew-preview header carries the access token from step 3.

The response is reverse-transformed: headers without the cf-ew-raw- prefix are discarded, and the prefix is stripped from the rest. The hard part—the API for preview sessions—already existed for the dashboard UI; Wrangler just needed to talk to it. The Rust HTTP library hyper handled the plumbing.

Adding Log Streaming

The initial version handled HTTP cleanly, but debugging still required the browser-based preview to see console.log output. For a tool named wrangler dev, logs needed to stream to the terminal.

Workers runs on V8, and the runtime can expose a WebSocket speaking the Chrome Devtools Protocol. In the dashboard preview, that's how the console view gets its data—the same protocol Chrome DevTools uses.

You can observe this yourself:

  1. Open Chrome DevTools.
  2. Go to the Network tab.
  3. Use the funnel filter icon, then select "WS" to show only WebSocket connections.
  4. Reload the page and pick the /inspect entry to see the message stream.

The browser sends messages to enable DevTools domains, and the runtime responds with events like console output. For Wrangler, the initial goal was simpler: open a WebSocket, send Runtime.enable, and receive console.log messages.

That turned out to be the easy part. Most Chrome DevTools Protocol libraries target other languages, and Rust's WebSocket ecosystem had cross-platform TLS issues. The team ended up implementing the needed protocol pieces in Rust themselves. It's early days, but getting the tool into developers' hands mattered more than polishing every feature first.

Status and Next Steps

wrangler dev is in alpha. The quickest path to trying it is the Workers Quick Start, then the wrangler dev docs. Feedback and bug reports are welcome in the open-source Wrangler repository, and the project has a public contribution guide for those who want to help build it out.