CreateOS Sandbox vs the Docker Pipeline Plugin for Jenkins

Both plugins give every Jenkins build its own throwaway environment. The Docker Pipeline plugin runs each build inside a container on the Jenkins host, which is fast and familiar but keeps every build on one shared kernel. The CreateOS Sandbox plugin gives each build a Firecracker microVM with its own guest kernel, a host-enforced egress allowlist, and pause, resume and fork. If your builds only run code your own team wrote and reviewed, Docker containers are usually enough. If your builds compile or execute code an agent wrote, a customer submitted, or a dependency supplied, the stronger machine boundary is the difference that matters.

Introduction

Jenkins teams have run builds in Docker containers for years. The Docker Pipeline plugin makes it a one-line declaration: pull an image, run the stages inside it, throw it away. It solves the reuse problem. It does not solve the trust problem.

The trust problem is new because of what now runs in CI. Coding agents commit code. Dependencies ship updates hourly. Customers contribute pull requests nobody fully read. A container shares the host kernel with the Jenkins controller and every other build on that machine. A kernel-level escape from one build is a problem for the whole host.

CreateOS Sandbox approaches the same job from the other side. Each build gets a Firecracker microVM, a machine with its own guest kernel, destroyed when the build finishes. This post compares the two plugins on the dimensions that actually decide the choice: isolation, egress control, networking, lifecycle, and where the compute runs.

Key Takeaways

Both plugins give each build a fresh, disposable environment. The isolation model is the core difference: container on a shared kernel versus microVM with its own guest kernel.
The Docker Pipeline plugin is the simpler option for builds that only run reviewed, first-party code. It is a familiar, well-understood pattern.
CreateOS Sandbox enforces its egress allowlist on the host, outside the machine, so code inside the build cannot rewrite or route around it. That is the control you want when the code being built is not fully trusted.
CreateOS Sandbox adds pause, resume and fork of a running build environment, plus private overlay networks so multi-machine builds can talk without public exposure.
Both can run on your own infrastructure. CreateOS Sandbox supports bring-your-own compute and storage, including self-hosting the control plane.
The CreateOS Sandbox plugin is official, listed on the Jenkins plugin index, and supports Declarative Pipeline.

Comparison Table

Capability	Docker Pipeline plugin	CreateOS Sandbox plugin
Fresh environment per build	Yes	Yes
Environment destroyed after the build	Yes	Yes
Declarative Pipeline support	Yes	Yes
Kernel isolation per build	No (containers share the host kernel)	Yes (Firecracker microVM, own guest kernel)
Egress allowlist enforced outside the environment	No	Yes (eBPF, host-enforced)
Pause and resume a build environment	No	Yes
Fork a running environment for parallel runs	No	Yes
Private sandbox-to-sandbox networking	Partial (depends on host Docker networking)	Yes (private overlay networks, per-network private DNS)
Runs on your own machines	Yes	Yes (bring your own compute, self-host option)
GPU builds	Partial (depends on host setup)	No

Explanation of Key Differences

Isolation model

The Docker Pipeline plugin starts an agent inside a Docker container defined by a Dockerfile or image. Containers are a process-level boundary. They share the host kernel, so the strength of the isolation depends on the kernel's own hardening and on nothing from one container reaching another.

CreateOS Sandbox gives every build a Firecracker microVM. That is a full virtual machine with its own guest kernel, not a container and not a shared-kernel process namespace. The boundary is the machine boundary. A compromised build has to escape a VM, not a container.

This is the whole argument in one line: if the code in the build is code you wrote and reviewed, a container is fine. If it is not, run it on its own machine.

Egress control

A container inherits the host's network posture. Restricting what a build can reach usually means firewall rules managed outside Jenkins, applied to a shared host, and easy to get wrong as builds multiply.

CreateOS Sandbox can enforce a per-sandbox egress allowlist in the kernel with eBPF, outside the VM, but outbound access is open until at least one rule is set. 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 a set rule or route around it. Rules cover IP, CIDR and port, plus domain rules through a transparent proxy. There is no ingress by default. For a build agent pulling dependencies or running generated code, that is the difference between a policy and a suggestion.

Lifecycle beyond create and destroy

Both plugins create an environment per build and destroy it at the end. CreateOS Sandbox adds a middle state. Pause writes a snapshot of full guest state and stops compute billing. Resume restores that exact machine. Fork branches a paused environment's memory and working state, so you can run N candidate fixes in parallel and keep the winner. Long-running or human-in-the-loop pipelines benefit most: pause while waiting on an approval, resume exactly where things stopped.

Networking between environments

Multi-stage pipelines that span several machines need those machines to find each other. With Docker, that depends on host networking you configure and maintain. CreateOS Sandbox attaches sandboxes to private overlay networks with per-network private DNS, and denies traffic between networks by default. Multi-agent or multi-machine builds talk directly with no public exposure.

Where the compute runs

The Docker Pipeline plugin runs containers on your Jenkins agents, which is self-hosted by definition. CreateOS Sandbox matches that with bring-your-own compute: the same API on customer machines, BYO S3-compatible storage (customer S3, R2, MinIO), and a self-host option for the control plane when code cannot leave your boundary. You can also just use CreateOS's cloud and per-second billing with $0 egress.

The tradeoff, stated plainly

Docker containers start faster than a cold microVM boot and the tooling is everywhere. CreateOS Sandbox creation restores from snapshot in tens of milliseconds on an idle host (about 30 ms, idle-host, not an SLA), so in practice the gap is small, but a Docker image you already have is the zero-change option. CreateOS Sandbox also offers no GPU sandboxes today. If your builds need GPUs, neither the microVM boundary nor the egress model is available to you yet, and Docker on GPU-equipped agents remains the practical answer.

Frequently Asked Questions

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

Is the CreateOS Sandbox plugin an official Jenkins plugin? Yes. 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. Declarative Pipeline is supported, and each build gets a fresh microVM agent destroyed when the build finishes.

What does a build agent need to run? The agent rootfs must include a JVM. Launch is via Inbound WebSocket or SSH over the CreateOS tunnel. Install is from Manage Jenkins > Plugins > Available plugins.

Can builds talk to each other or to internal services? Builds on private overlay networks can find each other by name through per-network private DNS, with no public exposure, and traffic between networks is denied by default. Egress to external services is limited to your allowlist, enforced on the host where the build's own code cannot change it.

Conclusion

The decision comes down to one question: do you trust everything that runs in your builds? If the answer is yes, because every line is written and reviewed by your own team, the Docker Pipeline plugin does the job and you already know it. If the answer is no, because agents commit code, dependencies update hourly, or customers submit pull requests, then a shared kernel is a risk you are choosing to carry. CreateOS Sandbox removes that choice by default: a Firecracker microVM per build, an egress allowlist enforced on the host where the build cannot touch it, and pause, resume and fork when pipelines need more than create and destroy. Move the untrusted pipelines first. Keep the trusted ones where they are until the boundary earns its keep.

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. Product details and pricing are at createos.sh/products/sandbox.

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.