# wazero: A Zero Dependency WebAssembly Runtime for Go Developers

> wazero embeds a WebAssembly runtime directly in Go binaries with no CGO and no dependencies beyond x/sys. It offers two execution modes, an AOT compiler and a portable interpreter, with a different platform story for each.

**wazero/wazero** — wazero: the zero dependency WebAssembly runtime for Go developers

- Repository: https://github.com/wazero/wazero
- Website: https://wazero.io
- Stars: 6,395 · Forks: 357
- Language: Go
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/wazero-wazero

## What wazero solves for Go programs that need to run Wasm

The README describes WebAssembly as a way to safely run code compiled in other languages, distributed as .wasm binaries. The usual problem is that the runtime executing those binaries is a separate process, often a C or Rust binary that pulls in system libraries and breaks cross compilation. wazero takes the opposite position: it is a WebAssembly runtime written in Go, embedded as a library, so the host application and the Wasm execution share one binary.

The audience is narrow and specific. You are a Go developer who wants to extend an application with code written in another language, or you want to run third-party Wasm plugins inside your own process. The README states the goal directly: import wazero and extend your Go application with code written in any language. Because wazero has no dependencies and does not require CGO, a Go program that embeds it still cross compiles, and per the README it can even be embedded in an application with no operating system at all. That last property is called out as a main differentiator from alternatives.

This is not a general purpose Wasm runner. There is no standalone binary to point at a .wasm file in the README; the entry point is the Go API. If you want a command line tool, you are building it yourself on top of the library.

## Compiler versus Interpreter: two execution paths with different platform reach

wazero ships two runtime configurations, and choosing between them is the first real decision. By default, wazero.NewRuntime(ctx) uses the Compiler if it is supported. The Compiler translates WebAssembly modules into machine code ahead of time, during Runtime.CompileModule, so the Wasm functions execute natively. The README states the Compiler is faster than the Interpreter, often by an order of magnitude (10x) or more, and does this without host-specific dependencies.

The Interpreter is described as a naive interpreter-based implementation of the Wasm virtual machine. Its selling point is portability: the implementation has no GOARCH or GOOS specific code, so it can be used for any compilation target available for Go, and the README names riscv64 as an example.

The conformance table is where the trade-off becomes concrete. Both runtimes pass the WebAssembly Core 1.0 and 2.0 specification tests, but not on the same set of platforms. The Compiler is marked supported on amd64 and arm64 and unsupported on others. The Interpreter is supported on amd64, arm64 and others. So the faster path is the narrower one, and a project targeting an unusual architecture gets the interpreter whether it wants it or not. You can force the interpreter explicitly:

```go
r := wazero.NewRuntimeWithConfig(ctx, wazero.NewRuntimeConfigInterpreter())
```

That call is worth keeping in mind during testing, because it lets you exercise the portable path on a machine that would otherwise pick the Compiler by default.

## Installing wazero and running the basic addition example

wazero is a Go module, so installation is a single go get against the module path in go.mod. The README gives this exact command:

```bash
go get github.com/tetratelabs/wazero@latest
```

After that, the module is available as github.com/tetratelabs/wazero in your imports. The go.mod in the repository declares the module as github.com/tetratelabs/wazero, sets a Go floor of 1.25.0 with the comment that this is the current Go version minus one, and requires golang.org/x/sys v0.44.0. The README notes that x/sys is the only dependency besides Go itself, so the Go version is the main source of conflict in a project that adopts wazero.

The README points new users at the examples directory rather than a long tutorial, and names examples/basic as the most basic one: it extends a Go application with an addition function defined in WebAssembly. The examples directory contains basic, allocation, cli, concurrent-instantiation, import-go, multiple-results and multiple-runtimes. To run the example tests from a checkout of the repository, the Makefile defines a target:

```bash
make test.examples
```

That target runs go test with a 300 second default timeout across ./examples/... plus the AssemblyScript, Emscripten and wasi_snapshot_preview1 example packages. If you are evaluating wazero, reading examples/basic alongside examples/import-go is a faster route than starting from the API reference, because the two together show both directions of the host and guest boundary.

## Where the platform support matrix bites

The support policy section is unusually honest about testing scope, and it should shape expectations. The README says the only supported operating systems are ones they test, while noting other versions may still work. The tested set is Linux (Ubuntu and scratch), macOS and Windows as packaged by GitHub Actions, plus nested VMs on Linux for FreeBSD, NetBSD, OpenBSD, DragonFly BSD, illumos and Solaris.

The per-runtime detail is tighter than the headline. For the Interpreter, Linux is tested on amd64, arm64 and riscv64; Windows, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, illumos and Solaris are tested only on amd64; macOS is tested only on arm64. For the Compiler, Linux is tested on amd64 and arm64; Windows, FreeBSD, NetBSD, DragonFly BSD, illumos and Solaris only on amd64; macOS only on arm64. Notice that OpenBSD appears in the Compiler list but not in the conformance table's supported set, and the table itself marks Compiler as unsupported outside amd64 and arm64. If your deployment target is an arm64 Windows machine or an arm64 FreeBSD box, the documented test coverage does not reach you.

