WebAssembly as a first-class workload - next to your containers

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

Most orchestrators run containers. Orca runs containers and WebAssembly modules, as equal citizens. That's not a checkbox feature - it's a bet about where a lot of small workloads are heading, and it shaped the internals.

The same machine, two runtimes

Here's a Wasm service in the same config file as your containers:

[[service]]
name = "edge-fn"
runtime = "wasm"
module = "./modules/api.wasm"     # local path or OCI reference
triggers = ["http:/api/edge/*"]   # route these requests to the module
replicas = "auto"

[service.env]
API_KEY = "${secrets.edge_key}"

The only thing marking it as different from a container is runtime = "wasm" and a module instead of an image. Everything else - placement, secrets, env, domains, the reconciler that keeps it running - is identical.

That's deliberate. Internally, Orca has a single Runtime trait. There's a ContainerRuntime backed by Docker and a WasmRuntime backed by wasmtime, and the reconciler dispatches to whichever one a service declares. The scheduler doesn't know or care which it's placing. Adding Wasm as a first-class workload wasn't a special case bolted onto the container path; it was implementing one more Runtime.

If you've ever tried to graft a second execution model onto a system that assumed one, you know how much that abstraction is worth. The trait was the whole game.

Why bother, when containers exist

Containers are great. But a container is a heavy way to run a 200-line function that fires on an HTTP path. You're carrying a whole userland, a cold start measured in seconds, and a memory floor that makes "run a hundred tiny endpoints" expensive.

Wasm inverts those costs. A module is a few hundred kilobytes. It starts in milliseconds. The sandbox is the execution model, not a kernel feature you're trusting. For the class of workload that's really "a function behind a URL" - webhooks, edge transforms, glue endpoints, per-tenant customization - Wasm is structurally cheaper than a container, and it's not close.

Orca routes HTTP triggers straight to a module invocation. A request to /api/edge/* doesn't hit a long-lived container; it invokes the Wasm module. That's the seed of something I think matters for the kind of person this whole series is for: the self-hoster, the small team, the person running real things on modest hardware.

Where this goes: scale-to-zero

Here's the direction, stated honestly as direction and not as a shipped feature.

A container that serves an endpoint used twice a day still sits there, resident, costing you memory 24/7. A Wasm module that starts in milliseconds doesn't have to. It can genuinely scale to zero - nothing resident until a request arrives, spun up to serve it, gone again after. For a box hosting a long tail of rarely-hit endpoints, that's the difference between "I can afford to run all of these" and "I have to pick which ones survive."

That's the payoff I'm building toward: a small cluster where your handful of always-on containers coexist with an arbitrary number of scale-to-zero Wasm functions, all in the same service.toml, all reconciled by the same loop, all behind the same proxy and TLS. The container-only PaaS can't offer the second half of that. The abstraction that made Wasm a first-class runtime is what makes it reachable.

The through-line

If you've followed this series, you've seen the same instinct three times now: delete the dependency (secrets in git, no Vault), fix the disease not the symptom (the zombie-session liveness rewrite), refuse to guess (exact placement matching). Wasm-as-a-first-class-runtime is the same instinct pointed forward - build the one clean abstraction (Runtime) so that the next execution model is an implementation, not a rewrite.

That's what building an orchestrator for the gap between Coolify and Kubernetes actually feels like: not a smaller Kubernetes, but a different set of bets about what a small operator actually needs - and the discipline to keep the config on one screen while you make them.

Orca is open source (AGPL-3.0) on GitHub. If this series resonated, that's the best place to follow where it goes next.