Overview

Wasmtime is the reference implementation of WASI (WebAssembly System Interface), enabling WebAssembly to run on servers, CLIs, and embedded systems. It provides a sandboxed environment where WASM modules can only access system resources (files, network, env vars) that the host explicitly grants.

CLI Usage

# Install
curl https://wasmtime.dev/install.sh -sSf | bash

# Run a WASM file
wasmtime hello.wasm

# With explicit capabilities (WASI capability-based security)
wasmtime --dir ./data --env DATABASE_URL=postgres://... my-app.wasm

# Pass arguments
wasmtime my-tool.wasm -- --input data.csv --output result.json

Embedding in Rust

use wasmtime::*;
use wasmtime_wasi::WasiCtxBuilder;

fn main() -> Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "plugin.wasm")?;

    let mut linker = Linker::new(&engine);
    wasmtime_wasi::add_to_linker(&mut linker, |s: &mut WasiCtx| s)?;

    // Grant only specific capabilities
    let wasi = WasiCtxBuilder::new()
        .inherit_stdio()
        .preopened_dir("./sandbox_data", "/")?  // Only this directory
        .env("ALLOWED_KEY", "value")?
        .build();

    let mut store = Store::new(&engine, wasi);
    let instance = linker.instantiate(&mut store, &module)?;

    // Call an exported function from the WASM module
    let process = instance.get_typed_func::<(i32,), i32>(&mut store, "process")?;
    let result = process.call(&mut store, (42,))?;
    println!("Result: {}", result);

    Ok(())
}

Use Cases

Plugin systems: Allow third-party plugins to run securely in your application. The plugin gets WASM capabilities, not host OS access:

// Safely run untrusted plugin code
// Plugin can ONLY call functions you've explicitly exposed
// Cannot access the file system, network, or memory outside its sandbox
let result = run_plugin(&plugin_wasm_bytes, user_input)?;

Edge computing: Wasmtime powers Fastly Compute and is used by Cloudflare Workers internally. WASM’s fast cold-start time (~1ms) vs container cold-start (~100ms) makes it ideal for edge functions.

Polyglot plugins: Write plugins in Rust, Go, Python, or C — compile to WASM — run with the same Wasmtime host regardless of language.

WASI vs Browser WASM

	Browser WASM	Server WASM (WASI)
File system	❌	✅ (capability-gated)
Network	❌	✅ (future WASI)
Threads	SharedArrayBuffer only	✅
Security	Browser sandbox	Capability model
Runtimes	V8, SpiderMonkey, WebKit	Wasmtime, WASMer, WasmEdge

Concrete Use Case: Running User-Submitted Code in a Sandboxed WASM Runtime for a SaaS Platform

A SaaS platform for data transformation allows customers to write custom transformation logic — think ETL rules like “parse this CSV column as a date, convert currency values, and flag rows where the total exceeds a threshold.” The platform needs to execute this user-submitted code on its servers without risking the host system. Traditional approaches like Docker containers add 100-300ms cold-start overhead per execution, and process-level sandboxing (seccomp, AppArmor) is complex to configure correctly. The team chooses Wasmtime as the execution runtime.

Customers write transformation functions in a subset of Python (compiled to WASM via Componentize-py) or in Rust. The platform compiles the submitted code to a .wasm component, validates it against a set of allowed WASI interfaces (only wasi:io for stdin/stdout and a virtual filesystem scoped to the job’s input data), and caches the compiled module. At execution time, Wasmtime instantiates the module in under 1ms, passes the input data through a pre-opened virtual directory, and collects the output. The capability-based security model means the user’s code physically cannot access the network, the host filesystem, environment variables, or any other tenant’s data — these capabilities are simply never granted to the WASM instance.

The platform processes 50,000 transformation jobs per hour across a pool of Wasmtime host processes. Each job runs in its own isolated WASM instance with a 5-second execution timeout and 256MB memory limit enforced by Wasmtime’s resource limiter. Compared to their previous Docker-based execution engine, cold-start latency drops from 200ms to under 2ms, memory overhead per job drops from ~50MB (container baseline) to ~4MB (WASM instance), and the security boundary is stronger because it relies on WASM’s formally-verified memory isolation rather than Linux kernel namespace configuration.

When to Use Wasmtime

Use Wasmtime when:

You need to execute untrusted or third-party code on your servers with strong sandboxing guarantees and minimal overhead
You are building a plugin system where plugins should be language-agnostic (Rust, Go, Python, C) but run in a uniform, secure runtime
You need sub-millisecond cold-start times that containers cannot provide, such as edge computing or serverless function platforms
You want capability-based security where executed code can only access resources you explicitly grant (specific directories, environment variables, or host functions)
You are implementing a polyglot compute layer and want a single runtime that accepts modules compiled from any language with a WASM target

When NOT to use Wasmtime:

You need full POSIX compatibility or access to the complete Linux syscall surface — WASI covers a subset and many system calls are not yet available
Your workload is I/O-heavy (database queries, HTTP calls) rather than compute-heavy — the WASI networking story is still maturing and may not meet your needs
You are running trusted, first-party code where container orchestration (Kubernetes, ECS) already provides sufficient isolation and operational tooling
You need a mature debugging and profiling ecosystem — WASM tooling is improving but still lags behind native debugging tools for languages like Rust, Go, or Java

Wasmtime — Fast & Secure WebAssembly Runtime

✅ Pros

⚠️ Cons