Cloudflare announced the first public experimental preview of support for the wasm32-unknown-emscripten compilation target within the wasm-bindgen toolchain and the Rust Workers environment. This path enables a larger number of native Rust applications and libraries to be built and run as WebAssembly on the global Workers platform, rather than being limited to libraries already compatible with the traditional WebAssembly model.
This work represents an integration between Emscripten, which provides a layer for connecting native code to the web environment and emulating functions such as the filesystem, timers, and sockets, and wasm-bindgen, which handles creating bindings between Rust and JavaScript. Under the new changes, both the Rust compiler and the Emscripten compiler can use each other’s bindings layer within the same build process.
Expanding Rust Library Compatibility
Cloudflare says the initial tests showed improved compatibility with Rust libraries, including low-level libraries. Libraries such as libc, socket2, and Mio required limited modifications to add the Emscripten target to their platform conditions. The most complex library was Tokio, because Workers runs on a single thread within a JavaScript event loop, while Tokio traditionally relies on blocking the thread while waiting for input and output operations.
To address this difference, Cloudflare is working on two paths. The first uses WebAssembly JavaScript Promise Integration, which allows the WebAssembly stack to be suspended and control to be returned to the JavaScript event loop. This requires careful management of the thread-local context when stacks are suspended and resumed. The second path proposes a LocalEventLoop pattern for Tokio, in which ready tasks are executed through a drive() operation and waiting is replaced with a wake-up signal to the host event loop.
Socket and TCP Networking Support
Networking support was an additional challenge, as Tokio relies on epoll_wait() through Mio, while Emscripten provided limited support for poll() and a layer for emulating WebSocket. Cloudflare therefore contributed more than 40 pull requests to Emscripten to add a -sNODERAWSOCKETS layer, which provides support for epoll, TCP, UDP, and Unix sockets through the node:net interface.
Because Workers provides compatibility with Node.js interfaces, the same bridge can be used within the platform, without adding separate custom interfaces between Emscripten and Cloudflare. These capabilities remain experimental, and some Tokio patches are still under review before they are finally merged into the project.
Practical Test Using a Minecraft Server
To test the extent of compatibility, Cloudflare engineer Dan Lapid ran the Rust-written Minecraft server known as Pumpkin inside a Durable Object. Because a Durable Object runs on a single thread, the game loops, region scheduling, and Rayon tasks were converted into cooperative tasks within a Tokio loop instead of relying on separate operating-system threads.
The server used the filesystem through Node.js interfaces, with files stored in the Durable Object’s SQLite through the worker-fs-mount library. Player connections also passed through TCP ingress and then to a TCP server inside the object. According to Cloudflare, this made it possible to run a multiplayer Minecraft server while preserving state and restarting the object from the stored world.
Why Does This Development Matter?
The practical value of the change lies not merely in adding a new compilation target, but in reducing the number of libraries and applications that need to be rewritten to run on Workers. However, Cloudflare describes the support as experimental and pre-release, while the new Tokio design, JSPI support, and some Emscripten integrations are still under development and upstream review. The path therefore opens the door to experiments running native Rust applications, but it has not yet proven to be a complete and stable alternative for all traditional runtime environments.