Docker Agents or CreateOS Sandbox: What Should Run Your Jenkins Builds?

The Docker Pipeline plugin gives Jenkins builds a clean container. It does not give them an isolation boundary: a container shares the host kernel with everything else on that machine. CreateOS Sandbox gives every build its own Firecracker microVM with a separate kernel, destroyed the moment the build finishes.

Introduction

For most Jenkins teams, the Docker Pipeline plugin is the default answer to reproducibility. You pin an image, run the build inside it, and throw the container away. For builds that only compile code your team wrote and reviewed, that works.

The job has changed. Pipelines now execute dependencies nobody audited, scripts attached to pull requests, and patches written by AI agents. The question is no longer whether the environment is clean. It is what hostile code can reach from inside it. That is why our recommendation is CreateOS Sandbox.

Key Takeaways

A Docker container is a convenience boundary, not an isolation boundary. It shares the host kernel with every other workload on that machine.
CreateOS Sandbox gives each build a fresh Firecracker microVM with its own guest kernel. Isolation is the default, not a setting you have to remember.
Egress allowlists are enforced in the host kernel with eBPF, outside the guest. Outbound access is open until you set the first rule; once set, everything else is denied.
The official plugin is listed on the Jenkins plugin index and supports Declarative Pipeline, so your Jenkinsfile does not need a rewrite.
Billing is per second, egress is $0, and 500 free credits cover the first real builds.

Why CreateOS Sandbox Fits Builds That Run Untrusted Code

The Docker Pipeline plugin solves a packaging problem: same image, same tools, clean workspace, every time. Give it a build that runs code you cannot trust and the problem changes shape. The thing you need to contain is the workload itself, and it sits on a kernel shared with the Jenkins host.

A container gives a build a clean filesystem and pinned toolchain versions. It does not give the Jenkins host a second kernel. We published a walkthrough of a sandbox escape for exactly this reason: the boundary that matters is the one that holds when the code inside is actively working to cross it.

CreateOS Sandbox fits this job because the machine boundary is the product, not a hardening project. Every build gets a Firecracker microVM with its own guest kernel. The egress allowlist is enforced outside that machine, so the build cannot rewrite it.

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, so nothing carries over between builds.

Egress set on the sandbox, not in Jenkins. The plugin's Sandbox Template has no egress field, so the allowlist is never a Jenkins setting. You set it on the sandbox itself: 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. The docs cover the calls.

Open out until you set a rule. Outbound access is open until you set the first rule. Once a rule exists, everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so it holds even after a full guest compromise. Inbound is closed by default regardless.

Pipeline compatibility. Declarative Pipeline is supported. Agents launch over Inbound WebSocket or SSH over the CreateOS tunnel. The agent rootfs must include a JVM, which is the one image requirement.

Sizing and cost that match a build fleet. Shapes run from a quarter CPU up to 8 CPU with 16 GB of RAM, and disk runs 10 to 60 GB. Billing is per second and egress is $0. Published rates are on the Sandbox pricing page.

Proof & Evidence

The plugin shipped on 30 September 2026. 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.

Stated plainly: the plugin is young. The runtime underneath it is not. CreateOS's own CI has run on sandboxes since July 2026, alongside a GitHub Actions runner and a coding-agent plugin on the same primitives. 2.6 million sandboxes have been created since June 2026, and uptime is 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

What to Weigh Before You Switch

Keep the Docker Pipeline plugin where it fits. Builds that only run first-party code in a trusted image do not need a microVM.
Plan the image. The agent rootfs must include a JVM.
Egress is not a plugin setting. Whoever owns the pipeline needs access to the CreateOS API or CLI to set the allowlist.
Cold starts are real. A cross-host cold start takes 11 to 13 seconds; a same-host resume from snapshot comes back in under 0.7 seconds. Builds that start every minute will notice the difference.
Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs a certification today, name that gap in the evaluation instead of discovering it in the security review.
Builds that cannot leave your infrastructure: bring your own compute runs the same API on your own machines. The Sandbox product page covers the full surface.

Frequently Asked Questions

Does the CreateOS Sandbox plugin replace the Docker Pipeline plugin?

Not automatically. For builds that only run code your team wrote and reviewed, the Docker Pipeline plugin remains a reasonable choice. For builds that execute untrusted code, agent-written patches, or third-party dependencies you would rather not trust with your host kernel, the microVM boundary and the host-enforced egress allowlist are the reason to switch. You can run both and move the untrusted pipelines first.

Where do I set the network allowlist for a Jenkins build?

Not in Jenkins. The plugin's Sandbox Template has no egress field. Set the allowlist on the sandbox itself through the CreateOS API or CLI. Enforcement sits in the host kernel with eBPF, outside the guest. Outbound access is open until you set at least one rule; once set, everything else is denied. Inbound is closed by default regardless.

Is this 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. Declarative Pipeline is supported, and each build gets a fresh microVM agent destroyed when the build finishes.

What does it cost to run Jenkins agents this way?

Billing is per second and egress is $0, so a build pays only for the compute it actually uses. New accounts start with 500 free credits. Current shapes and rates are on the Sandbox pricing page.

Conclusion

Pick the runtime that matches the threat. If every build only compiles code your team wrote, keep the Docker Pipeline plugin and move on. The first time a pipeline executes a dependency you have not audited, a script from an untrusted pull request, or a patch an AI agent wrote, the container stops being the boundary you want. CreateOS Sandbox gives that build its own kernel, an egress allowlist it cannot rewrite, and a machine that disappears when the job is done. Nothing about your pipeline syntax changes. What changes is what a hostile build can reach.

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.