The CreateOS Sandbox Jenkins Plugin: A Fresh MicroVM for Every Build

The CreateOS Sandbox plugin for Jenkins gives every build its own Firecracker microVM, destroyed when the build ends. Untrusted code runs on a machine with its own guest kernel, outbound traffic follows an allowlist you set through the CreateOS API or CLI, and nothing lingers on a shared agent after the job finishes.

Introduction

A Jenkins controller holds secrets, deploy keys, and network reach into staging and production. Every agent that joins it inherits that reach. Then the builds run whatever the pipeline pulls in: dependencies, plugin updates, scripts from pull requests, code an agent wrote overnight.

A container narrows the blast radius at the process level. The kernel underneath is still shared. If the question is where code nobody reviewed should run, the answer is a machine that exists for exactly one build and is destroyed when it finishes. That is the machine this plugin creates.

Key Takeaways

Each build gets a fresh Firecracker microVM with its own guest kernel. The machine is destroyed when the build finishes.
The plugin is official. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation.
Inbound access is closed by default. Outbound access is open until you set at least one egress rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest.
The allowlist is set on the sandbox itself through the CreateOS API or CLI. The plugin has no egress field.
Billing is per second with $0 egress. New accounts start with 500 free credits.

Why This Solution Fits

If your builds only run code your team wrote and reviewed, keep your current setup. The microVM boundary earns its keep when builds execute things you cannot vouch for: a malicious postinstall script in a dependency, a prompt-injected commit from a coding agent, a pull request that is also an attack.

The plugin fits the lifecycle Jenkins already wants. An agent exists for one build, joins over Inbound WebSocket or SSH over the CreateOS tunnel, and disappears at the end. Declarative Pipeline is supported, so your Jenkinsfile does not need a rewrite. The agent rootfs needs a JVM, which is the one image requirement.

This is the piece most isolation setups miss: the boundary has to hold when the build itself turns hostile. The egress allowlist is enforced in the host kernel with eBPF, outside the VM. Code inside the build cannot rewrite it or route around it, even after a full guest compromise.

Key Capabilities

A disposable machine per build. A fresh Firecracker microVM with its own guest kernel, not a container on a shared kernel. Created for the build, destroyed after it.

Egress you set once, on the sandbox. The plugin's Sandbox Template has no egress field, so the allowlist is never a Jenkins setting. You set it on the sandbox through the CreateOS API or CLI: the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart needed), the SDK's setEgress method, or createos sandbox firewall set on the CLI. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs.

Pipeline compatibility. Declarative Pipeline works. Launch is Inbound WebSocket or SSH over the CreateOS tunnel.

A cost shape that matches usage. Billing is per second and egress is $0, so you pay for the compute a build uses. Shapes run from a quarter CPU up to 8 CPU with 16 GB of RAM, and disk runs 10 to 60 GB. Published rates are on the Sandbox pricing page.

An exit path for sensitive builds. Bring your own compute runs the same API on your own machines, for builds that cannot leave your infrastructure. The Sandbox product page covers the full surface.

Proof & Evidence

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

Underneath it, the sandbox layer has real mileage: 2.6 million sandboxes created since June 2026, CreateOS's own CI running on sandboxes since July 2026, and 99%+ uptime. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Say the young part plainly: the plugin is new, and compliance certifications are on the roadmap, not shipped, for the Sandbox surface. The trust argument is the architecture. A per-build kernel boundary, egress enforced outside the machine, and agents that stop existing when the build ends. For a step-by-step walkthrough, the guide on sandboxing untrusted code in Jenkins covers setup and the pitfalls teams hit.

Buyer Considerations

Set egress rules before the first untrusted build. Outbound access is open until you set at least one rule. Decide the allowlist, your artifact registry and package mirrors, and apply it through the API or CLI as part of rollout, not after.
The allowlist is not a Jenkins setting. The plugin's Sandbox Template has no egress field. Plan who owns the API or CLI side of it.
The rootfs needs a JVM. Bake one into the agent image.
No GPUs. Shapes top out at 8 CPU and 16 GB. GPU workloads stay elsewhere.
If everything in your builds is reviewed and trusted, you do not need this. The microVM boundary is for code you cannot vouch for.

Frequently Asked Questions

Is the CreateOS Sandbox plugin an official Jenkins plugin?

Yes. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install is from Manage Jenkins > Plugins > Available plugins, and Declarative Pipeline is supported.

Can I configure the egress allowlist inside the plugin?

No. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself through the CreateOS API or CLI, and it is enforced in the host kernel with eBPF, outside the VM. Outbound access is open until you set at least one rule. Once set, everything else is denied. Inbound is closed by default either way.

What does a build agent need to run?

An agent rootfs that includes a JVM. Launch is Inbound WebSocket or SSH over the CreateOS tunnel. Each build gets a fresh microVM agent, and the machine is destroyed when the build finishes.

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

Billing is per second and egress is $0, so 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 fresh microVM per build moves the boundary to the kernel, pairs it with egress control the build cannot touch, and throws the machine away when the job 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.