Dora NodaFor two years, "WebAssembly will replace Docker" was one of cloud-native's loudest predictions. On December 1, 2025, that prediction quietly ended — not with WASM taking over Kubernetes, but with Akamai, an edge-CDN company, buying the startup that built the technology's best production case.
Here's the verdict up front: Spin and SpinKube are still worth adding to a self-hosted PaaS's build-target list — as an opt-in option for a narrow slice of workloads, not a Dockerfile replacement. The reason it's still safe to spend engineering time on them despite the acquisition is a fact most of the "WASM is dead" takes are skipping: Fermyon gave the code away before Akamai bought the company.
What Actually Happened
Akamai — the company best known for content delivery and DDoS protection, not for Kubernetes tooling — announced its acquisition of Fermyon on December 1, 2025, for an undisclosed sum. Fermyon's co-founders, Matt Butcher and Radu Matei, along with the rest of the team, joined Akamai's Cloud Technology Group. The deal wasn't a cold approach: the two companies had already been partnered for about a year, with Fermyon's runtime sold through Akamai's infrastructure before the acquisition made it official.
Read as a headline, it looks like the same story that's played out across infrastructure tooling for a decade: promising open-source project, VC-backed startup, eventual acquisition by a bigger company that folds the technology into its own roadmap. That's the frame the "container killer narrative just died" take assumes — that Spin and SpinKube now answer to whatever an edge-CDN vendor decides an edge-CDN vendor needs.
But there's a detail that changes the calculus: eight months before the acquisition closed, Fermyon donated Spin and SpinKube to the Cloud Native Computing Foundation — the same foundation that governs Kubernetes and Helm. That happened in early 2025, well before any acquisition talks were public. Spin and SpinKube are CNCF open-governance projects now, not Fermyon-owned code that came bundled into the deal. Akamai doesn't get to quietly deprioritize them the way an acquirer can deprioritize a project it fully owns — the roadmap runs through CNCF's process, with a community that has a vote, not just Akamai's product team.
Akamai has said publicly it will keep funding Spin, SpinKube, and Fermyon's Bytecode Alliance membership, framing the acquisition as adding engineering resources and global distribution rather than folding the project into a walled garden. That's a vendor's claim about its own intentions, worth exactly what any acquirer's promise is worth. The CNCF donation is worth more, because it's structural rather than promissory — the project's governance already changed hands before Akamai's money did.
The Technical Case Fermyon Actually Built
Strip away the "will WASM replace containers" framing and look at what Fermyon shipped, because the numbers are the reason anyone was talking about this in the first place.
Fermyon Platform for Kubernetes, built on SpinKube, claims 50x or greater workload density per node compared to standard container deployments — over 1,500 Spin applications running on a single Kubernetes node, well past the pod-count ceiling a typical cluster runs into with containers. The mechanism is straightforward: a Spin app is a WebAssembly module running inside a shared, sandboxed runtime instance, not a full container with its own filesystem layer and process namespace. That's also why cold starts land under 1 millisecond (versus 100ms+ for a cold container start), why a compiled Spin app ships as a 2–5MB artifact instead of a 100–200MB container image, and why an idle Spin instance's memory footprint stays under 1MB against a container's 20MB-plus baseline.
Those are vendor benchmarks, so the number worth trusting more is a customer's: ZEISS Group, the German optics and industrial-technology company, moved a Kubernetes batch process handling tens of thousands of orders onto Spin and cut compute cost by 60% without a performance regression. That's a concrete, third-party-verified outcome for exactly the kind of workload — high-volume, short-lived, stateless processing jobs — where WASM's per-instance overhead advantage compounds fastest.
That's a real efficiency story. It's also not a story about replacing every container workload a PaaS runs — which is where the "container killer" framing overreached from the start.
The other 2026 development worth noting alongside the acquisition: WASI 0.3, the WebAssembly System Interface spec that standardizes how a Wasm module talks to the outside world (networking, filesystem, clocks), reached stabilization this year with native async I/O support — closing one of the bigger gaps between "a sandboxed function that runs fast" and "a workload that can actually do real server-side work" without vendor-specific runtime extensions. That's a spec-level change, not a Fermyon product decision, and it matters more for Spin/SpinKube's long-term viability than anything in the Akamai deal — it's the Bytecode Alliance and W3C process moving forward regardless of who employs Spin's maintainers this quarter.
Where WASM Actually Fits in 2026 — and Where It Doesn't
The industry's own 2026 read on this has settled into coexistence rather than replacement, and the split follows workload shape more than hype:
Where Spin/WASM wins:
- Edge functions and request-routing logic — small, stateless, latency-sensitive
- API gateways and simple business-logic layers
- Multi-tenant function workloads where startup latency and per-instance memory directly drive cost, like ZEISS's batch job
- Plugin or extension execution where sandboxing untrusted code matters as much as speed
Where containers still win, and will for a while:
- Databases, message queues, and anything stateful with its own persistence layer
- Long-running or I/O-heavy processes that don't benefit from a cold-start-optimized runtime
- Arbitrary-language workloads — Wasm's language and library ecosystem, while growing, still doesn't match what a Dockerfile can run without friction
- Anything that needs the full Linux syscall surface a container gets by default and a Wasm sandbox deliberately doesn't
This is the honest 2026 scope, and it's narrower than "replace Docker" but real: WASM earns its place for a specific shape of workload, not as a general-purpose build target.
What This Means for a Self-Hosted Git-Push PaaS
For a platform like bex — where the default build path is Cloud Native Buildpacks turning a git push into a container image on Cluster API-managed hardware — the acquisition doesn't change the default. Buildpacks and Dockerfiles stay the build layer for the overwhelming majority of tenant workloads: web apps, APIs, background workers, anything stateful or arbitrary-language.
Where it's worth paying attention: Spin/SpinKube as an opt-in alternative build target, offered alongside buildpacks rather than replacing them, specifically for tenants running the workload shape Spin is actually built for — edge-style functions, request-routing logic, or short-lived multi-tenant jobs where the density and cold-start numbers above translate directly into lower compute cost on owned hardware. A CAPH-managed Hetzner fleet running thousands of Spin instances on a single node is a genuine cost story, not a marketing one, for the tenants whose workloads fit that shape.
What makes this worth building rather than waiting on is the governance fact from earlier: Spin and SpinKube left Fermyon's sole ownership eight months before Akamai's acquisition closed. That's what separates this from the standard "the company behind our dependency got acquired, now what" anxiety — the code's roadmap runs through CNCF's open process regardless of whose logo is on the company that pays some of its maintainers.
Concretely, that means a tenant opting into a Spin build path wouldn't look different from the buildpack path a tenant already gets by default — same git-push trigger, a different detected build target. A tenant shipping a small routing or edge-logic service might declare it explicitly:
# bex.yml
build:
target: spin
runtime:
cluster: caph-hetznerinstead of leaving target unset and falling through to buildpack auto-detection. The platform-side work is teaching the build pipeline to recognize a spin.toml manifest and route to SpinKube instead of Cloud Native Buildpacks — a second detected build target next to the existing one, not a replacement for it. That's a bounded, well-scoped addition precisely because Spin's scope is bounded: it only needs to handle the workload shapes from the section above, not the general case buildpacks already cover.
The Real 2026 Story
The container-killer narrative didn't die in this acquisition — it was never accurate to begin with. WebAssembly and containers were always going to end up as complements, not rivals, because they're optimized for different workload shapes: WASM for small, fast, sandboxed, ephemeral; containers for everything else. Akamai buying Fermyon is a CDN company betting that WASM's edge-latency story fits its own infrastructure, not a verdict on whether Docker survives 2026. It doesn't need to survive anything — it was never actually under threat.
For a self-hosted PaaS deciding what to build next, the acquisition is a reason to take Spin/SpinKube seriously as a second build target, not a reason to avoid it. The numbers are real, the case study is real, and the governance structure means the roadmap doesn't live or die with one company's cap table.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
