Beyond WASI: Running any Rust application in the browser with BrowserPod 3.0<br>and adds "filtering-pending" to before the browser paints any body<br>content. The style block below uses this class to hide [data-filter-section]<br>(the filter bar + card grid on showcase/blog pages).

ProductFilter.svelte initialises its filter state synchronously from the URL<br>(outside onMount), so its first rendered output already shows the correct<br>filtered state. A $effect removes "filtering-pending" after that first<br>render, so the section fades in cleanly.

This is the same no-FOUC pattern used for dark-mode theme scripts.<br>--> Back to blog<br>Beyond WASI: Running any Rust application in the browser with BrowserPod 3.0<br>Yuri Iozzelli<br>August 13, 2026<br>X Facebook Y Combinator LinkedIn Reddit Email WhatsApp

Today we are releasing BrowserPod 3.0, with full support for running any Rust<br>application in the browser, many fixes for Node.js, and initial Python support.

Our Rust support goes beyond what can normally be achieved with the existing Wasm<br>targets in terms of standard library features and third-party crate compatibility.<br>Programs can access the filesystem, make network requests, run subprocesses, and interact<br>with concurrently running applications. All of this without changing a single line of code !

In the demo below, you can see the preview version of Yarn 6 (written in Rust) installing an NPM project:

What is BrowserPod

BrowserPod is an in-browser code sandbox. Its goal is to make it possible to run any Linux application in modern browsers by compiling the application to WebAssembly and providing the full Linux syscall interface.

It provides an efficient, locally persistent virtual filesystem, outbound internet access for downloading packages or calling APIs, and inbound connections for exposing local development servers. BrowserPod supports real parallelism by running each thread or process on an independent Worker, while providing a consistent view of the system to all the running programs. For all purposes, it can be considered an OS kernel for the Web platform, implemented in WebAssembly.

This set of features makes BrowserPod uniquely suited for safe in-browser agentic code execution, web-based IDEs and development environments, interactive docs and live demos, educational platforms, and other applications that benefit from sandboxed execution inside a web app.

Why Rust now?

BrowserPod’s ambition is to run an entire Linux userspace in the browser. For the most part, this used to mean compiling a bunch of C/C++ projects.<br>Most dynamic languages, such as Python, JavaScript or Ruby run on top of interpreters and runtimes that are also, most usually, written in C/C++, and so having a C/C++ toolchain (in our case, Cheerp) would get you very far.

Nowadays, this is less and less true. Popular languages like Rust and Go are compiled ahead of time like C/C++, and have their own toolchains.

Many build tools for Node.js in particular are being written (or rewritten) in Rust.<br>For these reasons, Rust was always part of our roadmap for BrowserPod, but we decided to prioritize it over Python and Ruby thanks to a concrete use case from a member of our community on Discord.

One maintainer of the Yarn package manager expressed interested in building an interactive documentation page, featuring a real yarn build, and running on BrowserPod. But contrarily to previous versions, which were JavaScript, the upcoming Yarn 6 release is built in Rust.

This is one of the use cases where we think that BrowserPod can really shine, and so we started working on it right away! It took us a week to get to a first prototype and we could immediately see the potential, but there were more moving parts that we had expected.

What does it mean to “support” Rust

In previous releases of BrowserPod we focused on Node.js. Our users did not have to worry about compiling for the BrowserPod target, since we provide a pre-compiled Node.js build ourselves.

Rust programs behave very differently, since they need to be compiled ahead of time using rustc. As things stand today, the user needs to compile the program offline and add the resulting binary to the Pod. Interestingly, rustc itself is written in Rust. In principle, we could allow users to compile their Rust programs directly in the browser. We need a few additional features to achieve this objective, but it will happen in the near future.

Effectively “supporting Rust” today boils down to providing a Rust toolchain that can produce Wasm binaries for the BrowserPod target.

Existing Rust WebAssembly targets

Fortunately, we could start from solid ground. Rust already supports a variety of Wasm targets, namely:

wasm32-unknown-unknown: This target is the most barebones and platform agnostic. By itself, it makes no assumptions about the environment it runs in, but crates like wasm-bindgen and web-sys make it possible to communicate with the JS and Web environment. This target makes sense if you are deliberately...