Wasmi is an efficient, lightweight and deterministic WebAssembly interpreter, written in Rust and published as the wasmi crate, for constrained and embedded systems and for applications that need a safe plug-in runtime.

What it is

Wasmi is a WebAssembly interpreter implemented in Rust and distributed through crates.io, with API documentation on docs.rs and a usage guide kept in the repository at docs/usage.md. It executes WebAssembly modules with an interpreter rather than translating them ahead of time, and the project describes itself as efficient, cross-platform and focused on constrained and embedded systems. It lives in the Rust crate ecosystem, and its topic list places it in edge computing, embedded systems, game engines and plug-in systems. The source is released under Apache-2.0.

The problem it solves is the one a host application faces when it wants to run third-party or untrusted code inside its own process. That host needs execution that behaves identically on every platform, that cannot be pushed into unbounded work, and that does not depend on a just-in-time compiler being available on the target. Wasmi answers this by resisting compiler and JIT bombs during translation, by shipping built-in fuel metering, and by loosely mirroring the Wasmtime API so that it can serve as a drop-in replacement for the Wasmtime engine a host would otherwise embed.

Key capabilities

• Provides simple, correct and deterministic execution of WebAssembly, which the README lists as a distinct feature.
• Runs in no_std embedded environments, covering the targets catalogued in Rust's platform-support list.
• Resists compiler and JIT bombs during translation, and supplies built-in fuel metering so a host can bound how much work guest code performs.
• Loosely mirrors the Wasmtime API, which the README frames as making it a drop-in replacement.
• Claims 100% compliance with the WebAssembly spec testsuite.
• Covers a broad set of proposals, including simd from 0.43.0, relaxed-simd from 0.44.0, memory64 and custom-page-sizes from 0.41.0, wide-arithmetic from 0.42.0, multi-memory from 0.37.0, extended-const from 0.29.0, tail-calls from 0.28.0, and bulk-memory and reference-types from 0.24.0.
• Supports the official Wasm C-API through the wasmi_c_api_impl crate and WASI (wasip1) through the wasmi_wasi crate.

Who uses it and how

• Embedded and constrained deployments, where the no_std support allows the interpreter to be built into firmware that has no operating system beneath it.
• Applications that host plug-ins, including game engines, where the deterministic execution model and fuel metering make guest behaviour repeatable and bounded.
• Edge computing deployments that need one WebAssembly runtime behaving the same way across platforms rather than per-architecture compiled code.
• Safety-critical and blockchain-adjacent projects: Wasmi has been audited twice, once for versions 0.36.0 to 0.38.0 by Runtime Verification Inc. on behalf of the Stellar Development Foundation, and once for 0.31.0 by SRLabs on behalf of Parity Technologies.
• Hosts already written against the Wasmtime API, which can substitute Wasmi without restructuring their embedding code, and C or C++ hosts that reach it through the Wasm C-API.

Getting started

Add the wasmi crate from crates.io as a dependency, then follow the usage guide at docs/usage.md; crate features are documented on the docs.rs page. WASI and C-API support come from the companion wasmi_wasi and wasmi_c_api_impl crates.

How it compares

The only comparable tool the facts name is Wasmtime, whose API Wasmi loosely mirrors in order to act as a drop-in replacement, so a host can move between the two without rewriting its embedding layer. The distinction the project draws is that it stays an interpreter and remains usable in no_std environments while resisting JIT bombs, which is where a compiler-based engine is the weaker fit.

When to use it — and when not to

Because translation is interpreted, this is not the runtime to choose when peak throughput on compute-heavy guest code is the deciding requirement. Teams that need threads, garbage collection, function references or exception handling will find each of those still tracked as an open issue rather than supported, and several proposals only arrive in recent releases, so projects pinned to older versions miss simd, relaxed-simd and memory64. There is no service to operate beyond the crate itself, but there is also no hosted offering: adopters embed a library and take on its upgrade cadence.

    </a>