anuraOS: a browser-based Linux environment with a real virtual filesystem

A graphical Linux that lives inside a browser tab

anuraOS is a browser-based operating system shell and development environment with complete graphical Linux emulation, visually based on ChromiumOS. The Linux underneath is not a remote machine and not a container you ssh into: it is v86, a JavaScript-based x86 emulator, running in the same page as the desktop you see. The result is an environment that starts from a URL, with a demo hosted at anura.pro, and that keeps working offline because the whole thing is installed as a Progressive Web App. The project is explicit about its own status, calling it more of a proof of concept for what is possible on the modern web than an actual product, while noting that it proves useful in real cases and works as an educational tool. The code is JavaScript, the licence is AGPL-3.0, and the entry point of the environment is src/Boot.tsx, which the project helpfully points at in its credits section.

One filesystem, two implementations, kept in sync

The interesting engineering is in how the browser side and the emulated Linux side share a filesystem. Anura provides a virtual filesystem in the browser that is synced with the Linux emulator, so a file written by an app in the web environment and a file written inside the emulated Linux are the same file. The dependencies list in the project manifest shows how that is assembled: filer provides the browser-side filesystem abstraction, and webdav, libcurl.js, comlink, idb-keyval and fflate fill in the transport, compression and storage pieces. The build also compiles a virtual screen bridge and browser JS distribution from the external directory, and the Makefile shows the v86 sources being rebuilt from Rust for the interpreter and JIT paths. In other words, the emulator is not a black box binary dropped into the bundle; parts of it are compiled from source during the build, which is why the Rust toolchain is a hard prerequisite rather than an optional extra.

The build is Linux only, and the dependency list is long

The project states up front that anura will not build on Windows and that a Linux virtual machine or WSL is required. That single line saves a lot of time, because the dependency list is long: make, Node.js 24 or newer, PNPM, jq, uuid-runtime, rustup, wasm-bindgen at version 0.2.105, wasm-opt, a specific wasm-snip fork, Java 11 or newer, wget, clang, gcc with the multilib package on Debian and Ubuntu x86, a 32 bit glibc for building the root filesystem, Docker, and an x86 or x86-64 Linux machine because the Alpine rootfs target depends on x86 specific tools. You also add the Rust targets yourself, the wasm32-unknown-unknown target for the WebAssembly build and, if you intend to build v86 images, the i686-unknown-linux-gnu target. The project also flags a browser constraint: it mainly targets Chromium, should work on most other browsers, and publishes a document of known browser specific quirks rather than pretending compatibility is universal.

Cloning, building the rootfs and serving the result locally

The build sequence is short on the command line and long in wall clock time. You clone the repository with its submodules, then run the top level make target, and a forced rebuild is available for when you want everything rebuilt from scratch. The Makefile shows the shape of that target: it pulls submodules, bootstraps the npm installs for the root and the server package, builds the external libraries, compiles v86, assembles the browser JS bundle, and writes the public configuration file. The Linux root filesystem is a separate step that needs Docker running and your user added to the docker group, after which the rootfs target builds it. Serving the result locally is a single target, and the project states that anura is then running on port 8000 of localhost. There is also a Codespaces path for people who want a hosted setup: a setup script that is run inside the codespace, with the explicit caveat that it does not build the root filesystem.

make server

Apps are .app files reviewed by a maintainer

The application model is deliberately simple, and that is a design decision with consequences. Apps are stored in .app files that anuraOS reads to provide an application, and the project encourages app development to the point of saying good apps can be added to the official app repositories after review by an anuraOS maintainer. Two documents carry the developer contract: one on developing an anuraOS app, and one on using the Anura APIs from your code, with a documentation index tying them together. This is a plugin model with a review gate rather than an open registry, so distribution requires a relationship with the project. It also means the extension surface is defined by the environment rather than by a stable public SDK contract, which matters if you are planning to maintain an app across versions. The manifest also lists a set of runtime dependencies such as dreamland, workbox-cli, typescript and rollup, which tells you the front end is built with a component framework and a bundler rather than served as static files.

Where anuraOS is the wrong tool

Three limits are worth stating plainly. The first is the build environment: a Linux virtual machine or WSL, Docker, two Rust targets, wasm-bindgen at a pinned version, a specific wasm-snip fork, a 32 bit glibc and Java. That is a serious setup for a project whose own framing is a proof of concept, and it is the reason the Codespaces path exists. The second is performance and fidelity: v86 is an interpreter and JIT in JavaScript, and a real Linux desktop under emulation is a different experience from a native one, so a project that depends on smooth GUI work or heavy compilation inside the emulated system is asking for trouble. The third is the licence and the review gate. AGPL-3.0 is the most copyleft of the common licences, so if you intend to modify anuraOS and serve it, you need to understand what that obliges you to do. And an app that depends on internal behaviour rather than the documented API can break when the environment changes underneath it.

How it differs from running v86 on its own

The closest real alternative is to use v86 directly in a page, which is exactly what the Linux emulation here is based on, and the difference in approach is where the value is. v86 on its own gives you a Linux machine in a browser tab and a way to talk to it. anuraOS wraps that in a desktop metaphor modelled on ChromiumOS, adds a browser-side virtual filesystem that is synced with the emulated one, ships a code editor, and layers a modular application system and offline PWA support on top. Where v86 is a component, anuraOS is an environment, and the cost of that choice is the build chain and the copyleft licence. If your requirement is a single Linux program running in a browser, the emulator alone is the smaller dependency. If your requirement is a workspace where a file, a terminal and an app all meet, the extra layer is doing work v86 does not.

Maintenance state, versioning and the security path

The repository is not archived, and the last push was on 2026-08-06. The release list shows a single entry labelled latest, marked as a continuous build dated the same day, which matches a project that publishes from the main branch rather than cutting tagged versions on a schedule. The package manifest still carries a version of 2.0.0 and identifies the project as a webOS with v86 capabilities and a modular app system. Because there are no versioned releases, pinning is done by commit, and the branch policy is worth thinking about before you depend on it. Security reporting instructions are in SECURITY.md, and the project credits Mercury Workshop as the creator with the Linux emulation based on the v86 project, with fuller credits in CREDITS.MD. The homepage is anura.pro, and the documentation index lives in the documentation directory of the repository itself.

Editorial conclusion

Adopt anuraOS if you want to experiment with a browser-hosted development environment, teach how a graphical Linux and a web file system can be joined, or build .app modules against the Anura API. Do not adopt it as a production desktop, since the project describes itself as a proof of concept, and do not plan to build it on Windows because the project states it will not build there. Before you start, confirm you have a Linux virtual machine or WSL with Docker, Node.js 24 or newer and the Rust wasm targets, and read BrowserQuirks.md, because the project targets Chromium and lists browser specific quirks it does not hide.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. MercuryWorkshop/anuraOS on GitHub
3. Project website
4. README
5. Releases