Wago arrives as a new single-pass WebAssembly runtime taking aim at wazero

A new WebAssembly runtime named Wago has been released, stepping into a field already occupied by Wasmtime, Wasmer, wazero and V8. In the launch post on dev.to, the author frames the project as an answer to a specific pain point: the cost of compiling and running wasm at scale, where the de-facto Go-based option felt too slow and too memory-hungry.

Why build another runtime

According to the post, the author's two most recent employers, Hypermode and Impart Security, ran isolated wasm workloads on wazero. The appeal was clear: no fleets of Docker containers or micro-VMs, with guest programs living comfortably in kilobytes to megabytes of RAM.

The trade-off, he argues, is speed. Wasmtime benefits from Cranelift, a proper optimizing compiler that emits high-quality machine code, while wazero deliberately prioritises simplicity over peak performance. On larger workloads, he says wazero could peak at hundreds of megabytes of memory just to compile a module, a cost that scaling out with more machines only partly hides.

That led to a set of deliberately ambitious goals: a compiler that needs only kilobytes of memory, emits less machine code, compiles several times faster, runs meaningfully faster than wazero, stays single-pass, and can eventually target embedded systems.

Railshot, a single-pass compiler

The result is Railshot, Wago's compiler. It skips the traditional pipeline of building a large intermediate representation and running repeated optimization passes, instead moving more or less directly from the wasm input through analysis to machine code.

Single-pass compilation normally means worse output code. The author's counterargument is that wasm binaries usually arrive already optimized by front-end toolchains such as LLVM, Rust or TinyGo, so the runtime does not need to rediscover that work. The structured nature of WebAssembly, with its blocks, loops, branches, types and operand stack, also hands the compiler useful information essentially for free.

Building on an approach he calls Valent Blocks, with a nod to a research paper, Railshot maintains small, temporary views of the program that are just detailed enough to enable register pinning, bounds-check elimination, instruction combining, constant folding, branch simplification and fewer loads and stores, all without turning into a conventional optimizing compiler.

Self-reported numbers, with caveats

Across his benchmark corpus, the author reports that Wago is roughly 5.7× faster to compile, 11× lighter on memory during compilation, about 70% faster at execution, and produces around 52% less machine code, all relative to wazero.

He is upfront about the caveats: he wrote both Wago and the benchmarks, and he encourages readers to run them independently. He also acknowledges that Wago is brand new, contains bugs and will see breaking changes, while Wasmtime and wazero carry years of production hardening that no benchmark chart can substitute for.

Plugins and platform support

Wago has grown beyond the compiler. The post lists support for modern WebAssembly (3.0 and beyond), very cheap instance creation, standalone native executables, AMD64 and ARM64 backends with RISC-V in progress, and macOS, Linux and Windows hosts.

The more unusual feature is the plugin system, which can extend the runtime itself rather than just adding host functions, including custom WebAssembly instructions and types. As a proof of concept, the author implemented wider SIMD, with 512-bit vectors on AVX-512-capable hardware, as a plugin. WASI is similarly optional and installed on demand, so users only carry the capabilities they actually want. The post takes a swipe at Wasmer's commercial direction along the way, suggesting readers sponsor Wago rather than pay for a cloud-oriented product.

Why it matters

The WebAssembly runtime landscape has looked settled: Wasmtime backed by the Bytecode Alliance, Wasmer as a long-standing commercial player, and wazero as the default answer in Go. Wago's argument is that the space is not finished, because cheap compilation and a small memory footprint change the economics of running wasm everywhere from edge and serverless workloads to embedded targets, where containers and micro-VMs are too heavy and existing alternatives too costly to compile.

Its extensible plugin model, reaching down to custom instructions and types, also sketches a vision of a runtime as a platform you own rather than a fixed stack you rent.

All of that rests on self-reported benchmarks and very young code. Independent verification, spec compliance and security hardening will decide whether Wago becomes a real challenger or stays an interesting experiment. But for teams whose infrastructure bills include the memory cost of compiling wasm modules, it is a project worth testing.