Sign in Sign up

Platform

Wabuntu

Ubuntu, recompiled for the web. A complete Linux distribution that runs in a browser tab — on a real Linux 6.12 LTS kernel we ported to a new wasm32 architecture.

What this is

Wabuntu is not an emulator and not a virtual machine. It is real Ubuntu rebuilt for WebAssembly. When you open a Wabuntu session you get the same shell, the same apt, the same /usr/bin/python3, the same git, the same vim you would get from a fresh Ubuntu install. The difference is that nothing was installed, and there is no host operating system underneath. The kernel, the userspace, and every binary you run is a WebAssembly module executing natively in your browser's wasm engine.

What's included

  • A real Linux 6.12 LTS kernel, ported to a new arch/wasm32 architecture. Linux code paths execute as WebAssembly directly — no emulation, no transpilation. Every syscall you make goes through real Linux subsystems: VFS, scheduler, signals, fork/exec, pipes, futexes, memory management.
  • A complete userspace — your choice of libc. Bash 5.2, GNU coreutils 9.5, busybox, and the standard tool set you expect from a working Ubuntu system. Binaries are built against musl or glibc — both are supported equally — and, in the minimal images, statically linked, so each executable is self-contained and instantly launchable; dynamic linking is fully supported too (dlopen on musl, glibc's own ld.so) where a package needs it.
  • An apt-compatible package manager. apt install, apt search, apt update, apt upgrade — the commands and behaviour you already know. Wabuntu's APT repository lives at rep.wabuntu.io and hosts wasm-native builds of Ubuntu's most-used packages, all built from upstream source through our automated pipeline.
  • HardwareJS, the JavaScript hardware platform that sits between the kernel and the browser runtime. HardwareJS provides what hardware normally provides on a real machine: shared memory backing the kernel's RAM, a fixed pool of Worker threads the kernel uses as CPUs, syscall routing, signal delivery, and device backends for the console and the virtual filesystem.
  • The full Linux ABI you expect. /proc, /sys, /dev, real filesystem permissions, real signals, real pipes, real process trees. Your shell scripts work. Your build pipelines work. Your muscle memory works.

What you can do with it

Open a tab. Get a shell. Do real Linux work.

  • Run language runtimes — Python, Node, Ruby, Go, Rust — and build software with them.
  • Use git, ssh, curl, vim, tmux, and the rest of your daily-driver Linux tooling.
  • Install packages with apt, just like Ubuntu.
  • Spin up isolated environments per browser tab. Each Wabuntu session is its own kernel, its own filesystem, and its own process tree, with no leakage between sessions.
  • Share a session by URL. Anyone who opens the link gets the same environment, ready to go.

No installation. No download. No host operating system required.

How Wabuntu is different

It is not an emulator. Most "Linux in browser" projects are x86 or RISC-V emulators running an Ubuntu disk image. Every CPU instruction your shell executes goes through a JavaScript interpreter loop. They are slow, large, and an entire instruction set away from the host. Wabuntu inverts the model: WebAssembly is the instruction set, Linux is ported to it natively, and your binaries execute at native wasm speed in your browser's wasm engine.

It is not a container. Containers ship a userspace on top of a shared host kernel. Wabuntu ships its own kernel — real Linux 6.12 LTS, real upstream source — into your browser. There is no host Linux underneath. The browser itself is the hypervisor.

It is not a thin shell or sandbox imitation. Wabuntu binaries are real executables with a real syscall ABI, executed by a real kernel. Your bash is GNU bash, compiled to wasm. Your python3 is real CPython, compiled to wasm. The whole stack is what it claims to be.

Technical underpinnings

┌─────────────────────────────────────────────────────┐
│                   Your browser                      │
│                                                     │
│  ┌───────────────────────────────────────────────┐  │
│  │ HardwareJS — the JavaScript hardware platform │  │
│  │ shared memory · CPU workers · syscall         │  │
│  │ routing · device backends · signal delivery   │  │
│  └───────────────────┬───────────────────────────┘  │
│                      │                              │
│  ┌───────────────────┴───────────────────────────┐  │
│  │ vmlinux.wasm — Linux 6.12 LTS, arch/wasm32    │  │
│  │ real scheduler · real MM · real VFS · real    │  │
│  │ signals · real concurrency over shared memory │  │
│  └───────────────────┬───────────────────────────┘  │
│                      │                              │
│  ┌──────┐ ┌──────┐ ┌─┴────┐ ┌──────┐ ┌──────┐       │
│  │ bash │ │  ls  │ │python│ │ git  │ │ ...  │       │
│  │.wasm │ │.wasm │ │.wasm │ │.wasm │ │      │       │
│  └──────┘ └──────┘ └──────┘ └──────┘ └──────┘       │
│  Tasks time-slice across a fixed CPU-Worker pool;   │
│  each process keeps its own user memory.            │
└─────────────────────────────────────────────────────┘
  • Kernel. Linux 6.12 LTS, unmodified upstream source plus our arch/wasm32 drop-in. Built with the LLVM toolchain through a customised link pipeline. The kernel binary, vmlinux.wasm, boots cold in well under a second on a modern browser.
  • Userspace toolchain. The brintOS toolchain — wasm32 ports of both musl 1.2 and glibc 2.43 with our custom syscall ABI, plus a pinned LLVM, the HwjsCoroutinize pass, and compiler and linker wrappers that produce wasm-format executables recognised by our kernel's binfmt_wasm loader. (The compiler is LLVM/clang; GCC's wasm backend isn't ready yet, but we're tracking it.)
  • Packages. Built from upstream source through an automated pipeline. We contribute portability patches upstream where possible and absorb Alpine Linux's musl-portability patches where applicable. The repository grows weekly as the build matrix turns over.
  • Platform layer. HardwareJS — a TypeScript library that presents the kernel with shared memory, process workers, syscall routing, signal delivery, and emulated device backends. It is the JavaScript implementation of the "hardware" the kernel runs on.