Spin Made WebAssembly Serverless. The Functions Are Still Trigger-Based.
by Nick Clark | Published March 28, 2026
Fermyon Spin is the most polished serverless framework that the WebAssembly ecosystem has produced. The Spin SDK targets Rust, JavaScript, TypeScript, Python, and Go through component-model bindings; the Spin trigger system maps HTTP routes, Redis subscriptions, and timer events onto handler entry points; the Spin app manifest describes the entire application declaratively; and Fermyon Cloud provides hosted execution at edge latency with cold-start times measured in single-digit milliseconds. For developers building event-driven services, Spin substantially improves on the Lambda-style experience that has defined serverless for a decade. The execution model, however, remains trigger-bound. A Spin component runs when an event arrives and stops when the handler returns. Memory-resident execution treats the execution unit not as a function summoned by an event but as an object that carries its own policy and runs from its own state, on its own cycle, without a server invoking it. The gap is between trigger-driven function hosting and object-carried, server-independent execution.
The analysis here treats Spin as a serious and well-engineered platform, and the gap it identifies is not a defect in Spin's design — Spin executes its chosen model unusually well. The structural observation is that the chosen model, function-as-handler bound to triggers, is one option in a broader space of execution architectures, and the memory-resident-execution primitive occupies a different region of that space. Comparing the two clarifies what each does and does not provide.
Trigger-based execution without continuity
A Spin application is a manifest plus a set of WebAssembly components. The manifest binds each component to a trigger: an HTTP route, a Redis channel, a scheduled timer. When the trigger fires, the Spin runtime instantiates the component, calls the bound entry point with event data, and tears the instance down on return. The runtime is unusually fast at this — Wasmtime instantiation is cheap and Spin's pre-initialization work amortizes well — but the model is fundamentally an instance-per-event one. Two consecutive events produce two distinct instances with no shared in-memory state.
Memory-resident execution requires the opposite: a single execution unit that persists across the events it observes, accumulates state in its own memory, and proceeds on its own cycle whether or not any external event arrives. The unit's memory is part of its identity, not a per-invocation scratchpad. Spin's instance-per-event model is precisely engineered to avoid the resource cost of long-lived state. That engineering choice is sound for the workloads Spin targets and incompatible with what memory-resident execution requires.
Key-value storage without governed memory
Spin acknowledges that some applications need state and provides a key-value interface, alongside SQLite and other resource stores, accessible through the Spin SDK. Components can read and write keyed values that persist between invocations, and Fermyon Cloud provides a managed backing store. The mechanism solves the simple statefulness problem: a counter increments correctly across requests, a session token survives between calls.
What it does not provide is governed memory. The key-value store is a passive data plane. There is no schema attached to its contents, no lineage tracked across mutations, no policy that constrains which writes are admissible, no observable history that subsequent reads can verify against. A memory-resident object's memory is, by contrast, a structured artifact: it carries the schema that defines its shape, the lineage that records its mutations, and the policy that admits future mutations. Reading and writing the memory is itself a governed operation, not an unmediated put-and-get against a backing store.
The trigger contract pushes policy outside the unit
In the Spin manifest, the trigger configuration — which routes a component handles, which channel it subscribes to, what authentication the runtime applies — lives outside the component itself. The runtime enforces those bindings; the component receives only the event payload. This separation is good engineering for hosted execution: the platform owns the dispatch, the developer owns the handler. The structural consequence is that the policy governing when, why, and on whose behalf the component runs is a property of the platform configuration, not of the component.
A memory-resident object carries its policy with it. The conditions under which it is permitted to advance, the credentials required to mutate its state, the observations it must record before producing output — all of these are bound to the object as a structural part of its definition, not as a manifest entry the platform reads. Move the object to a different host and the policy moves with it, because the policy is the object. In Spin, move the component to a different host and the manifest must move too, because the policy is the manifest.
No-server-required execution
Spin always presupposes a Spin runtime. The framework's value proposition is that the runtime is small, fast, and OCI-distributable, and Fermyon Cloud is one of several hosting options including self-hosted Spin and Kubernetes operators that schedule Spin workloads. The runtime is, however, never optional. A component does not execute outside a Spin host; the trigger system is the runtime, and the runtime is what makes the component reachable.
Memory-resident execution treats the execution unit as capable of advancing without a dedicated host. The unit's cycle is a property of the unit, and any environment with the verification primitives required to admit the unit's next step can serve as a substrate. There is no privileged runtime that owns the dispatch; there is the unit, its memory, its policy, and a substrate sufficient to verify the policy and apply the next mutation. The substrate may, in practice, be a WebAssembly engine — Wasmtime is an excellent candidate, and Spin's investment in fast Wasm startup is directly relevant — but the unit is not a Spin component, and the substrate is not Spin.
What memory-resident execution provides
Memory-resident execution defines an execution unit whose memory persists across cycles, whose policy is carried as part of the unit rather than external configuration, and whose advance does not require a server to invoke it. The unit's memory is governed: each mutation is admitted against the policy bound to the unit and recorded as lineage in the memory itself. The unit's cycle proceeds whenever a substrate sufficient to verify the policy is available, with no privileged dispatcher. The model is complementary to Spin's contribution rather than competitive with it: Spin demonstrates that WebAssembly execution can be fast, small, and broadly portable, and memory-resident execution can adopt those properties at the substrate layer while replacing the trigger contract above it. Spin made WebAssembly serverless. Memory-resident execution makes the executing object the locus of state, policy, and continuity, with or without a Spin host underneath.
