Firecracker microVM Jenkins: Why Your Build Agents Need a Real Kernel Boundary

Jenkins build agents run code nobody fully reviewed: public-registry dependencies, broad-permission plugins, old pipeline scripts. A container shares the host kernel, so a container escape is a host compromise. CreateOS Sandbox gives every Jenkins build its own Firecracker microVM with its own guest kernel, a host-enforced egress allowlist, and teardown the moment the build ends.

Introduction

A Jenkins controller orchestrates. The agents do the work: compile, test, package, publish. Anything an agent touches, an attacker wants, because agents hold credentials to your artifact registry, your cloud account, and often your production deploy keys.

The standard answer is a container per build. It is better than a shared agent, and it is not enough. Containers isolate processes, not kernels. A kernel bug in the host image is reachable from every container on that host. For builds that pull untrusted dependencies or run generated code, the isolation boundary has to sit below the operating system.

This post lays out what a Firecracker microVM changes for Jenkins build agents, which capabilities matter, and where the tradeoffs sit.

Key Takeaways

A container shares the host kernel. A Firecracker microVM has its own guest kernel, so the isolation boundary is the machine, not a namespace.
Egress control has to be enforced outside the guest. An allowlist enforced inside the VM can be rewritten by the code you are trying to contain.
Fresh state per build removes the residue problem: cached artifacts, mutated toolchains, leftover credentials.
CreateOS Sandbox ships an official Jenkins plugin, listed on the Jenkins plugin index, that provisions a microVM agent per build and destroys it when the build finishes.
The tradeoff is cold-start latency on a fresh host. Snapshot restore keeps it small, but it is not zero.

Why Jenkins Agents Need More Than a Container

Look at what a typical build agent does in an hour. It downloads packages from npm, PyPI, Maven Central, or a mirror. It executes post-install scripts from those packages. It runs plugins that have been granted broad Jenkins permissions. It holds secrets for publishing artifacts.

Supply-chain attacks target exactly this path. A compromised dependency does not need to escape your network perimeter. It is already inside, executing on your build agent, with your credentials in its environment.

A container limits the blast radius of a process-level compromise. It does not limit a kernel-level one. Shared-kernel escapes are a known class, and CI hosts aggregate the most untrusted code execution in your company. The constraint is simple: if the build runs code you cannot trust, the boundary must be a kernel the untrusted code does not share with anything else.

There is a second, quieter problem: state. Long-lived agents accumulate. A cached dependency gets poisoned. A toolchain gets patched in place. A credential file survives a job that should never have seen it. Ephemeral containers help, but anything mounted from the host, and the host itself, carries residue across builds.

What CreateOS Sandbox Gives a Jenkins Build

CreateOS Sandbox is Firecracker microVM infrastructure for untrusted or agent-written code. Every sandbox is a microVM with its own guest kernel. It is not a container and not a shared-kernel process namespace. Isolation sits at the machine boundary.

For Jenkins specifically, the pieces that matter:

A fresh microVM agent per build. The official CreateOS Sandbox plugin for Jenkins provisions a new microVM agent for each build and destroys it when the build finishes. No residue, no cached state, no leftover credentials. The plugin is maintained under the Jenkins organisation in the createos-sandbox-plugin repository.

Host-enforced egress allowlists. Outbound traffic from the build is governed by an allowlist enforced in the host kernel with eBPF, outside the VM. Outbound access is open until at least one rule is set, and the plugin's Sandbox Template has no egress field, so the allowlist is set on the sandbox itself through the CreateOS API or CLI, not in the plugin. Code inside cannot rewrite it or route around it. Rules cover IP, CIDR, and port, plus domain rules through a transparent proxy. If a compromised dependency tries to phone home to an attacker's server, the host drops the packet. This is the control a container runtime cannot give you, because the container runtime lives on the same kernel the workload can reach.

Pause, resume, and fork. Pausing writes a Firecracker snapshot of full guest state and stops compute billing. Resume restores that exact machine. Forking a paused sandbox branches its memory and working state, which suits parallel test shards or N candidate fixes where you keep the winner.

Bring your own. Storage can be your own S3-compatible bucket (S3, R2, MinIO). Compute can be your own machines, same API. If builds touch code that cannot leave your boundary, you can self-host the control plane and storage entirely.

Cost that follows usage. Per-second billing, $0 egress, and pause stops the meter. A build that waits twenty minutes on an external approval does not bill for the idle wait if you pause it.

What Is Shipped Today, and What Backs It

The claims above trace to shipped product, not a roadmap. The Jenkins plugin shipped 30 September 2026 and is listed on the Jenkins plugin index. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported. The agent rootfs must include a JVM.

The underlying sandbox platform is used at real scale: 2.6 million sandboxes created since June 2026, and CreateOS's own CI has run on sandboxes since July 2026. Uptime is 99%+. The infrastructure company behind CreateOS, NodeOps, has operated production infrastructure since December 2023.

On speed: sandbox creation restores from snapshot in tens of milliseconds, about 30 ms on an idle host (an idle-host figure, not an SLA). Pause takes about 1.4 seconds. Same-host resume is under 0.7 seconds. Cross-host cold start is 11 to 13 seconds. That last number is the tradeoff: a build scheduled onto a fresh host pays for the boot.

What to Weigh Before You Switch

Cold starts on fresh hosts. Snapshot restore is fast on a warm host. Cross-host cold start is 11 to 13 seconds. If your pipelines are thousands of tiny jobs, queue placement matters more than it does with warm containers.
JVM in the rootfs. The agent rootfs must include a JVM. If you maintain custom agent images, plan for that requirement.
No GPU sandboxes. Builds that need GPU acceleration are out of scope today.
Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. Trust here is architectural: Firecracker isolation, host-enforced egress, bring-your-own infrastructure. If your security review requires a certification artifact for this specific surface, ask before you commit.
It is a young product. The plugin, the SDK, and CreateOS's own CI on sandboxes are the usable proofs. If you need a decade of enterprise CI history, weigh that.

Frequently Asked Questions

Is there an official Jenkins plugin, or do I have to script the API myself?

There is an official plugin. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. It supports Declarative Pipeline and launches agents over Inbound WebSocket or SSH over the CreateOS tunnel.

How is a microVM different from the container-per-build pattern we already use?

A container isolates processes on a shared host kernel. A Firecracker microVM boots its own guest kernel, so a kernel-level escape from the build lands in a machine that exists for one build and is then destroyed. The host kernel is never shared with the workload.

Can a compromised build exfiltrate secrets over the network?

Only where your egress allowlist permits. The allowlist is enforced in the host kernel with eBPF, outside the VM, so code inside the sandbox cannot rewrite or route around it. No ingress by default. Set the rules to your artifact registry and package mirrors, and an attacker's callback address is unreachable.

What does it cost to run every build in its own microVM?

Billing is per second, egress is $0, and pausing a sandbox stops the meter. You pay for the compute a build actually uses, not for idle agents sitting in a pool. New accounts start with 500 free credits, and published unit rates are on the Sandbox pricing page.

Conclusion

Jenkins agents run the least trusted code in your company with the most trusted credentials attached. A container narrows the blast radius at the process level. A Firecracker microVM moves the boundary to the kernel, pairs it with egress control the workload cannot touch, and throws the machine away when the build ends.

Install the CreateOS Sandbox plugin for Jenkins. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install it from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.