Spin Made WebAssembly Serverless. The Functions Are Still Trigger-Based.
by Nick Clark | Published March 28, 2026
Spin provides a developer-friendly framework for building serverless WebAssembly applications that respond to HTTP requests, Redis messages, and other triggers. The developer experience is excellent. But Spin functions are trigger-based: they execute when an event arrives and terminate when processing completes. They do not maintain persistent state between invocations, carry their own execution cycle, or self-evaluate. The gap is between serverless function hosting and memory-resident objects that execute from their own state.
Spin's developer experience and WebAssembly-native serverless model provide genuine improvements in function hosting. The gap described here is about the execution model.
Trigger-based execution without continuity
A Spin application defines handlers for triggers: HTTP routes, Redis channels, or timers. When a trigger fires, Spin instantiates the WebAssembly module, calls the handler, and discards the instance after completion. There is no state continuity between invocations. Each invocation starts fresh.
Memory-resident execution requires continuity: state that persists across cycles, memory that accumulates, and governance that validates continuously. Spin's model is optimized for stateless triggers, not stateful self-execution.
Key-value storage without governed memory
Spin provides key-value storage for persisting data between invocations. This addresses the statefulness gap at the infrastructure level. But key-value storage is a data store, not governed memory. There is no schema, no lineage, no governance on mutations.
What memory-resident execution provides
Memory-resident execution objects maintain persistent governed memory across execution cycles. They self-evaluate on each cycle, not just when triggered. Their memory includes lineage tracking and governance validation. Spin's efficient WebAssembly runtime could serve as the compute substrate. Memory-resident execution would add continuous self-evaluation and governed state above the trigger model.
