5 ms·
Show HN: Kandelo – a POSIX-compatible multi-process WASM kernel for the browser
Kandelo is an open-source, Wasm-based multi-process kernel that runs POSIX programs in browsers and Node.js.
Kandelo is still experimental, but it already runs a substantial range of existing software.
Do you have use cases for this?
We are trying Kandelo as a new foundation for WordPress Playground which runs server-side WordPress entirely in the browser. Kandelo also looks promising as a sandbox for running agents in the the browser and on the command line. On the side, we've been playing with porting games and desktop environments and even compiling runnable programs within Kandelo.
Yet it feels like there are many possibilities we haven't considered.
How would you like to use something like this?
Demos:
Some notes: The demos have been tested in desktop browsers. Unfortunately, YMMV on mobile today. Some of the disk images are large (~50MB) and may take a while to boot initially.
Main set, with Shell (bash, vim, nethack, and more), Nginx, PHP, WordPress, and Doom:
https://kandelo.dev/20260819-demo/ https://kandelo.dev/20260819-demo/
LÖVE game engine:
https://kandelo.dev/20260819-demo-love/ https://kandelo.dev/20260819-demo-love/
SNKRX running under LÖVE:
https://kandelo.dev/20260819-demo-love/?vfs=love-snkrx-abi44.vfs.zst https://kandelo.dev/20260819-demo-love/?vfs=love-snkrx-abi44...
Commander Keen running in DOSBox:
https://kandelo.dev/20260819-demo-dos/?demo=keen https://kandelo.dev/20260819-demo-dos/?demo=keen
LXDE desktop PoC:
https://kandelo.dev/20260819-demo-lxde/?demo=desktop-lxde https://kandelo.dev/20260819-demo-lxde/?demo=desktop-lxde
Background
I wanted an authentic OS-level foundation for running systems software in the browser and started this as a vibe-coded exploration. I figured it would end up being too slow and that we would have to offer many different ways to compromise default POSIX behavior to get anything usable. But after weeks of fighting agents, insisting on genuine POSIX compatibility as the default, I was surprised at how well the system worked without those compromises.
Nginx, PHP, Python, Ruby, Redis, and even MariaDB were able to be built using the SDK with minimal hacks.
Then we started porting games, having fun, and playing to see how far we could push it.
Notes on architecture:
There is a central, single-worker kernel, aiming to provide all supportable POSIX syscalls. Each process is a dedicated worker with independent memory. Each process thread is a dedicated worker that shares memory with threads from the same process. Syscalls are done with the process SharedArrayBuffer and the Atomics API. fork() is supported. The system is centered around virtual file system (VFS) images, and the VFS can contain lazy references to programs that may or may not be used. Vim is such a reference in the shell demo.
On GitHub:
https://github.com/Automattic/kandelo https://github.com/Automattic/kandelo
- faxmeyourcode 1mo agoThis is so cool! I'm having trouble thinking of all the different use cases and potential issues with this, but I don't think anyone has done something like this before. Great work
- brandonpayton 1mo agoThanks for taking a look and for kind words! We've also had a prototype running multiplayer DOOM between browsers via WebRTC. I wonder what kinds of network applications might be interesting here.
- grayrest 1mo agoI had the idea of achieving build isolation by codemodding the Rust implementations of bash and the GNU coreutils (brush+uutils) to use a VFS (wasmtime's cap-std) backed by the real FS and then disabling anything that remained problematic. It kind of works but I'm still not particularly confident in it and I think this is probably the better approach. The some points of trouble I ran into were dead symlinks left behind on the FS pointing to real files and escape codes interacting with the terminal (e.g. escape codes reading from the clipboard).
- brandonpayton 1mo agoThe build isolation approach sounds interesting, but I'm not sure I understand. Do you mean isolating build scripts by using a VFS mapped to the real FS and masking away everything the build script should not have access to? > The some points of trouble I ran into were dead symlinks left behind on the FS pointing to real files Symlinks make this space trickier for sure. > escape codes interacting with the terminal (e.g. escape codes reading from the clipboard). Woah. TIL this was possible.
- grayrest 1mo ago> Do you mean isolating build scripts by using a VFS mapped to the real FS and masking away everything the build script should not have access to? Yes. Essentially the idea was to find the source control root (or something configurable) and mount the real subtree into a VFS where everything interacts with the filesystem through the VFS. I can run wasm compiled versions of apps I don't really trust or run native patched versions that I do. For background, I'm writing a UI platform in Roc [1] and using just [2] in order to script things. I had extra tokens so I decided to do an LLM port of just over to Roc to exercise the compiler (it's pre-0.1, pushing the compiler leads to crashes) and people won't have to install Rust to write apps. Like wasm, Roc code can't access the outside world without the host providing the access to the outside world so in the process of the port I thought "I don't have to make posix calls, I can put it in sandbox and lie about it" so that's how I got here. I'm fairly close to being able to do hermetic builds so that's a possibility but this is mostly an exploration of whether the idea works or not. [1] https://roc-lang.org/ https://roc-lang.org/ [2] https://github.com/casey/just https://github.com/casey/just