CI Isolation: MicroVM, Container or WASM?

CI Isolation: MicroVM, Container or WASM?

Ci isolation is a boundary question wearing a performance costume. Teams ask "which is fastest" and then get burned by "which boundary did we actually need". MicroVMs, containers and WASM sandboxes draw the line in three different places, and your workload's behaviour decides which line is cheap and which is theatre.

This guide gives you the decision order we use. For scale, the Firecracker paper reports 125 ms microVM boots and under 5 MiB overhead per VM, while a warm container start typically lands near 50 ms.

Those gaps are small next to a 10-minute test suite, which is why boundary choice should lead, and why performance arguments usually settle second in any honest review. Teams that invert the order pay compatibility tax on workloads that never needed the strong boundary at all.

Three boundaries, drawn differently

A container shares the host kernel and isolates through namespaces and seccomp; the boundary is a policy the kernel enforces on shared code. A microVM gives each workload its own guest kernel on a hypervisor, as Firecracker's documentation describes, so a kernel exploit stays inside the guest. A WASM sandbox isolates at the runtime: modules see only capabilities the host grants, per the WASI capability model, and cannot touch sockets or files they were not given. Strongest default boundary goes to the microVM; strongest least-privilege model goes to WASM; best compatibility per millisecond goes to containers.

Workload-first decision list

1. Jobs run arbitrary third-party dependencies or user code: microVM. You cannot audit what you did not write.
2. Jobs run your own code with Linux toolchains, needing raw syscalls and sockets: container, with tight seccomp.
3. Jobs are pure compute plugins with a narrow capability needs: WASM, where denial is the default.
4. Mixed pipeline: layer them, WASM inside containers inside a microVM host, each layer buying what it is good at.

The list looks obvious until a team argues about it for a quarter. Writing down the trustworthiness of each job's code ends that argument permanently, and it gives new hires a one-page answer to the oldest platform question.

The same reasoning appears in our online judge guide, where submitted code is the worst-case tenant, and in Firecracker versus Docker tradeoffs, where the boot-time gap is priced against the boundary gain.

What breaks at each boundary

Containers break your threat model first: a kernel bug is a shared bug, and CI runners are famously rich in kernel-facing bugs. MicroVMs break latency-sensitive interactive loops unless you use snapshots, and they cost memory per guest. WASM breaks anything that expects a POSIX world: no forks, no arbitrary syscalls, limited threading, and a toolchain that must compile to wasm. We found most failed migrations skipped this inventory step and discovered incompatibilities in production.

Operating the choice

Whatever you pick, keep images small and caches warm, because isolation multiplies cold starts across every job. Per-job ephemeral runners remove cross-job contamination entirely, the pattern we recommend in self-hosted CI runners. Measure p95 job latency before and after the boundary change; if the tax exceeds your risk appetite, move one layer down for trusted jobs only.

A migration order that works

Move the riskiest job first: anything executing third-party or user-supplied code goes to microVM runners in week one. Keep trusted build jobs on containers while you measure the latency tax, and pilot WASM only for plugins with narrow capability needs.

Reverse the order and you pay the compatibility tax on workloads that never needed the strong boundary, which is how isolation projects lose executive support. Risk first, comfort later, and only where the measurement says so.

Verdict

Choose the boundary from the trustworthiness of the code, then pay the performance tax only where the code deserves it. Untrusted in, microVM; trusted and syscall-hungry, container; narrow and portable, WASM. Mixing layers is not compromise, it is engineering.

Limitations

• Boundary strength descriptions are architectural defaults; however, misconfiguration weakens any of the three.
• We cannot benchmark three technologies head-to-head here; latency claims are directional.
• WASM toolchain compatibility moves fast, so the breaks list ages quicker than the rest.
• Your kernel patch cadence changes the container risk calculus, but ours is not yours.

FAQ

Is gVisor a fourth option?

Yes, gVisor is a kernel-interposition layer between container and microVM in both cost and boundary; treat it as a middle setting.

Can WASM sandboxes replace containers in CI?

Only for workloads compiled to wasm with narrow capability needs. General build toolchains still need an OS-shaped world.

What is the cheapest safe default for untrusted jobs?

Ephemeral microVM runners with snapshots and warm caches: the boundary of a VM with boot costs approaching containers.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "CI Isolation: MicroVM, Container or WASM?",
      "datePublished": "2026-10-25",
      "dateModified": "2026-10-25",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/ci-isolation-microvm-container-or-wasm"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Is gVisor a fourth option?",
          "acceptedAnswer": {"@type": "Answer", "text": "Yes, a kernel-interposition layer between container and microVM in both cost and boundary; treat it as a middle setting."}
        },
        {
          "@type": "Question",
          "name": "Can WASM sandboxes replace containers in CI?",
          "acceptedAnswer": {"@type": "Answer", "text": "Only for workloads compiled to wasm with narrow capability needs. General build toolchains still need an OS-shaped world."}
        },
        {
          "@type": "Question",
          "name": "What is the cheapest safe default for untrusted jobs?",
          "acceptedAnswer": {"@type": "Answer", "text": "Ephemeral microVM runners with snapshots and warm caches: the boundary of a VM with boot costs approaching containers."}
        }
      ]
    }
  ]
}