Today we’re releasing BrowserPod 1.0: a browser-based code sandbox for running untrusted code next to the user, with near-native speed, extremely low latency, strong data locality and very low running costs, while maintaining high fidelity with native/cloud execution.

This first release ships with BrowserPod for Node.js, the first engine in a broader, language-agnostic platform: a universal execution layer for browser-based compute. Support for Python, Ruby, Go and Rust engines will be released in the next six months. Linux-class sandboxes, powered by CheerpX, will be added by the end of 2026.

BrowserPod relies on WebAssembly to provide high-fidelity, fully compiled runtime engines for multiple languages that are robust to real-world computationally heavy, multithreaded and multiprocess loads.

To get an idea of what BrowserPod can do, feel free to experiment with the Node.js REPL below, running completely on your device.

Why BrowserPod — and why now?

Increasingly, software has a need to safely execute untrusted code: generated by models, written by users, pulled from libraries, or assembled by agents. That’s changing the economics and the threat model of code execution. The key question is not how to run code, but where to run it, what it can reach, and what it costs to operate at scale.

Cloud sandboxes are a common, default solution. But they also come with recurring tradeoffs:

• Latency (spinning up sandboxes, network rounds trips, cold starts)
• Cost (per-session infrastructure adds up fast)
• Data exposure (shipping inputs/outputs to remote systems expands the surface area)

BrowserPod flips the model: keep execution inside the browser, leveraging WebAssembly and the browser’s security model, while still providing a Linux-compliant environment (filesystem, processes, and networking).

What you can build with it (today)

BrowserPod is designed to be a universal compute platform, powered by multiple runtime engines, starting with Node.js, but expanding to other languages very rapidly.

This technology is the culmination of more than 10 years of unique experience that we have in building browser-based development tools and virtual machines based on WebAssembly.

Here are the use cases that shaped the architecture from day one:

1) In-browser agentic coding

Run AI-generated code in a sandbox next to the user, with fast startup, strong isolation, and better performance than typical cloud-based sandboxes. This is the most direct path to cutting per-session sandbox costs while tightening security boundaries and improving performance.

2) Web-based IDEs and full-stack dev environments

Power “real” development workflows in the browser: package installs, dev servers, build tools, previews. All with high fidelity.

3) Interactive docs and “live” library demos

Turn documentation into a runnable environment: examples people can modify, execute, and share without leaving the page.

4) Education at scale

High-fidelity environments with minimal operational overhead. If you can avoid per-student sandboxes, you can meaningfully change what’s economically feasible.

With BrowserPod, not only can compute stay local, but user data as well, making privacy-first applications much more practical and removing any jurisdiction risk connected to shipping user information to the cloud. Paired with the already visible trend towards the on-device execution of agentic models, we envision a world in which BrowserPod can power local-only personal agentic workloads in absolute privacy.

The feature that unlocks a lot: Portals

BrowserPod includes Portals, a controlled networking feature that lets you expose services running inside a Pod through shareable URLs.

That means you can run a dev server inside its sandbox and still get:

• Live previews
• Interactive demos
• Collaborative troubleshooting
• Shareable “click-to-open” environments

All this, without computation being delegated to backend infrastructure.

To see Portals in action, scan the QR code (below) with your mobile device. Any change to the code, will be reflected immediately to the device as well.

How does this work?

At its core, BrowserPod is built to be a high-fidelity, multi-language runtime environment.

Pods provide:

• Modular support for arbitrary language engines
• A sandboxed runtime with a virtual filesystem. Disk state is provided via images streamed on-demand to the user device. Any change stays local to the browser and can be persistent, making it possible to get back to the previous disk state after reloading a Pod.
• Process isolation and true concurrency via WebWorkers, suitable for real tools and workloads.
• Controlled networking (ingress and egress) via Portals.

BrowserPod builds on our previous experience in building browser-based virtual machines, with WebVM being its spiritual predecessor. The syscall layer of WebVM, which is powerful enough to run large scale, unmodified native applications, serves as the core foundation of BrowserPod.

Why Node.js first

We started with Node.js deliberately, not as an easy first step, but because it is one of the most challenging environments to test the robustness and fidelity of BrowserPod.

Modern Node workloads are complex: they are package managers, build pipelines, dev servers, file watchers, and tooling ecosystems with complex dependencies, which assume a lot about the environment.

Shipping Node.js as the first engine forces the platform to be robust from the start, and it sets the bar for everything that follows.

Roadmap and vision

Today’s release of BrowserPod for Node.js is the first step of our ambitious release plan.

Our roadmap includes numerous releases of new engines in the course of 2026:

• March 2026: command line tools (shared by all engines) - bash, git, coreutils, ssh, and many others
• April 2026: Python support
• May 2026: Ruby support
• July 2026: Go support
• August 2026: Rust support
• November 2026: Linux-class workloads (powered by the CheerpX WebAssembly Linux virtualization engine)

By the end of 2026 BrowserPod will be able to run any Linux container in the browser with support for modern full-stack development, realizing our vision of building a universal in-browser execution layer.

Throughout the year, we’ll also keep shipping continuous improvements in performance, compatibility, and developer ergonomics as we learn from real usage.

If you have any questions or ideas for us, get in touch. The whole Leaning Technologies team, myself included, is available on Discord

Try it out now

If you want to see what BrowserPod feels like in practice, start here: https://console.browserpod.io and follow the instructions, or simply use our npm quickstart.

npm create browserpod-quickstart

We believe BrowserPod is a concrete step toward a bigger goal: making the browser a first-class execution environment for tools, services, and the next generation of AI-native products. We cannot wait to see what the community will build with BrowserPod.