Spin: a WebAssembly serverless runtime with a CLI-first workflow

What Spin is for, and who it is aimed at

Spin is a framework for building, deploying and running cloud microservices compiled to WebAssembly. The README describes it as aiming to be the easiest way to get started with WebAssembly microservices, and it leans on two upstream pieces: the WebAssembly component model and the Wasmtime runtime. The repository is the CLI and runtime side of that story, written in Rust, licensed Apache-2.0 WITH LLVM-exception, and published under the spinframework organization.

The audience is narrower than "anyone who wants serverless". If you already write Rust, JavaScript, Python or Go and want those services to run as Wasm components behind an HTTP or Redis trigger, Spin gives you a template, a build command and a local server. The SDK list makes the boundary explicit: the framework team supports JavaScript, Rust, Go and Python, while Zig and Moonbit integrations are third-party and maintained by their authors. C# appears in the feature table but is not listed among the team-supported SDKs in the same sentence.

The trigger model is the part that shapes application design. HTTP is the default entry point, Redis is a second supported trigger in the Rust, TypeScript and Python SDKs, and custom triggers can only be authored from Rust. That last row of the support table is worth reading twice: it means extensibility beyond the built-in triggers is a Rust-only path.

How a Spin application is structured and executed

A Spin app is a directory with a manifest, source, and a build command that produces a Wasm component. The CLI is the control surface: spin new scaffolds from a template, spin build runs the per-component build command, and spin up starts a local server. The README's example output shows the build step executing cargo build --target wasm32-wasip2 --release, which tells you the compilation target is wasip2, the component-model preview 2 target, not the older wasm32-wasi.

At runtime the CLI maps routes to components and serves them on a local port. In the README example the app listens on http://127.0.0.1:3000 and the route table lists the component as a wildcard route at the root. Component stdout is captured to .spin/logs/, which is a small detail with real consequences: if you are debugging with print statements, you read them from a file rather than the terminal.

Beyond triggers, the runtime exposes host APIs that components call into: outbound HTTP, configuration variables, key-value storage, SQLite storage, MySQL and PostgreSQL, outbound Redis and Serverless AI. These are implemented by the host (the Spin runtime), not by your component, which is why the support table is per-SDK: a capability exists in the runtime but your language binding may not expose it. The table shows MySQL unsupported in Python, and key-value, SQLite, Redis triggers and Serverless AI unsupported in C#.

The repository layout matches that architecture. The CLI lives at the top level with crates/ split into spin-app, spin-build, spin-common and others, wit/ holds the interface definitions, templates/ holds the scaffolding used by spin new, and examples/ contains runnable projects including http-rust, http-middleware, http-cpp, open-ai-rust, spin-timer and vault-variable-test.

Installing Spin and running a first Rust app

The README points at the install page of the documentation site for a detailed guide, and gives a short path in the meantime. The script downloads the CLI and you then move the binary onto your PATH. The two commands below are quoted from the README.

curl -fsSL https://spinframework.dev/downloads/install.sh | bash
sudo mv ./spin /usr/local/bin/spin

After that you need the Wasm target for Rust, because the generated Rust template compiles to wasm32-wasip2. The README states this requirement before the usage example.

rustup target add wasm32-wasip2

Now scaffold an application. The --accept-defaults flag takes every template default, and -t names the template; the trailing argument is the project directory. The README uses http-rust and the name hello-rust.

spin new --accept-defaults -t http-rust hello-rust
cd hello-rust
spin build

spin build prints the underlying cargo invocation and a success line per component. Then start the local server and call it.

spin up

The README shows the expected output: a log line telling you component stdio is written to .spin/logs/, a serving line for http://127.0.0.1:3000, and a route list. In another shell, curl -i 127.0.0.1:3000 returns HTTP/1.1 200 OK with content-type: text/plain and the body Hello World!. From there you edit src/lib.rs and rerun the build. If you prefer not to use the install script, the README also links a build-from-source path, and the Makefile's install target runs cargo install --path . --locked.

