A Linux-like kernel in a browser tab - deep dive in the BrowserPod architecture Back to blog<br>A Linux-like kernel in a browser tab - deep dive in the BrowserPod architecture<br>Alessandro Pignotti<br>May 18, 2026<br>X Facebook Y Combinator LinkedIn Reddit Email WhatsApp

A few months ago we released BrowserPod: an in-browser sandbox, powered by WebAssembly, that runs completely client-side. Under the hood BrowserPod provides a WebAssembly-native kernel, designed from scratch to run in the browser while being compatible with many applications originally designed for Linux.

This WebAssembly kernel is the critical feature that makes BrowserPod powerful enough to run real-world, full stack apps completely in the browser. This post is a deep-dive in the architecture , capabilities and limitations of our solution: we will start by highlighting the core functions of modern operating systems and how they translate in the BrowserPod design, we will then further delve into the implementation of the disk and networking subsystem, and finally discuss the current limitations and future plans.

BrowserCode running Claude Code in the browser on<br>top of BrowserPod

With the release of BrowserPod 2.0, the tool is now stable enough to run Claude Code and other agentic CLIs completely in the browser. Check out BrowserCode to get a quick impression of what you could build with BrowserPod today.

What does a kernel actually do?

BrowserPod is heavily inspired by traditional kernels for native hardware, and we could identify many direct parallels between the WebAssembly execution model and the principles you’d typically find in an operating system textbook.

Low-level programming concepts are often misunderstood, especially by developers that are only exposed to more abstracted forms of coding. So, before getting into the details, it is a good idea to outline in broad strokes the main functions of an operating system kernel:

Accessing and abstracting the hardware : The kernel contains specialized code, usually called device drivers, that can speak the low-level protocol of the various hardware components of a device. The kernel also exposes an abstracted interface of the hardware to applications, making it possible to have multiple competing vendors and hardware designs without requiring each program to include device-specific logic.

Coordination of hardware access: The kernel decides which application can access the hardware at any given time and, if it allows concurrent access, resolves any conflicts. As an example, consider a disk driver: only one (or a few) blocks of data can be read/written concurrently by the hardware. Any other request must be placed in a queue and served progressively. The kernel will decide the order in which requests will be processed,making sure no single application can hog all the resources. The kernel can also optimise the access patterns, for example by exploiting locality.

Application isolation: A fundamental capability of modern operating systems is keeping applications isolated. This is normally achieved via a low-level CPU capability called “virtual memory”. The idea is that each application (or process more accurately) can only ever access a subset of the physical memory and has no access at all to address in other processes. In operating systems parlance it is said that each process has its own independent address space. A useful side-effect of this property is that a crash in one process will not affect any other process on your system, at least ideally.

Concurrent execution: If the hardware provides multiple CPUs, the kernel can also run more than one process concurrently. In practice, this means each CPU will be configured to access a different address space and multiple instruction flows will be executed independently in parallel. An interesting special case is multi-threading where the CPUs will be configured to access the same address space while maintaining an independent execution flow.

A real kernel, but in a browser tab

Diagram of the BrowserPod architecture, illustrating the main components.

Our objective for the BrowserPod kernel is to move beyond the current state of the art of WebAssembly as a compilation target. Compiling a single, potentially multithreaded, program and running it in the browser is relatively easy with existing toolchains.

What is missing, in our opinion, is a solution to run complete software systems: collections of programs that work together and interact to provide a complete user experience. Here’s a practical example: a simple npm install && npm run dev command actually represents a complex orchestration of multiple processes, including shells, node.js instances, install scripts, etc.

All these steps need to work on a coherent and persistent view of the files and other system resources, working together without stepping on each other’s toes. As we started to lay out a viable architecture to solve this problem we noticed that we had to effectively build a...