v0.4-preview

[progrium]

Composable compute in HTML

See us at GopherCon 2026 on August 5th in Seattle!

Wanix Elements are web components that let you declare and use filesystems, tasks, VMs, terminals, and even VS Code, using HTML and JavaScript. Everything you need to build a Unix-style compute environment from scratch that runs sandboxed in the browser. Not only can it run Wasm and JS, but x86 Linux executables and more. This means it can run many development toolchains. It is the easiest way to:

• set up and run Linux on the web (entirely client-side in the browser)
• make old software more accessible by putting it on the web
• demonstrate your software in the browser before user download and installs
• simulate a cluster for an educational environment
• embed plugin development into your app
• build any kind of Unix development environment
• learn and explore the Plan 9 worldview
• so much more!

For the personal software revolution, Wanix gives you everything to build your own OS in the browser in a way that interops with and makes composable other operating systems the same way Plan 9 did. The creator of Unix once said the best operating system in the world is Plan 9. Wanix takes the ideas of Plan 9 and brings them to the web as new primitives for general compute.

In this example, without needing any JavaScript, we create a namespace, allocate a new ramfs as the root, download the rc shell, write an inline shell script, set up a task to run the shell script with rc, and create a terminal wired up to the task to interact with it. Using just a few tags we got a terminal on the page with "Hello world from Wanix!" printed out:

<wanix-namespace>
  <wanix-bind dst="." src="#ramfs/new"></wanix-bind>
  <wanix-bind dst="rc.wasm" type="file" mode="755" 
    src="https://cdn.jsdelivr.net/npm/wanix-extras@0.4.0-rc2/dist/rc.wasm"></wanix-bind>
  <wanix-bind dst="hello.sh" type="file" mode="755">
    echo "Hello world from Wanix!"
  </wanix-bind>
  <wanix-task cmd="rc.wasm -c hello.sh" term start></wanix-task>
  <wanix-term path="#term/1"></wanix-term>
</wanix-namespace>

This is a huge preview release. The star could be the HTML custom elements, but there is also a lot more to check out below. In the year since the last release, we've also launched an application developed on Wanix called Apptron. Those developments went back into Wanix and have been accumulating for this release.

For a bunch of interactive examples, you can also check out our newly relaunched website.

Elements

Wanix Elements are the easiest way to set up and use Wanix systems. You declaratively describe the system using HTML and you're done! The core Wanix elements all map to the core Wanix primitives: namespaces, tasks, terminals, VMs, and binds:

• <wanix-task>
• <wanix-bind>
• <wanix-term>
• <wanix-vm>
• <wanix-namespace>
• <wanix-workbench>

Workbench is an optional addition (see below). Workbench and <wanix-term> are the only elements that are visually rendered.

You can use an explicit namespace and wrap your system in <wanix-namespace>:

<wanix-namespace>
  <wanix-bind dst="rc.wasm" type="file" mode="755" src="/dist/rc.wasm"></wanix-bind>
  <wanix-task cmd="rc.wasm -c 'echo Hello world'" term start></wanix-task>
  <wanix-term></wanix-term>
</wanix-namespace>

For simple systems, you can also use an implicit namespace by using task, term, vm, or workbench as the outer namespace element:

<wanix-task cmd="rc.wasm -c 'echo Hello world'" term start>
  <wanix-bind dst="rc.wasm" type="file" mode="755" src="/dist/rc.wasm"></wanix-bind>
  <wanix-term></wanix-term>
</wanix-task>

You can choose which element (besides <wanix-bind>) is the root, though typically it will be the visual element. This form is the equivalent of the two above as well:

<wanix-term>
  <wanix-bind dst="rc.wasm" type="file" mode="755" src="/dist/rc.wasm"></wanix-bind>
  <wanix-task cmd="rc.wasm -c 'echo Hello world'" term start></wanix-task>
</wanix-term>

Workbench

Wanix Workbench is a fully customizable VS Code interface as a web component. It can be used as a simple editor, file explorer, terminal, full IDE, or something completely different via extensions. It's never been easier to deploy a customized VS Code:

<wanix-workbench assets="/workbench" sidebar="never" open="hello.txt" term>
  <wanix-bind dst="." src="#ramfs/new"></wanix-bind>
  <wanix-bind type="file" dst="hello.txt">
    Hello world
  </wanix-bind>
</wanix-workbench>

Wanix Workbench is part of "extras" because it requires a directory to be served with Code workbench assets and the bridge extension. This is literally just serving the workbench directory in the repo after building, but is also available over CDN (see below).

Extras

Optional components and support files are now distributed as "extras":

rc shell

Wanix now has its own minimal shell called rc (run command). Wanix previously depended on a minimal Busybox Linux VM just for a shell. Now this standalone Wasm executable can be dropped in as needed. Like Busybox, it's actually a multi-call executable with a whole Unix userland (cat, echo, cp, etc) including a Bash-like shell as one of the commands it embeds.

