The business problem should be distinctive. The technology underneath it usually should not.
When we deliver software, it runs on our own WebAssembly runtime: one secure, opinionated shape. Application behaviour targets typed capabilities; infrastructure choices remain in the host. People and coding agents can concentrate on what the software must do instead of inventing its stack as well.
Reusable infrastructure and pipeline assets then carry that known shape from development to production. The business problem stays unique. The way the software runs and ships does not have to be invented again.
Built for people. Ready for generation.
The origin is three beats.
We built the runtime — Rust, on Wasmtime — so our engineers could stop selecting stacks. Instead of repeatedly choosing frameworks, importing provider SDKs and wiring infrastructure into application code, they wrote business behaviour against WASI-shaped capabilities such as SQL, key-value storage, blob storage, messaging and identity.
Generated code met our production bar in October 2025. We had been holding it to the same review and verification bar as hand-written code. We were not surprised by the direction — only by the date. The design decision that paid off had been made years earlier, for human engineers.
The same constraint now makes generation straightforward. Given a reviewed behavioural specification with explicit acceptance checks, the agent implements the declared business behaviour. It does not design the universe.
This is constraint as leverage:
fewer architectural choices for the agent to invent;
less provider-specific code mixed into business behaviour;
a consistent target for generation, testing and review;
familiar operational patterns across different business domains;
more attention spent on whether the software solves the right problem.
A Wasm-shaped solution
The runtime is lightweight — written in Rust on Wasmtime — and hosts WebAssembly components.
Application behaviour runs in sandboxed guest components. Guests request typed capabilities — such as HTTP, messaging, key-value state, SQL, blob or document storage, identity and observability — without embedding a concrete infrastructure client. The native host supplies the backend, credentials and deployment configuration.
This creates a clear boundary:
application behaviour lives in the guest;
infrastructure needs are expressed as typed capabilities;
technology choices are supplied by the host.
That consistent shape makes generated and hand-written code easier to review against the same expectations. It also makes it possible to apply the same development, testing and operational patterns from one engagement to the next. Almost everything we deliver ends up Wasm-shaped, regardless of the business problem. That is the point.
Why this bet, and not another
Standardising a platform is not a new idea. Containers with a service mesh, a heavily governed application framework, or serverless with shared libraries can each reduce repeated decisions. We chose the WebAssembly component model and WASI-shaped capabilities deliberately, and the reasons matter more — not less — now that much of the code is generated:
Sandboxed by default. A guest component has no ambient filesystem, network, process or environment access. For generated code, that is the right starting posture: an agent’s mistake, or a poisoned dependency, cannot reach anything the host did not explicitly grant.
Typed, narrow interfaces. Capabilities such as SQL, key-value state, blob storage and messaging are contracts, not conventions. Generated code either satisfies the interface or does not compile, which moves a whole class of review from human vigilance to the toolchain.
A deliberately small generation problem. The agent implements declared business behaviour against a known capability model. It does not select frameworks, import provider SDKs or design deployment architecture, so the search space — and the review surface — stays small.
Every grant is visible. What an application can touch is enumerable from its host configuration. Security review gets a concrete artefact instead of an archaeology exercise.
A well-governed framework can approximate some of this by discipline. The component model enforces it by construction — and construction is what holds when the volume of code, and the speed at which it arrives, keep increasing.
Reuse the path to production
Every system still needs environments, infrastructure, testing, security checks, deployment and observability. Recreating these foundations from scratch slows the first release and creates another unique platform the organisation must maintain.
The runtime is therefore only one part of a working delivery foundation. Propellerhead can apply reusable assets around a Wasm-shaped solution, including:
Terraform modules and compositions for AWS or Azure;
GitHub Actions workflows for build, test, security checks and deployment;
environment configuration and promotion patterns;
observability defaults and operational checks;
artefact creation and release conventions;
local backends for fast development and production backends for deployment.
These are Propellerhead delivery assets, not features of the runtime itself. They are adapted to the client’s security, networking, data, governance and operating requirements.
The result is a known starting point instead of an empty repository — not a claim that every system or organisation is identical.
Make production routine
A reusable foundation helps teams automate the route from accepted change to running software:
Build the guest component and host runtime.
Run automated tests and declared quality checks.
Create or update infrastructure through reviewed code.
Produce versioned, traceable artefacts.
Deploy consistently across environments.
Observe the result and retain a recovery path.
Separate deployment from user release where the product needs controlled exposure.
The exact controls remain proportionate to the system. A dependable path should be easy to use frequently, not impressive but too expensive to operate.
Keep application logic independent of today's infrastructure
Where the runtime has a conforming backend, the host can substitute it without changing or recompiling guest application logic.
That allows a team to:
develop and test against lightweight local implementations;
deploy the same guest against selected production services;
keep endpoints and credentials out of application code;
exercise application behaviour through different backend implementations;
change a supported backend with less application-code churn; and
preserve more choice over cost, residency and providers.
Portability changes architecture conversations now. Teams can define the capability the product needs before choosing the service that supplies it.
How spec-driven delivery and the runtime work together
Our spec-driven delivery engine, Emery, sits on top of coding agents rather than competing with them. Agents and model providers are improving quickly and becoming interchangeable; what is not interchangeable is the record of why the software exists, what it was specified to do and what evidence supported accepting it. The engine makes those durable artefacts — reviewed intent, specifications, exact execution inputs, visible gaps and verification results — the system of record. Chat history is not an audit trail.
Both halves are open source under MIT/Apache-2.0: our WebAssembly runtime, Omnia, and our spec-driven delivery engine, Emery, are public on GitHub. We would rather you read the code than take our word for it.
The WebAssembly runtime provides the target: sandboxed application components, explicit capabilities and host-selected infrastructure.
Reusable Terraform and GitHub Actions assets carry that target through environments and into operation.
In practical terms:
People establish the business outcome and accountable intent.
The delivery engine turns evidence and intent into reviewed, behaviour-focused specifications.
Coding agents implement the declared behaviour against the runtime’s known target.
The runtime keeps the application inside explicit capabilities.
Reusable delivery assets build, verify and deploy the result.
People decide what is accepted and released.
The delivery engine preserves why and what should be built. The runtime constrains how application behaviour meets infrastructure. The delivery foundation makes the route to production repeatable. Coding agents and model providers can change without discarding the delivery record.
WebAssembly runtime
Open source
Omnia
The constrained execution target—sandboxed guest components, typed capabilities and infrastructure supplied by the host.
Most tooling pages overclaim. We would rather state the boundary precisely, because the boundary is where your risk assessment actually happens.
The runtime is not a managed platform and does not offer broad multi-cloud support out of the box. It sits inside a client-owned solution; the host backends and cloud deployment assets available are named and verified for each engagement.
The portability promise is narrow and useful: supported host backends can change without changing or recompiling guest application logic. Data migration, provider-specific semantics, performance, cost and operational equivalence still require explicit work and verification against the target service.
The WebAssembly sandbox does not replace infrastructure security. Credentials still need appropriate scope, network and egress policy still apply, shared backends need appropriate isolation, and every linked capability or writable mount is a real grant. Host configuration is part of the security boundary.
The delivery engine’s workflow is review-gated and single-node. People authorise privileged execution, publication and release. We do not claim unattended delivery.
Model-assisted review is useful; it is not host-attested proof. Verification is described at the level actually achieved.
Terraform modules, GitHub Actions workflows and environment patterns are reusable Propellerhead delivery assets applied around a Wasm-shaped solution, not features of the runtime.
If a claim anywhere on this site ever seems larger than this list allows, the list wins.
This is the shape of software we deliver
Readiness and advisory work may stop before implementation. When Propellerhead writes the application, it runs on our WebAssembly runtime. The business problem stays unique. The way the software runs, is tested and is released does not have to be invented again.