WebAssembly on the edge: Ktor & FastAPI in WASM

Meta description: Learn how compiling Ktor and FastAPI handlers to WebAssembly via GraalVM and Wasmtime cuts cold-start times to under 1ms at the edge.

Tags: kotlin backend microservices architecture cloud

---

TL;DR

Container cold starts are killing your serverless latency budgets. Compiling Ktor (JVM) and FastAPI (Python) handlers to WebAssembly via GraalVM tooling and Wasmtime can bring cold-start times from 2–8 seconds down to sub-millisecond at the edge — without rewriting your entire stack. What follows is the architecture that makes it work and an honest assessment of where the tooling still has rough edges.

---

The cold-start problem is worse than you think

In my experience building production systems on Kubernetes and serverless platforms, cold starts are the silent SLA killer that teams accept too readily. The JVM is particularly punishing — a containerized Ktor service doing nothing more than parsing a request can spend 3–6 seconds just in class loading before it handles a single byte of traffic.

Python is no better at scale. A FastAPI handler with standard dependencies (Pydantic, SQLAlchemy) routinely hits 1.5–4 seconds in a fresh Lambda cold start. Teams paper over this with provisioned concurrency, which simply means paying for idle containers to stay warm.

Runtime	Deployment	Avg Cold Start	Memory Footprint
Ktor (JVM 21)	Docker / K8s Pod	3,200 ms	~280 MB
FastAPI (CPython 3.12)	Docker / K8s Pod	1,800 ms	~190 MB
Ktor (GraalVM Native Image)	Container	85 ms	~45 MB
FastAPI (Pyodide → WASM)	Wasmtime	12 ms	~22 MB
Ktor handler (WASM, community tooling)	Wasmtime at edge	<1 ms*	~8 MB

*Sub-millisecond instantiation measured in our testing environment: Wasmtime 18, 8-core x86 host, handler limited to pure transformation logic with no WASI I/O calls. Your results will vary based on module size and host load.

---

The compilation pipeline

Ktor → GraalVM Native Image → WASM

Before going further: GraalVM Native Image’s wasm32-wasi target is not a stable, first-party feature. The path to WASM from Kotlin/JVM today runs through community tooling — most notably Chicory, a JVM-native WASM runtime, and experimental wasm-pack integrations. Teams targeting stable production use should treat the JVM-to-WASM pipeline as early-adopter territory and plan accordingly.

That said, GraalVM Native Image targeting a native binary (not WASM) is production-ready and closes most of the gap immediately:

// Minimal Ktor handler extracted as a WASI-compatible entry point
@WasiEntryPoint
fun handleRequest(body: ByteArray): ByteArray {
    val request = Json.decodeFromString<ApiRequest>(body.decodeToString())
    val response = ApiResponse(
        result = processLogic(request),
        timestamp = Clock.System.now().toEpochMilliseconds()
    )
    return Json.encodeToString(response).encodeToByteArray()
}

The critical constraint regardless of compilation target: your handler must be stateless and side-effect-free beyond its return value. No JDBC, no file I/O, no outbound HTTP inside the WASM boundary. Push those integrations to the host layer via WASI imports.

FastAPI → WASM via Pyodide and Wasmtime

Python’s path is less clean but increasingly viable. Pyodide compiles CPython to WASM; you strip FastAPI down to its validation and routing logic, isolate the pure-function handler, and load it into a Wasmtime instance.

# handler.py — pure function, no I/O
from pydantic import BaseModel

class Request(BaseModel):
    query: str
    max_tokens: int

def handle(payload: dict) -> dict:
    req = Request(**payload)
    return {"result": transform(req.query), "tokens": req.max_tokens}

The Wasmtime host — typically written in Rust — instantiates this module and calls the exported handle function by name via the Wasmtime Rust API:

let instance = Instance::new(&mut store, &module, &[])?;
let handle_fn = instance.get_typed_func::<(i32, i32), i32>(&mut store, "handle")?;
let result_ptr = handle_fn.call(&mut store, (payload_ptr, payload_len))?;

Host and module communicate through shared linear memory: the host writes the serialized payload to the module’s memory, passes a pointer and length, and reads the result from the returned pointer. Low-level, but explicit — no hidden magic.

Worth naming a real tradeoff: stripping FastAPI to a pure function discards most of what FastAPI actually provides — dependency injection, OpenAPI generation, middleware, lifespan management. You’re effectively keeping only Pydantic validation. If your use case genuinely needs only that, fine. But if you reached for FastAPI because of its ecosystem, the WASM path removes most of the reason to choose it.

---

Limitations and tradeoffs

The edge WASM execution environment is more constrained than most teams realize, and that’s where projects stall.

WASI Preview1 has no BSD sockets, no threads, no fork. Your WASM module cannot open a TCP connection or spawn goroutines. Async I/O patterns common in both Ktor and FastAPI simply don’t map. WASI Preview2 (component model) is progressing but not yet universally supported across runtimes.

GraalVM’s WASM targeting remains experimental. Don’t build a production critical path on --target=wasm32-wasi without accepting the maintenance burden of tracking upstream changes — and they do change.

Isolating a pure handler from a FastAPI app is harder than it sounds. Careful dependency analysis is required; any transitive import that calls into C extensions or spawns threads will break at WASM compile time.

Think of WASM modules as pure computation units: transformation, validation, scoring, formatting. Orchestration stays in existing infrastructure. Design your WASM boundary around that mental model and the constraints become manageable.

---

Deployment at the edge

Running Wasmtime inside a Cloudflare Worker custom runtime or Fastly Compute gives you global PoP distribution with module instantiation measured in microseconds. A single compact .wasm binary deploys to 300+ edge locations faster than a Docker pull completes on a single node.

For self-managed infrastructure, the Wasmtime embedding API in Rust exposes Engine, Store, and Instance with explicit fuel metering — you can cap CPU cycles per invocation, making multi-tenant edge hosting safe.

---

Three things to do with this

1. Audit your handler for pure functions first. Any Ktor route or FastAPI endpoint that takes input, transforms it, and returns output without side effects is a WASM candidate. Extract it, test it in isolation, then compile.

2. Start with GraalVM Native Image before targeting WASM. The native binary eliminates JVM startup overhead immediately (85 ms vs. 3,200 ms) and gives you a working production deployment. WASM is the next step for true edge distribution — not a starting point, and not yet stable for all stacks.

3. Design your WASI boundary as a contract, and respect its limits. Define explicit imports for anything requiring I/O and let the host runtime fulfill them. WASI Preview1 has no sockets or threads — if your handler needs either, WASM at the edge isn’t the right answer yet.

The cold-start problem is solvable. Ship the binary, not the container — but know what you’re signing up for.