WASM at the Edge: Cold Starts, Sandboxes and Which to Pick

Q: What exactly is a cold start, and why do isolates and Wasm sandboxes have smaller ones than containers?

A cold start is everything a platform does between a request arriving and your first line of code running: finding or creating an execution environment, setting up isolation, loading a language runtime, loading your code and running its initialisation. A container does all five steps. A microVM does all five but has shrunk the first two to a snapshot restore, which is why Firecracker documents boots under 125 ms and Lambda SnapStart reaches sub-second starts. A V8 isolate skips creating an environment and loading a runtime because both already exist in the host process; Cloudflare states an isolate starts around a hundred times faster than a Node process in a container and uses an order of magnitude less memory on startup. A Wasm sandbox also reuses a host runtime such as Wasmtime and additionally declares its imports up front, so the host wires exactly what is needed. The smaller cold start is not a feature that was added. It is the consequence of removing layers the code could otherwise have depended on.

Q: What are Cloudflare Workers' actual limits, and how do they shape the design?

Cloudflare's own limits page documents 128 MB of memory per isolate, including JavaScript heap and WebAssembly allocations, shared across all concurrent requests the isolate handles; when an isolate exceeds it, in-flight requests complete and a new isolate is created for subsequent ones. CPU time is 30 seconds per request by default and can be raised to 5 minutes on the Workers Paid plan, with waiting on network calls not counted. The average Worker uses about 2.2 ms of CPU per request, and heavier authentication, server-side rendering or payload parsing uses 10 to 20 ms. A Worker must parse and execute its global scope within 1 second or the deploy is rejected with error 10021, and the uncompressed bundle limit is 64 MiB. The design consequences are that per-request memory is not yours alone, that top-level initialisation is a deploy-time risk, and that CPU-heavy work belongs elsewhere.

Q: When is a WebAssembly sandbox the right edge boundary rather than a V8 isolate?

When the code is not yours: a customer's plugin, a partner's extension, a marketplace function, where you need a boundary with no ambient authority at all, which wasi.dev describes as a capability-based sandbox in which a module starts with nothing and can only do what the host explicitly grants. When the tenancy is hostile and a shared isolate, which the vendor built for its own multi-tenancy, is not a boundary you are willing to sign off on. When the same logic must run on a CDN edge, a Kubernetes cluster and a factory gateway from one build, which is the component portability case wasmCloud and Spin exist for. And when you need per-request isolation, which Fastly Compute provides by instantiating a fresh Wasmtime sandbox for every request. If none of those apply and the workload is JavaScript that an isolate serves well, Wasm is paying porting cost for nothing.

Q: When is Wasm the wrong choice at the edge?

When the code needs a kernel, a filesystem, arbitrary sockets, threads at scale or native libraries that have no WASI build; a Firecracker microVM or a container is the right boundary for that, and Lambda, Lambda MicroVMs and Cloudflare Containers all exist to serve it. When the workload is a JavaScript or TypeScript application that already runs well in a V8 isolate, where compiling to Wasm adds build complexity without changing the trust boundary. When the language toolchain for WASI is immature for the dependencies the team actually uses. When the team will not redesign around declared capabilities, because a sandbox that refuses ambient authority will refuse their code. And when the function is a thin proxy to a single-region origin, where the microseconds saved on start are irrelevant beside the 80 to 200 ms spent on the network and the egress billed for the round trip.

Q: What changed with WASI 0.3, and does it contradict what AppScale wrote earlier about the Component Model?

wasi.dev now lists three shipped milestone releases, 0.1, 0.2 and 0.3, and states that 0.3 adds native async support to the Component Model and refactors WASI interfaces to use stream and future primitives. Our earlier Component Model article, written when 0.2 was current, described 0.3's async as arriving and reference runtimes as shipping release-candidate snapshots. That was accurate at the time and is now superseded: 0.3 is a released milestone, and Wasmtime v50.0.0 shipped on 2 October 2026. The practical consequence is the same one that article anticipated. A streaming or long-lived connection workload built on 0.2's blocking interfaces will need to move to 0.3, so new streaming work should start on 0.3 and accept that the runtime support is new.

Q: How do microVMs compare, and when should you pay for SnapStart or provisioned concurrency?

