A Jenkins plugin that gives every build its own microVM and a network allowlist

CreateOS Sandbox ships an official Jenkins plugin that gives every build a fresh Firecracker microVM with its own guest kernel, then destroys it when the build ends. The network allowlist is enforced in the host kernel with eBPF, outside the guest, so it holds even if the build is compromised. Rules are set through the CreateOS API or CLI.

Introduction

A Jenkins agent executes whatever the pipeline hands it: dependencies pulled from public registries, steps contributed by plugins, scripts committed by someone who left last quarter. It runs all of that on a machine that usually shares a kernel with other work and holds a wide route into your network.

The exposure is not the build result. It is the machine. A compromised agent reads the credentials in its environment, reaches internal services, and moves laterally while the build log stays green. Two controls close this, and they only work as a pair: a machine per build that starts clean and dies clean, and a network policy enforced outside that machine, where compromised code cannot reach it.

Key Takeaways

Every build runs on a fresh Firecracker microVM with its own guest kernel, destroyed when the build finishes. No state bleeds from one build into the next.
The egress allowlist is enforced in the host kernel with eBPF, outside the VM. A full guest compromise does not lift it.
Outbound access is open until you set at least one rule. Once set, everything else is denied. Inbound is closed by default either way.
The plugin's Sandbox Template has no egress field. Rules are set on the sandbox itself, through the CreateOS API or CLI.
Builds resume from snapshot instead of a cold boot: same-host resume under 0.7 s, cross-host cold starts 11 to 13 s.

Why This Solution Fits

Build agents hold the most trusted credentials in your delivery pipeline and run the least trusted code. The common answer is a container: same host kernel, and egress rules that live inside the guest, where root can rewrite them. That narrows the blast radius at the process level and stops there.

A machine boundary per build fits the threat better. CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container. The plugin hands each build a fresh one and destroys it when the build ends, so a poisoned build takes nothing with it. We compared the container-per-build pattern and the microVM boundary in detail in Firecracker microVM Jenkins; this post concentrates on the network half.

The network half matters just as much as the kernel. The allowlist is enforced in the host kernel, outside the VM. A build that gets fully compromised still cannot route around it. That is the difference between a policy and a suggestion.

The workflow does not change. Declarative Pipeline is supported. Agents connect over Inbound WebSocket or SSH over the CreateOS tunnel. The one requirement is that the agent rootfs includes a JVM.

Key Capabilities

Each build gets a microVM with a per-VM kernel. Isolation is the default, not a setting someone has to remember to tick.

The allowlist rules take a host, a host and port, wildcard subdomains, IPs, or CIDR ranges. Enforcement sits in the host kernel with eBPF, outside the guest. Rules apply live through the API, with no restart needed.

One default to get right: outbound access is open until you set at least one rule. Deny-by-default starts when the first rule exists. Inbound is closed regardless.

For Jenkins, the allowlist is never configured in the plugin. The Sandbox Template has no egress field. You set rules on the sandbox through the CreateOS API or CLI, for example createos sandbox firewall set <sandbox> <host>.

Builds that need to talk to each other can share a private overlay network with per-network private DNS and no public exposure. Traffic between networks is denied by default.

Shapes run from a quarter CPU up to 8 CPU with 16 GB of memory, and disk from 10 to 60 GB. Egress is $0 and billing is per second, which suits agents that live exactly as long as the build.

Proof & Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. It shipped in September 2026.

The platform underneath has numbers. 2.6 million sandboxes created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. Uptime is 99% or better. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

This is a young product and it is plain about that. What is proven: the isolation model, the host-side egress enforcement, and a CI that runs on it every day. The plugin is new. Treat your first week on it as the evaluation.

Buyer Considerations

The agent rootfs must include a JVM. If your agent images are slim, add Java.
The allowlist lives outside Jenkins. If egress policy is a Jenkins-side setting for you today, it moves to the CreateOS API or CLI. Decide who owns it.
Egress is open until a rule is set. Treat the allowlist as part of rollout, not a cleanup task for later.
Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs certifications this quarter, raise it early.
Check your builds against the shapes: a quarter CPU up to 8 CPU with 16 GB, disk 10 to 60 GB.

Frequently asked questions

Does the CreateOS Sandbox plugin work with Declarative Pipeline?

Yes. Declarative Pipeline is supported. Agents launch over Inbound WebSocket or SSH over the CreateOS tunnel, and the agent rootfs must include a JVM. The plugin is listed on the Jenkins plugin index.

Can I set the network allowlist in the plugin configuration?

No. The plugin's Sandbox Template has no egress field. Rules are set on the sandbox itself, through the CreateOS API or CLI, and enforcement sits in the host kernel with eBPF, outside the guest. The plugin page lists what the plugin itself manages.

Is outbound traffic blocked by default?

No. Outbound access is open until you set at least one rule. Once a rule exists, everything else is denied. Inbound is closed by default regardless of the egress state.

What does each build actually run on?

A Firecracker microVM with its own guest kernel, not a container. The plugin gives each build a fresh one and destroys it when the build finishes. The source is public under the Jenkins organisation.

Conclusion

Pick the pipeline that touches the least trusted code. Install the plugin, pick a shape that fits the build, and set the allowlist through the API or CLI. Run it for a week. Per-second billing and $0 egress mean the trial costs minutes of compute. The build results will look the same. The blast radius will not.

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.