Rust/WASM Edge Functions vs Cloudflare and Vercel Edge

A V8 isolate is a lightweight JavaScript execution context inside the same V8 engine: no new system processes, no new kernel to start. This is the mechanism that Cloudflare first made public for Workers, and which Vercel reuses for its Edge Runtime. The objective is the same on both sides: to avoid the cost of a container or a VM for each request.

A WebAssembly module meets the same need through a different mechanism. The WASM bytecode runs in a bounded linear memory, defined by the specification itself. The guest module cannot address outside this area, regardless of the source language (Rust, C, Go…) that produced the binary. It is this model that Wasmtime applies in the wasm mode of Aurabase, detailed below. For startup measurements between the two mechanics, see our file on WebAssembly cold start benchmarks.

Each Aurabase function carries a runtime field which is worth "wasm" or "deno". The invocation engine chooses the execution path accordingly:

// Dispatch according to runtime: WASM (wasmtime) or Deno (V8 Isolates via edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy to aura-edge-runtime — V8 Isolates (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

The sandbox relies on three Wasmtime mechanisms combined. A CPU budget counted in “fuel”: each WASM instruction consumes it. A timeout applied in epoch increments: a dedicated thread increases the Wasmtime clock after the configured delay, which interrupts the current execution. A memory limit set via StoreLimits. The three terminals are configured when the engine is instantiated:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// Memory bounded by StoreLimits, initial fuel = max_fuel,
// timeout = epoch increment after timeout_secs (dedicated thread)

The compiled module is cached by code_hash: the same deployed binary is not recompiled on each call. Each invocation nevertheless instantiates a new Store and instance. No state leaks from one call to the next. The surface area exposed to the guest module remains deliberately minimal, five host functions in total: aura.log, aura.get_input, aura.set_output, aura.get_env and a stub env.abort for AssemblyScript compatibility. No host functions expose outgoing network calls at this time.

On the deployment side, the CLI compiles your crate locally before sending: aura functions new scaffolds a crate cdylib, aura functions deploy compiles it then sends it.

# Scaffolding: creates aurabase/functions/<name>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# cargo build --target wasm32-unknown-unknown --release, then upload
# POST /v1/functions/:project_id { runtime: "wasm", code: <wasm in base64> }
aura functions deploy my-fn

Cloudflare Workers natively run JavaScript and TypeScript in V8 isolates distributed across Cloudflare's global network. WebAssembly has been a first-class citizen since the beginning of the platform: a .wasm module can be imported directly into a Worker like any other module.

To write a Worker entirely in Rust, the most used route is the community SDK workers-rs, which compiles the code to wasm32-unknown-unknown and executes it in the Workers runtime. The difference with Aurabase's wasm mode is the available surface area. A Worker written in Rust via this SDK runs in the full Workers environment, and can therefore call fetch or other platform bindings. Aurabase's wasm mode starts from a deliberately reduced host surface (previous section).

Vercel's Edge Runtime also runs code in V8 isolates, with a subset of standard Web APIs (fetch, Request/Response, crypto.subtle…) rather than the full Node.js environment. Native Node modules and arbitrary compilation toolchains have no place there.

The WebAssembly object is part of this subset: nothing prevents you from loading a .wasm binary and instantiating it by hand from a JavaScript or TypeScript function. But to our knowledge, Vercel does not publish any official SDK or CLI to directly write an Edge Function in Rust, unlike workers-rs on the Cloudflare side or aura functions deploy on the Aurabase side. The path remains possible, but entirely manual, without dedicated tools.

A V8 isolate separates the code executed by a dedicated heap and its own context, within the same engine process. It is a proven mechanism, at the scale of millions of requests per second at Cloudflare and Vercel, but which remains a software isolation mechanism within a single JavaScript engine.

The WASM model isolates differently: each instance gets its own linear memory, a contiguous buffer outside of which no access is possible by construction of the binary format itself, independently of the engine that executes it. In the Aurabase runtime, each host function that manipulates a pointer provided by the guest module (aura.log, aura.get_env…) explicitly revalidates the bounds before any memory access. This is an additional defense in depth against a malicious or buggy module.

Aurabase runtime specifications. Cloudflare and Vercel columns described from the documented public architecture of each platform (isolates V8, WebAssembly as build target).

Pure calculation, without network calls: schema validation, data transformation, scoring, lightweight image generation. Aurabase's wasm mode is suitable directly, with a strict memory sandbox, an explicit CPU budget, and without dependence on an external service.

Function that calls a third-party API (payment, email, outgoing webhook). Aurabase's deno mode remains the default choice today, in the same way that a classic Cloudflare Worker or a Vercel Edge Function relies on fetch natively.

Team already invested in the Cloudflare ecosystem (KV, Durable Objects, R2). Staying on Workers makes sense; workers-rs allows you to introduce Rust gradually, without changing platforms.

Need a native Rust runtime managed end-to-end, with a dedicated CLI and the same language as the rest of the backend. This is the angle that documents in our Wasmtime vs Wasmer comparison, on the choice of the WebAssembly engine itself.