Choosing Isolation for Jenkins Builds: Containers, Ephemeral Agents, or a MicroVM per Step

Every Jenkins admin eventually faces the same decision: what actually runs the build? The default answer, a shared agent in a container, is cheap and familiar. It is also the answer that breaks first when a build pulls a dependency you did not write. This guide walks through the three practical options, the criteria that separate them, and when a Jenkins plugin that gives each build its own microVM with a network allowlist is the right call.

Introduction

Jenkins is the workhorse of CI. It is also, increasingly, a place where untrusted code runs. A malicious dependency in a package.json, a compromised plugin, a pull request that touches the build script itself: any of these turns a build agent into an attack surface. The question is not whether your builds execute code you did not fully review. The question is what that code can reach when it runs.

There are three common answers. Keep everything on shared agents and rely on Jenkins-level controls. Use ephemeral containers so each build gets a fresh filesystem. Or give each build its own microVM, with outbound network access governed by an allowlist enforced outside the build itself. Each option trades cost, speed, and containment differently, and the right choice depends on what your builds actually pull in and what your agents can reach.

Key Takeaways

Ephemeral containers solve stale-state problems, not trust problems. A container shares the host kernel, so a kernel-level escape reaches everything the host can reach.
A microVM per build gives the build its own guest kernel. The blast radius of a compromise shrinks to one build that is destroyed when it finishes.
Network egress is the control most teams skip. 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.
For Jenkins specifically, the allowlist is not a plugin setting. It is set on the sandbox itself through the CreateOS API or CLI.
The CreateOS Sandbox plugin for Jenkins gives each build a fresh Firecracker microVM agent, torn down when the build ends.

Decision criteria

Judge each option against five criteria.

1. Isolation boundary. A container isolates namespaces, not kernels. A microVM runs its own guest kernel, so a guest compromise does not touch the host kernel. If your builds run code you cannot trust, this is the criterion that matters most.

2. Egress control. Most build steps need outbound access: package registries, artifact stores, API endpoints. The question is whether that access is governed. An allowlist enforced in the host kernel survives a full guest compromise, because the guest cannot disable enforcement that lives outside it.

3. Freshness. Shared agents accumulate state: caches, credentials, leftovers from previous builds. Ephemeral agents fix this. Both containers and microVM-per-build approaches can be ephemeral.

4. Operational cost. MicroVMs boot in seconds from snapshot restore, but they are heavier than containers and need a host pool with capacity. Containers are cheaper per build. The tradeoff is containment per dollar.

5. Pipeline compatibility. Whatever you choose has to work with Declarative Pipeline and your existing agent provisioning. A security model that requires rewriting every Jenkinsfile will not survive contact with the team that owns them.

How to choose

If your builds only run first-party code and your agents have no network reach beyond your package mirror, shared agents with good Jenkins hygiene are defensible. The risk is concentrated in the trustworthiness of your own code and your plugin set. Keep the agents patched, restrict credentials, and revisit when a build starts pulling third-party artifacts.

If your builds pull third-party dependencies but you trust the host boundary, ephemeral containers are the pragmatic middle. Each build gets a clean filesystem, stale-state bugs disappear, and cost stays low. Accept the shared kernel. This is the right choice when the threat model is "bad dependency breaks my build," not "bad dependency owns my build host."

If your builds run code you cannot trust, or your build agents sit inside a network you cannot afford to expose, a microVM per build is the fit. This is the case for the CreateOS Sandbox plugin: each build gets a fresh Firecracker microVM agent with its own guest kernel, destroyed when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported. The agent rootfs must include a JVM.

If you choose the microVM route, set the egress allowlist deliberately. 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. Rules take host, host:port, wildcard subdomains, IPs and CIDRs. For Jenkins, the plugin's Sandbox Template has no egress field, so the allowlist is never configured inside Jenkins or the plugin UI. Set it on the sandbox itself through the CreateOS API (PUT /v1/sandboxes/{id}/egress, which applies live with no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. The CreateOS Sandbox docs cover the mechanics.

If your builds handle regulated data or must stay inside your own infrastructure, bring-your-own compute matters. The same API runs on your machines, so the isolation model does not force you onto someone else's network. Pricing is per-second with $0 egress, and shapes run from a quarter CPU up to 8 CPU / 16 GB. Shapes and rates are published on the Sandbox pricing page, and the limits guide walks through each cap.

Frequently Asked Questions

Does the CreateOS Jenkins plugin let me configure the network allowlist in Jenkins? No. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself through the CreateOS API, SDK, or CLI, and it is enforced in the host kernel outside the guest. See the plugin page for what the plugin does cover.

Is a microVM per build slower than a container? It is heavier, but not slow. Sandboxes create in seconds from snapshot restore, about 30 ms on an idle host (idle-host, not an SLA). The real cost is host capacity, not build latency.

What happens if code inside the build tries to reach a host that is not on the allowlist? Once at least one egress rule is set, everything not on the list is denied, and the enforcement lives in the host kernel with eBPF. A fully compromised guest cannot lift it, because the guest does not control the enforcement point.

How do I install the plugin? 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.

Conclusion

The decision comes down to one question: what can a build do when it goes wrong? Shared agents answer "everything the host can." Ephemeral containers answer "everything the host can, from a clean filesystem." A microVM per build answers "very little, and nothing outside its allowlist." If your builds run dependencies, plugins, or generated code you did not write, the third answer is the one that holds. Install the CreateOS Sandbox plugin for Jenkins from Manage Jenkins > Plugins, set your egress rules through the API or CLI, and let every build start on a machine that exists only for it.

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.