WebAssembly Runtime

WebAssembly Runtime

The WASM runtime is an experimental extension. Configuration is stable, but runtime internals may change between releases.

Wippy runs WebAssembly modules as first-class registry entries alongside Lua code. WASM functions and processes execute within the same scheduler, share the same security model, and interoperate with Lua through the function registry.

Entry Kinds

Kind	Description
function.wat	Inline WebAssembly Text format function defined in YAML
function.wasm	Precompiled WASM binary loaded from a filesystem entry
process.wasm	WASM binary executed as a process (CLI commands or long-running)

How It Works

1. WASM modules are declared as registry entries in _index.yaml
2. At boot, modules are compiled and placed into worker pools
3. Lua (or other WASM) code calls them via funcs.call()
4. Arguments and return values are automatically mapped between Lua tables and WIT types
5. Async operations (I/O, sleep, HTTP) yield through the dispatcher, same as Lua

Component Model

Wippy supports the WebAssembly Component Model with WIT (WebAssembly Interface Types). Component modules get full type mapping between the host and guest:

• Records map to Lua tables with named fields
• Lists map to Lua arrays
• Results map to (value, error) return tuples
• Primitives (s32, f64, string, etc.) map directly

Raw/core WASM modules are also supported with explicit WIT signatures.

Calling WASM from Lua

WASM functions are called the same way as any other function in the registry:

local funcs = require("funcs")

-- No arguments
local result, err = funcs.call("myns:answer_wat")

-- With arguments
local result, err = funcs.call("myns:compute", 6, 7)

-- With complex data
local users = {
    {id = 1, name = "Alice", tags = {"admin"}, active = true},
    {id = 2, name = "Bob", tags = {"user"}, active = false},
}
local transformed, err = funcs.call("myns:transform_users", users)

Security

WASM executions inherit the caller’s security context by default:

• Actor identity is inherited
• Scope is inherited
• Request context is inherited

Host capabilities are opt-in through explicit imports. Each entry declares exactly which WASI interfaces it needs (wasi:cli, wasi:filesystem, etc.), limiting the module’s access surface.

See Also

• Functions - WASM function entry configuration
• Host Functions - Available WASI and Wippy host interfaces
• Processes - Running WASM as long-lived processes