Wasmtime vs Wasmer for production Edge Functions

WebAssembly has long designated a runtime format for the browser. For several years, it has also been used to execute sandboxed code on the server side or at the edge: a bytecode compiled once, portable on any host machine, isolated by default without a container or complete virtual machine. Wasmtime and Wasmer carry this extension out of the browser, both written in Rust, both capable of executing the same .wasmfile.

Wasmtime is a project hosted by the Bytecode Alliance, the organization that manages several components of the WebAssembly server ecosystem, including the Cranelift compiler. Wasmer is developed by Wasmer Inc., a company which publishes the runtime as open source while marketing complementary services around it (edge ​​deployment, tooling). Two different governance models, no judgment on the quality of the code produced by one or the other.

The remainder of this article compares four verifiable fields, licensing and governance, available compilers, WASI standard and Component Model, security model, then explains, with supporting code, why Aurabase's Rust core runs Wasmtime in its Edge Functions engine.

Wasmtime is released under the Apache-2.0 license with LLVM exception, a permissive license common in the compiler ecosystem. Its governance follows the Bytecode Alliance model: several organizations contribute to the project, none owns it alone.

Wasmer is published under the MIT license, even more permissive on paper, but its technical direction remains concentrated at a single publisher, Wasmer Inc. This is not a fault in itself: many successful open source projects follow this model. It's simply a different risk profile if your organization values ​​distributed governance across multiple entities.

Wasmtime compiles in production via Cranelift, a code generator also from the Bytecode Alliance. The crate also documents an additional compiler, Winch, designed to reduce compilation time compared to Cranelift in cases sensitive to startup. The Cargo.toml ofaura-functions only activates the cranelift feature: it is this compiler, and it alone, which processes each WASM module loaded in production.

Wasmer takes the opposite path: three interchangeable backends. Singlepass compiles in a single pass, almost instantly, at the cost of less optimized machine code. Cranelift offers a balanced compromise. LLVM aims for the best possible execution throughput, with the longest compilation time of the three. A single runtime, three compromise profiles chosen during configuration.

WASI, the WebAssembly System Interface, standardizes access to files, clocks and the network from a WASM module, without depending on the browser. Its most recent version, WASI Preview 2, is based on the Component Model: a mechanism for composing modules written in different languages, with shared typed interfaces rather than a binary format specific to each runtime. Both Wasmtime and Wasmer are working on implementing this standard, each at their own pace.

Wasmer additionally documents WASIX, an extension that aims to cover POSIX primitives that the official WASI standard does not yet cover, such as threads or more comprehensive network sockets. This is not a standard supported by the WebAssembly working group, but an extension specific to the Wasmer ecosystem.

Both runtimes isolate each module in its own linear memory, with no direct access to the host system outside of explicitly imported functions. This is the basis of the WebAssembly security model, common to both projects.

Wasmtime also exposes a native execution footage API, fuel: each instruction consumes a budget fixed in advance, and execution stops properly once this budget is exhausted. A second API, the epochinterruption, allows you to impose a timeout without blocking the engine while waiting. Wasmer documents his own mechanics of metering and per-instance memory limits; This article has not verified them in a third-party repository, so does not break them down figure by figure.

This is exactly what Aurabase's aura-functions service enables, detailed in the next section with the actual source code.

The aura-functions service declares wasmtime as a production dependency, without deactivation comments or dev-dependency configuration. No file in the repository, neither Cargo.toml nor .rsfile, mentions Wasmer.

# WASM Runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

The initialization code explicitly activates fuel and interrupt by epoch, then bounds the memory by invocation with StoreLimits:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// by invocation:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

All three limits are configurable per environment variable, with default values checked in config/mod.rs: WASM_MAX_MEMORY_MB at 64, WASM_TIMEOUT_SECS at 10, WASM_MAX_FUEL at one billion units. The timeout is triggered in the background: a tokio::spawn waits the configured duration then increments the engine epoch, without blocking the current execution while waiting.

The ABI exposed to guest modules remains intentionally minimal: four host functions, aura.log, aura.get_input, aura.set_output and aura.get_env, registered via linker.func_wrap. It is not the Component Model, nor WASI Preview 2: it is an in-house contract, narrower, designed for a single use, executing an HTTP edge function and recovering its JSON response.

This wasm mode is a choice per function, not a global toggle. The Aurabase architecture overview details the other path, the default denomode, which executes JavaScript/TypeScript in a separate service. Both coexist in the same aura-functionsservice.

Sources: Cargo.toml and wasm/mod.rs from the Aurabase repository, verified directly on August 24, 2026. General Wasmtime and Wasmer characteristics taken from the public documentation of each project; no third-party benchmark figures are republished in this table.

You start a new edge runtime, with no existing dependencies. Wasmtime, supported by a multi-vendor foundation, reduces the risk of depending on a single publisher for the future of the project.

You have very frequent and short-lived cold starts. Wasmer's Singlepass backend directly responds to this need, almost instantaneous compilation, at the cost of less optimized machine code.

You need POSIX primitives beyond the current standard WASI. WASIX, the Wasmer extension, covers threads and extended sockets that WASI Preview 2 alone does not yet cover.

You want a native footage and timeout API, without third-party middleware. Wasmtime exposes fuel and epoch directly in the crate, exactly what aura-functions enables at Aurabase.