<wanix-bind dst="rc.wasm" type="file" mode="755" 
    src="https://cdn.jsdelivr.net/npm/wanix-extras@0.4.0-rc2/dist/rc.wasm"></wanix-bind>

It's very a much a work in progress, so it may be somewhat broken, but is also a great place to start hacking on Wanix. It's also intended to be a usable shell and userland for non-Wasm platforms.

Linux system

The rc sub-project has replaced shell as the default shell for Wanix and no longer uses a Linux VM. However, it was nice to have a "Wanix ready" Linux. Now in extras we have wanix-linux.tgz, which is Alpine Linux, plus some utilities, and a smaller Linux kernel. Wanix can run other custom Linux systems, but this gives you something to get going with Linux quicker.

You can simply bind the system tarball from CDN:

<wanix-bind dst="." type="archive" 
    src="https://cdn.jsdelivr.net/npm/wanix-extras@0.4.0-rc2/dist/wanix-linux.tgz"></wanix-bind>

v86 assets

Support for v86 now requires binding a tarball of assets from extras to #vm/v86, which works fine via CDN:

<wanix-bind dst="#vm/v86" type="archive" 
    src="https://cdn.jsdelivr.net/npm/wanix-extras@0.4.0-rc2/dist/v86.tgz"></wanix-bind>

Workbench assets

Support for <wanix-workbench> requires serving the Wanix Workbench assets and telling the element where they are.

<wanix-workbench assets="/workbench"></wanix-workbench>

We recommend serving them yourself to avoid cross-domain issues, but in some cases you can point to the CDN:

<wanix-workbench 
    assets="https://cdn.jsdelivr.net/npm/wanix-extras@0.4.0-rc2/dist/workbench"></wanix-workbench>

Project Layout

The project has been flattened out so you can see most of the project from the top level. Be sure to look in examples.

wanix/
├── api/        # Wanix filesystem API over Duplex
├── cmd/        # Wanix command-line tool
├── elements/   # Wanix web components
├── examples/   # Runnable local examples
├── extras/     # Package of support files for CDN
├── fs/         # General filesystem API and toolkit
├── gojs/       # Web worker for `gojs` tasks
├── misc/       # Support packages
├── native/     # Native task driver package
├── rc/         # Wanix shell based on Plan 9 shell
├── term/       # Terminal device package
├── test/       # Various test suites
├── v86/        # v86 virtual machine driver
├── vm/         # Virtual machine device package
├── wasi/       # Web worker for `wasi` tasks
├── wasm/       # Default Wasm module for Wanix
├── web/        # Web namespace packages
└── workbench/  # VSCode based work environment

Notable Additions

• invoke / func file protocol: allows synthetic files to act more like req/resp sockets
• import binds: binds namespaces from other web pages or 9p over websocket
• syncfs, httpfs, cowfs
• web/caches, web/dl, web/idbfs

Notable Changes

• #web/vm has moved to #vm
• #ramfs is now allocated by binding from #ramfs/new
• Bundles and related CLI commands have been dropped

Contributions

• pipe: report buffer size as file size by @0xull in pipe: report buffer size as file size #220
• fix docker create command in shell's Makefile by @lalyos in fix docker create command in shell's Makefile #230
• fix: mac specific tar issue by @lalyos in fix: mac specific tar issue #231
• fix: make terminal iframe visible by @lalyos in fix: make terminal iframe visible #232
• Reduce wanix.wasm build size by removing debug symbols. by @tbrockman in Reduce wanix.wasm build size by removing debug symbols. #236

New Contributors

• @0xull made their first contribution in pipe: report buffer size as file size #220
• @tbrockman made their first contribution in Reduce wanix.wasm build size by removing debug symbols. #236

Full Changelog: v0.3...v0.4-preview

---

This discussion was created from the release v0.4-preview.

[btheado]

The examples at https://wanix.dev work great and are very instructive. Great work!

I tried running a few of the examples on observablehq at: https://new.observablehq.com/@btheado/hello-wanix, but none of them work for me yet. I documented the issues I'm seeing on that page.

I haven't done any troubleshooting yet, but if you want to try it for yourself, click the pencil icon on the bottom right to make the cells editable. The first example I left commented out because it renders the page unusable. If you uncomment and make your page unusable, then just refresh the page to recover.

[progrium]

Thank you! Poked around and it just looks like a bunch of ways Wanix and Observable step on each other a little. Make sure you explicitly use wanix@0.4.0-rc2, the default/latest is stuck on an older version.

The infinite messages look like possibly resize updates from Wanix but being logged by and in a format specific to Observable. Once I got the terminal to render I saw it infinitely grow as well. I think it's because of the autoresize/fit extension is competing with Observable maybe doing something similar. A solution may involve an option to turn that off.

You could make an issue specifically about running on Observable and we can continue to triage there.

[btheado]

Thanks for that tip. After updating to wanix@0.4.0-rc2, I'm no longer seeing the growing terminal issue. The first and third examples are working for me now. The workbench is is not working but that one appears to be a CORS issue, nothing specific to wanix.