Firecracker's project page documents boots in under 125 ms, up to 150 microVMs per second per host, under 5 MiB of memory overhead per VM and only five emulated devices, which is why it is the isolation layer under AWS Lambda and the managed Lambda MicroVMs. A microVM gives your code a real Linux kernel and filesystem, which is why it can run arbitrary binaries and why its start is two to three orders of magnitude slower than an isolate. AWS documents that initialisation is the largest contributor to cold start, that SnapStart snapshots the initialised environment at publish time and restores from it for sub-second starts on Java 11+, Python 3.12+ and .NET 8+, with caching charged per published version at a 3-hour minimum plus a restoration charge, and that provisioned concurrency is the option for double-digit millisecond requirements. Pay for either when the function genuinely needs a kernel. If it does not, the cheaper fix is to make it an isolate or a Wasm component.

Q: How should a team decide, function by function, which sandbox to use?

Ask four questions in order. Whose code is it: yours and trusted goes to an isolate or your existing stack; a customer's or partner's goes to a Wasm sandbox if it can be a component and a microVM if it needs a kernel. What must it touch: HTTP, key-value and nearby data only means isolate or Wasm; files, arbitrary sockets, native libraries or a GPU means microVM or container, and if the list cannot be written down the function is not finished being designed. How long and how much memory: under 128 MB and 30 seconds of CPU fits an isolate or Wasm; up to 10 GB and 15 minutes fits Lambda or a container. Where does the data live: at the edge or replicated, a fast sandbox pays off; in one region behind a connection pool, the edge function's job shrinks to routing and the real decision is Lambda versus Fargate. When one workload answers differently for different functions, split it.

Q: What are the most common anti-patterns in edge compute selection?

Choosing the platform by its cold-start number and discovering the memory ceiling or per-request teardown afterwards. Doing heavy work in global scope, which Cloudflare rejects at 1 second of startup CPU and other platforms silently charge on every cold request. Building a thin proxy to a single-region origin, where the sandbox saves microseconds and the network spends 100 ms plus egress. Treating a shared isolate as a tenant boundary for mutually untrusted customer code when the vendor built it for its own multi-tenancy. Porting code between memory models, from Lambda's per-invocation allocation to a 128 MB shared isolate or from a warm Workers isolate to Fastly's per-request teardown, without noticing. Building a streaming workload on WASI 0.2's blocking interfaces and rewriting for 0.3 later. And buying the cold start away with provisioned concurrency, SnapStart caching or pre-warming for a function that could have been an isolate.

Q: What does a mature edge compute practice look like?

Every function has a written capability list of what it reads, writes and calls, and that list, not a benchmark, decides its boundary. Startup time and memory are measured per function and gated in CI with the platform's own tooling, such as Wrangler's reported startup_time_ms. At least two boundaries exist, an isolate tier for trusted HTTP-and-data logic and a microVM or container tier for functions that need a kernel, and thin proxies have been moved next to their data or collapsed into routing. Untrusted and polyglot logic is built as WASI components with WIT interfaces that run on Fastly, Spin, wasmCloud or an embedded Wasmtime from one build, with streaming paths on 0.3 async, and customer code never runs in a shared isolate. At the top, placement is a policy: the platform team places each function on isolate, Wasm, microVM or container from its declared capabilities and measured profile, and reports start latency, memory and egress per function as one cost.

Satyam Kumar

Back to Blog

multi-cloud-infrastructure

WASM at the Edge: The Cold Start Is the Price of the Trust Boundary, So Choose the Sandbox by What the Code Must Be Allowed to Do (2026)

By Satyam KumarOctober 8, 202621 min read

wasm at the edge webassembly edge computing edge serverless cold start v8 isolates vs containers cloudflare workers limits fastly compute wasmtime wasi 0.3 async wasmtime v50 spin framework wasm wasmcloud cncf firecracker microvm cold start lambda snapstart cold start edge compute platform comparison wasm sandbox multi-tenant capability-based sandbox wasi edge runtime selection 2026

WASM at the Edge: The Cold Start Is the Price of the Trust Boundary, So Choose the Sandbox by What the Code Must Be Allowed to Do (2026)

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

WASM at the Edge: The Cold Start Is the Price of the Trust Boundary, So Choose the Sandbox by What the Code Must Be Allowed to Do (2026)

Frequently Asked Questions

Share this article

Comments

Leave a comment