There is a second, unrelated trap for macOS users: the README directs anyone who needs to code-sign a macOS application to issue #2393. That is a pointer, not an answer, and it means code-signing entitlements are a known open area rather than a solved one.

## Zero dependencies, but not zero cost

The zero dependency claim is verified in an unusual way: the README states wazero runs its tests in Docker's scratch image, which is the smallest possible parent image. That is a real constraint on what the codebase can pull in, and it is why embedding wazero does not change your container base image or your CGO settings.

The cost is in the API surface and the versioning policy. wazero promises not to break any exported function signature without incrementing the major version, and the 1.0 release happened in March 2023. New features and behaviors arrive in minor versions, bugs and internal changes in patches. That is a stable contract, but it also means the library moves at its own pace and you inherit its Go version floor: go.mod currently sets go 1.25.0, and the README says wazero follows Go's release policy of supporting two versions. If your project is pinned to an older Go toolchain, wazero is not an option until you move.

The repository also carries a retract block in go.mod for the v1.0.0 beta tags, with a comment explaining that the betas are retracted and replaced with pre to prevent users from accidentally upgrading into a broken beta 1. That is a small detail, but it tells you the project takes accidental upgrades seriously enough to use the retract mechanism rather than just documenting the problem.

## How wazero compares to a CGO-based runtime

The obvious alternative for a Go program is a Wasm runtime that links a C or Rust engine through CGO. The practical difference is not raw speed; it is what happens to your build. A CGO-based engine introduces a C toolchain requirement, platform-specific shared libraries, and a cross-compilation story that usually ends in per-target build infrastructure. wazero's README frames the absence of CGO and dependencies as the differentiator, and the scratch-image test is the evidence behind it. The trade is that you give up whatever optimizations a mature C engine has accumulated, and you accept the platform matrix above.

A second alternative is running Wasm out of process, for example through a server or a CLI that your Go program talks to over a socket or stdio. That removes the embedding question entirely and lets you pick any runtime you like, including ones with broader architecture support. What you lose is the single-binary property: your application now has a second process to ship, supervise and secure, and every Wasm call crosses a process boundary. wazero's examples/cli shows the shape of a CLI built on the library, which is the direction you would go if you want a standalone tool without leaving Go.

A third option worth naming is simply not using Wasm. If your goal is plugin extensibility inside a Go program, Go plugins and subprocess isolation solve some of the same problems with none of the Wasm toolchain. Wasm earns its place when the guest code is compiled from another language or comes from an untrusted source and you want the sandbox.

## Maintenance, licensing and what to check before adopting

The repository is not archived, and the last push was on 2026-09-22. The most recent release listed is v1.12.0 on 2026-05-29, preceded by v1.11.0 on 2025-12-19 and v1.10.1 on 2025-11-11. That cadence is consistent with a project that ships minor features and patch fixes on a semver schedule rather than a fast-moving one.

wazero is licensed under Apache-2.0, and the README notes that wazero is a registered trademark of Tetrate.io, Inc. in the United States and other countries. The licence permits commercial embedding, but the trademark line means the name itself is not yours to use in a product or service name. That is worth flagging to whoever handles branding before you ship something called "your-product-wazero". This is not legal advice; check the LICENSE and NOTICE files in the repository with your own counsel.

The upgrade cost is bounded by the semver promise: patch and minor upgrades should not require code changes to exported function signatures, and the Go version floor moves with Go's two-version support policy. The thing to verify first is the conformance table row for your runtime mode and target platform, followed by the Go version your build already uses. If you are on macOS and code-sign, read issue #2393 before you plan the release.

## Conclusion

Adopt wazero if you are writing Go and want to execute Wasm modules in-process without CGO, especially on targets where the interpreter is the only viable mode. Do not adopt it if you need a standalone CLI runtime, a non-Go host language, or Compiler support on riscv64 or other non-amd64, non-arm64 targets. Before committing, verify which runtime mode your target platform actually supports in the conformance table, check the Go version floor in go.mod, and read issue #2393 if you code-sign on macOS.

## FAQ

### What websites use Wasm?

The README does not list websites that use Wasm. It describes WebAssembly as a way to safely run code compiled in other languages, and wazero as a runtime that executes those modules inside Go applications.

### Does Netflix use Wasm?

The README does not mention Netflix or any other company using Wasm. The only usage evidence it gives is a link to a community users page and the statement that wazero is in use by many projects and production sites.

### What is Wasm and how does it work?

The README says WebAssembly is a way to safely run code compiled in other languages, and that runtimes execute WebAssembly Modules, which are most often binaries with a .wasm extension. wazero is one such runtime, written in Go.

### Why is Wasm so big?

The README does not discuss Wasm binary size. It does state that wazero has zero dependencies, does not rely on CGO, and is verified by running tests in Docker's scratch image.

## Sources

- [License: Apache-2.0](https://github.com/wazero/wazero/blob/main/LICENSE)
- [Project website](https://wazero.io)
- [README](https://github.com/wazero/wazero/blob/main/README.md)
- [Releases](https://github.com/wazero/wazero/releases)
- [wazero/wazero on GitHub](https://github.com/wazero/wazero)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wazero-wazero