Wasmer

Wasmer is a standalone webassembly runtime: a CLI that runs .wasm files, a library you embed in a host program, and a package registry the CLI can pull from. It has been going since 2018, which makes it one of the oldest runtimes outside the browser, and it is MIT-licensed with a company (YC-backed) behind it. The commercial layer on top is a hosted platform for deploying Wasm applications to an edge network.

The wasmer.io homepage is almost entirely a pitch for that hosted platform — "new container technology," "scales effortlessly," logos of large companies — and says very little about the runtime. What follows is the runtime.

How it works

The distinguishing design decision is that the compiler is a swappable backend rather than a fixed part of the engine. Singlepass compiles in a single linear pass for the fastest possible startup and predictable compile time, which is what you want when the module arrives at request time and is discarded. Cranelift is the middle option. LLVM produces the fastest generated code at much higher compile cost, for modules you compile once and reuse. Compiled artifacts can be serialized ahead of time so the compile cost is paid at build rather than at load.

The other half is the system interface. Plain WASI gives a Wasm module a restricted POSIX subset — preopened directories, stdio, clocks, random — and deliberately stops well short of a real operating system. Wasmer ships WASIX, its own superset, which adds threads, full Berkeley sockets, and fork/exec. That is what lets existing server software be compiled to Wasm more or less unmodified, and it is also a non-standard extension: code that depends on WASIX runs on Wasmer and not on runtimes that implement only WASI.

Embedding is available from a long list of host languages — Rust natively, plus C/C++, Python, Go, JavaScript, PHP, Ruby and others — through bindings over a common C API, so the same sandbox is reachable from whatever the host application is written in. The JavaScript SDK runs WASIX programs in the browser, which is how the wasmer.sh shell demo works.

# run a module directly
wasmer run ./program.wasm --dir=. -- --flag arg

# run a published package from the registry
wasmer run python/python -- -c "print(1+1)"

# compile ahead of time with a chosen backend
wasmer compile ./program.wasm --llvm -o program.wasmu

Where it fits

Against wazero, the trade is direct: wazero is pure Go with no CGO, so embedding it costs nothing in build complexity, and it is an interpreter-plus-basic-compiler with no LLVM tier. Wasmer is faster at the top end and speaks WASIX, but embedding it in a Go program means linking a native library and giving up free cross-compilation. Against Wasmtime, the Bytecode Alliance runtime, Wasmer's differentiators are the multi-backend design, WASIX, and the breadth of language bindings; Wasmtime is the more conservative choice if standards conformance is what matters.

Limitations

WASIX is the main one. It solves a real problem — standard WASI is too thin to port existing programs onto — but it does so outside the standards process, so it is a portability decision rather than a free feature. The multi-backend design also means the performance you get depends on which backend you picked and whether you paid the compile cost up front, and the marketing numbers rarely say which.

The runtime is open source; the deploy platform, the registry and the pricing are not the same thing, and the homepage tends to blur them. Anyone evaluating Wasmer for embedding should read the repo, not the site.

Repo: github.com/wasmerio/wasmer — ~20,900 stars, MIT, Rust.