Cloudflare gets native Rust running on Workers

Cloudflare has opened up an experimental route to running native Rust — Tokio and all — on its Workers platform, and someone has already built a fully playable Minecraft server inside a single Durable Object to prove it. The company has published the first public preview of first-class support for the Emscripten wasm32-unknown-emscripten compiler target in wasm-bindgen, the open source toolchain that powers Rust WebAssembly applications on the V8-based Workers runtime.

The blocker was never ambition, it was plumbing. Rust on Workers had to be compiled for the bare wasm32-unknown-unknown target, so anything that expects an operating system underneath it — sockets, threads, a filesystem — tended to fall over. Emscripten already pretends to be a POSIX-ish system, which is why C and C++ code ports to the web so easily. Teaching wasm-bindgen to build for that target means a much larger slice of the Rust ecosystem can come along.

Google started it, Cloudflare finished the plumbing

The effort began at Google. Mitch Foley on the Portable Toolchains team ran into the need for Rust WebAssembly toolchains to interoperate with C++ after another internal team wanted wasm-bindgen to drive its builds and produce the companion JavaScript. Both toolchains assumed they were the one in charge of loading JavaScript, so teams had to pick one and stick to it. The fix was to split the work: Emscripten drives the build, loads the WebAssembly module and provides the companion JavaScript, while wasm-bindgen emits a smaller, portable version of its bindings that Emscripten can link directly. The result lands as a new -sWASM_BINDGEN configuration. C++ Emscripten code can now be built against static wasm-bindgen Rust code, and Rust applications using wasm-bindgen can be built for the Emscripten target, with both binding layers working at once.

Tokio was the genuinely hard part

Workers are single-threaded and live inside a JavaScript event loop, while Tokio's async model is built around blocking operations being parked on real threads. Cloudflare fleshed out two answers. The first is WebAssembly JavaScript Promise Integration, which lets a blocking WebAssembly call suspend its own stack and hand control back to the JavaScript event loop, then resume later — exactly what a parked thread would have done. The problem there is that a JavaScript stack switch is not a thread switch, so two suspended stacks share the same thread-local runtime context; Cloudflare's pre-release patchset swaps that context on every entry, exit, suspend and resume. The second approach is more interesting: a LocalEventLoop design where a Tokio runtime's wait step is replaced with a wake signal owned by the host. A spawn, a timer expiring or a socket becoming readable all wake the host's loop instead of unparking a thread, and the same shape embeds into a GTK main loop, a Win32 message pump or a Cocoa run loop.

Sockets needed a bridge. Emscripten only supported poll(), not the epoll that Tokio's I/O driver wants, and Cloudflare needed its TCP sockets API wired in. Rather than write one, the team reused the node:net API it already implements for Node.js compatibility. That work landed as more than 40 pull requests to Emscripten and shipped as the -sNODERAWSOCKETS compilation option, which turns on epoll, TCP, UDP and Unix sockets for Emscripten applications in Node.js — and, because Workers implements the same node:net API, on Workers too. A proposal for an emscripten_epoll_add_listener API followed so readiness can reach the event loop as a JavaScript callback.

Then they ran a Minecraft server on it

To prove the target out, Cloudflare's Dan Lapid implemented a Pumpkin Minecraft server running inside a Durable Object over a single weekend. Pumpkin is a Rust Minecraft server built on Tokio and designed for multi-core machines: world generation runs on a dedicated thread pool while the game tick loop and chunk scheduler each get their own operating system thread. A Durable Object has exactly one thread, so every one of those had to become cooperative instead. World saves go through ordinary file calls that Emscripten forwards to the node:fs compatibility layer, which Lapid's own filesystem mount library then points at persistent storage. Networking needed no changes at all: each player connection arrives through Workers TCP ingress at the worker's connect() handler, is forwarded into the Durable Object, and is handed to a net.Server listening inside the object. Multiplayer included.

Everything is available today for experimental use, including worked examples for TCP sockets on Workers with Emscripten and Tokio. Tokio's own support patchsets are still being reviewed upstream, although the first target support patch for wasm32-unknown-emscripten has already landed in Tokio, and finalising the reentrant design is a joint effort with the Tokio and Emscripten maintainers.

Our opinion

Cloudflare has spent years quietly turning the edge into something that behaves like a normal computer, and this is the most developer-friendly version of that pitch yet. The clever part is not that Rust runs on Workers — it already did — but that Cloudflare fixed the compatibility grudges upstream instead of wrapping them in a proprietary runtime and calling it a feature. Forty-odd pull requests into Emscripten and a Tokio patchset under review is the sort of unglamorous work that makes a platform worth targetting.

Do not redeploy production workloads onto this yet. The word Cloudflare keeps using is experimental, Tokio support is still being upstreamed, and the LocalEventLoop route panics rather than parks when you call block_on, which is exactly the kind of detail that bites at 2am. But as a signal of where serverless is heading, it lands hard: a persistent, multiplayer Minecraft server with real TCP sockets, running in a single-threaded isolate, is not a demo anyone expected to see this year.