wasmtime run: Execute a Wasm Module in CI
wasmtime run loads a .wasm or .wat module and runs it, granting filesystem and env access only where you allow it.
Wasmtime is the Bytecode Alliance runtime. In CI it runs WASI binaries produced by Rust, C, or Go, with a deny-by-default sandbox you open with explicit flags.
What it does
wasmtime run compiles the module with Cranelift, instantiates it, and invokes its entry point (WASI _start by default). The sandbox blocks all host access until you grant directories with --dir and variables with --env.
Common usage
wasmtime run app.wasm
wasmtime run --dir=. app.wasm arg1 arg2
wasmtime run --dir=./data::/data app.wasm
wasmtime run --env KEY=value app.wasm
wasmtime run --invoke add module.wasm 2 3Options
| Flag | What it does |
|---|---|
| --dir <host[::guest]> | Preopen a host directory for WASI (optionally remap the guest path) |
| --env <NAME=VALUE> | Pass an environment variable into the guest |
| --invoke <func> | Call a specific exported function instead of _start |
| -S <feature> / --wasi | Toggle WASI features (e.g. -S http, -S threads) |
| --dir=. -- | Everything after -- is passed as argv to the guest |
In CI
Preopen directories explicitly with --dir; the sandbox denies filesystem access by default, which is the top reason a locally passing run fails in a pipeline. Pin the runtime version (setup step or a cached binary) so Cranelift codegen and WASI feature defaults do not drift.
Common errors in CI
"failed to parse WebAssembly module" means the file is not valid wasm (truncated, wrong file, or a wat that was not assembled). "unknown import: wasi_snapshot_preview1::..." means the module targets WASI but was run without WASI enabled, or the preview1 vs preview2 ABI mismatches. "failed to find a pre-opened file descriptor" means the code opened a path you did not --dir.