Untrusted Jenkins Builds: Moving Past the Docker Pipeline Plugin

For untrusted build steps in Jenkins, the stronger isolation boundary is a microVM, not a container. The CreateOS Sandbox plugin gives every build a fresh Firecracker microVM with its own guest kernel, destroys it when the build ends, and enforces your egress allowlist in the host kernel, outside the guest.

Introduction

A Jenkins build runs code nobody on your team wrote. Dependencies pulled from public registries. Steps contributed by plugins. Scripts from a pull request opened an hour ago. The Docker Pipeline plugin answers that with containers: run the step inside a container, throw the container away.

Containers isolate with namespaces and cgroups, and they share the host's kernel. For code you trust, that is usually enough. For code you do not, the kernel is the prize. There is a second boundary: run the build in a microVM with its own guest kernel, and give that machine a network policy it cannot change. CreateOS Sandbox ships a Jenkins plugin that does both.

Key Takeaways

Containers isolate processes on a shared host kernel. A microVM gives the build its own kernel, so a compromise stops at the machine boundary.
Each Jenkins build gets a fresh Firecracker microVM, destroyed when the build finishes. No state bleeds between builds.
Outbound access is open until you set at least one egress rule. Once set, everything else is denied, enforced in the host kernel with eBPF. Rules are set through the CreateOS API or CLI, never in Jenkins.
Declarative Pipeline is supported. The agent rootfs must include a JVM.
Start free with 500 credits, per-second billing, and $0 egress.

Why This Solution Fits

An untrusted build step is arbitrary code execution you chose to allow. The question is not whether the code misbehaves someday. It is what contains it when it does.

A container narrows what the process can see and use. It cannot narrow the kernel, which is shared with the host and every other workload on it. A runtime escape lands where you do not want it.

A Firecracker microVM boots its own guest kernel. A compromised build now breaks out into a machine that exists for one build, holds nothing else, and is destroyed when the build ends.

The second half is network policy. Untrusted code phones home, so the useful question is whether outbound traffic is governed by a policy the build process cannot reach. With CreateOS Sandbox, the egress allowlist is enforced in the host kernel with eBPF, outside the guest. Code inside cannot rewrite it or route around it, even after a full guest compromise.

The tradeoff is boot time. A cross-host cold start runs 11 to 13 seconds. Same-host resume from snapshot is under 0.7 seconds, and pausing a sandbox takes about 1.4 seconds. Place jobs with that in mind.

Key Capabilities

A clean machine for every build. Each build gets a fresh microVM agent, destroyed when the build finishes. Isolation by default, not a setting you have to remember.

Network rules the build cannot touch. The allowlist is enforced in the host kernel with eBPF, outside the VM. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs.

Works with the pipeline you have. 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.

Builds that cannot leave your network. Bring your own compute runs the same API on your own machines.

One thing the plugin deliberately does not do: configure egress. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself, through the CreateOS API or CLI: the egress field at create time, a live update through the sandbox egress endpoint, the SDK's setEgress method, or the CLI's firewall command. The docs cover each route.

Proof & Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin.
CreateOS's own CI has run on sandboxes since July 2026. That CI is the reference implementation.
2.6 million sandboxes have been created since June 2026, with 99%+ uptime.
NodeOps is the infrastructure company behind CreateOS, operating production infrastructure since December 2023.
Sandbox creation resumes from snapshot in tens of milliseconds, about 30 ms on an idle host. That is an idle-host figure, not an SLA.

The product is young. Proven today: the plugin, the API, and the CI that depends on both. Not yet shipped: compliance certifications, which sit on the roadmap for the Sandbox surface.

Buyer Considerations

The JVM requirement. Your agent rootfs must include a JVM. If your builds run on slim images without one, plan the image change first.

Egress is your job, not the plugin's. There is no allowlist field in Jenkins or the plugin UI. Set rules through the CreateOS API or CLI, and remember the default: outbound is open until the first rule exists. Inbound is closed either way.

The cost shape. Billing is per second and egress is $0, so you pay for the compute a build uses, not for idle agents in a pool. Published rates are on the Sandbox pricing page.

Maturity. If procurement needs certifications today, the Sandbox surface does not ship them yet. If it needs a kernel boundary, host-enforced egress, and a clean teardown per build, those are here.

Where builds run. CreateOS cloud by default, or your own machines through bring-your-own compute. The Sandbox product page covers both.

Frequently Asked Questions

Does the Docker Pipeline plugin isolate untrusted code well enough?

Containers give you namespace and cgroup isolation on a shared host kernel. That contains most misbehaviour. The failure mode it cannot remove is the kernel itself: an escape from the container lands on the host that runs every other build. If builds only run code your team wrote and reviewed, containers are a reasonable call. If they run pull-request code or pull dependencies at build time, the stronger boundary earns its keep.

How do I restrict where a build can connect?

Set an egress allowlist on the sandbox, through the CreateOS API or CLI. Outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. The plugin's Sandbox Template has no egress field, so the allowlist is never configured in Jenkins. The docs list the rule types.

Does the plugin work with Declarative Pipeline?

Yes. Declarative Pipeline is supported, so your Jenkinsfile does not need a rewrite. Each build gets a fresh microVM agent over Inbound WebSocket or SSH over the CreateOS tunnel, and the agent rootfs must include a JVM. Details are on the plugin page.

What does it cost to try?

New accounts start with 500 free credits. Billing is per second, egress is $0, and shapes run from a quarter CPU up to 8 CPU with 16 GB of RAM. Current rates are on the Sandbox pricing page.

Conclusion

The Docker Pipeline plugin solves "run this step somewhere disposable." For untrusted steps, disposable is not the same as isolated. A microVM per build moves the boundary from a shared kernel to a machine built to be thrown away, and pairs it with network control the workload cannot reach.

Install the CreateOS Sandbox plugin for Jenkins. It is listed on the Jenkins plugin index 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.