Where the SDK support table bites

The most useful page in the repository is not the front page copy; it is the language support matrix, because it is where the abstraction leaks. Spin presents itself as language-agnostic, and WebAssembly is, but the SDK bindings are not uniformly complete. If you are writing Python and need MySQL, the table says that combination is not supported. If you are writing C# and need key-value storage, SQLite storage, a Redis trigger or Serverless AI, the same applies.

That asymmetry has a practical consequence for architecture decisions. Choosing Spin means choosing both a runtime and a language binding, and the binding determines which host APIs you can reach. A feature that exists in the runtime and in the Rust SDK may be absent in the SDK you actually write. The README does not present this as a temporary gap or give a timeline, so treat the table as the current contract rather than a roadmap.

Custom triggers are the sharpest edge. Only the Rust SDK is marked supported for authoring them. If your design depends on a trigger that Spin does not ship, you are writing Rust, regardless of what the rest of your services are written in. That is a real constraint, not a documentation omission.

There is also a toolchain constraint visible in Cargo.toml: the workspace declares rust-version = 1.96 and edition 2024. If you build Spin from source or use the Rust SDK, your toolchain has to satisfy that floor.

Spin compared with a container-based serverless stack

The natural alternative is a container-based serverless platform: you write a normal service, package it as a container image, and the platform handles routing and scaling. The difference in approach is the unit of deployment. Spin deploys a Wasm component built against a host interface defined in wit/, so the runtime, not your image, provides storage, outbound HTTP and configuration. A container stack deploys your whole userland, so you bring your own database driver and your own HTTP client.

That trade runs in both directions. Spin's model gives you a smaller artifact and a runtime that mediates capabilities, which is why the support table can exist at all: the host has to expose the API before your SDK can bind to it. A container gives you the entire ecosystem of your language immediately, at the cost of a larger artifact and a heavier startup path.

There is a second alternative worth naming for people who arrive at this repository by the wrong search. Spin is not the SPIN model checker, a formal verification tool for concurrent software, and it is not SPIN Selling, a sales methodology. The name collision is common enough that the search data for this project includes both. If you came looking for either of those, this repository is unrelated.

Maintenance, release cadence and licence

The repository is not archived, and the last push was on 2026-09-21. Releases are tagged and versioned: v4.0.1 on 2026-06-09, v4.0.2 on 2026-06-24, and v4.1.0 on 2026-08-26. The workspace version in Cargo.toml reads 4.2.0-pre0, which indicates development is continuing past the 4.1.0 tag. The project publishes a ROADMAP.md, a GOVERNANCE.md, a MAINTAINERS.md and a SECURITY.md at the top level, and the README points to a Slack channel for the community.

Upgrade cost depends on how much of the host API surface you use. The CLI is a single binary, so replacing it is cheap, but the SDKs are separate repositories and separate version streams, and the support matrix can shift between releases. The safest upgrade check is to rebuild your components against the new CLI and confirm that every host API you call is still listed as supported for your language in the documentation's language support overview.

The licence is Apache-2.0 WITH LLVM-exception. That is a permissive licence with an additional exception clause. Nothing here is legal advice; if the exception matters for how you redistribute a modified Spin, read the LICENSE file and the exception text rather than relying on the SPDX identifier alone.

Editorial conclusion

Adopt Spin if you are building HTTP or Redis-triggered services in Rust, JavaScript, Python or Go and want a local loop that compiles to Wasm and runs with spin up. Do not adopt it if your code depends on MySQL from Python, or on key-value, SQLite or Serverless AI from C#, since the support table marks those as not supported. Before you commit, install the CLI, run spin new --accept-defaults -t http-rust hello-rust, and confirm that the wasm32-wasip2 target builds on your toolchain, because that target is a prerequisite the README states up front.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. spinframework/spin on GitHub