CreateOS Sandbox Jenkins plugin: ephemeral microVMs as build agents

Subtitle: Fresh Firecracker guest per build. Destroyed when the build finishes. Listed on the Jenkins plugin index.

CreateOS Sandbox is a Firecracker microVM execution environment for untrusted and agent-written code, with host-enforced egress control, pause/fork, and BYO options. The official Jenkins plugin, listed on the Jenkins plugin index and maintained under jenkinsci/createos-sandbox-plugin, uses that sandbox as a build agent: each build can get a fresh microVM, then the agent is destroyed when the build finishes.

That is the whole launch in one paragraph. The rest of this post is mechanism, install path, and what we are not claiming.

What shipped: the CreateOS Sandbox plugin for Jenkins

CreateOS Sandbox now has an official cloud plugin hosted under the Jenkins organization:

Plugin page: https://plugins.jenkins.io/createos-sandbox
Source and README: https://github.com/jenkinsci/createos-sandbox-plugin

What that means in practice:

Jenkins can provision an ephemeral CreateOS Sandbox microVM as a build agent.
Launch path is Inbound WebSocket, or SSH over a CreateOS tunnel.
When the build finishes, the plugin tears the agent down and deletes the sandbox.
Pipeline stays familiar: label-based agents, or Declarative agent { createos inheritFrom: ... }.

This is the same CreateOS Sandbox product you already evaluate for untrusted and agent-written code. Jenkins is a new entry surface into that sandbox, not a second product story.

How it works (mechanism)

CreateOS Sandbox is a Firecracker microVM execution environment for untrusted and agent-written code, with host-enforced egress control, pause/fork, and BYO options.

Mapped onto Jenkins:

A job requests a configured label (for example createos).
The CreateOS Sandbox cloud plugin calls the CreateOS API and creates a sandbox.
The plugin starts the Jenkins agent inside that microVM (WebSocket path) or starts sshd and connects through the CreateOS tunnel (SSH path).
The build runs with normal Jenkins Remoting semantics for Pipeline steps.
When the build finishes (success, failure, or abort), the agent is destroyed with its sandbox.

The isolation story is the proven four only:

Firecracker microVM with its own guest kernel
Host-enforced egress allowlist
Pause / fork
BYO options

We are not adding compliance badges, install ranks, or production Jenkins endorsements to this list. Mechanism first.

One hard requirement that trips people: the agent root filesystem must include a JVM. Stock images such as the default devbox rootfs will not start agent.jar. The repo ships Dockerfile.agent so you can build a JVM-bearing template and point the Sandbox Template's root filesystem at it. That is not optional polish. Without a JVM in the guest, the agent never comes online.

When to use WebSocket vs SSH

Templates default to Inbound WebSocket. Jenkins creates the sandbox, starts agent.jar through the CreateOS exec API, and the agent connects back to the controller over HTTPS/WebSocket.

Choose SSH over CreateOS tunnel when the controller must initiate the connection. Typical case: inbound agent connections are blocked, or WebSockets to the controller are not allowed. The launcher creates the sandbox, injects the SSH credential's public key, starts sshd, opens a local loopback proxy on the controller, and connects Jenkins' SSH launcher to sandbox port 22 through the CreateOS tunnel API.

Method	Use when	Direction
Inbound WebSocket	Sandbox can reach the Jenkins URL over HTTPS/WebSocket	Agent connects to controller
SSH over CreateOS tunnel	Controller must initiate; inbound agents blocked	Controller connects to sandbox via CreateOS tunnel

Both paths still carry Pipeline sh, logs, and workspace traffic over Jenkins Remoting. Pick the path that matches your network posture, not a preference for novelty.

WebSocket also needs a Jenkins URL the sandbox can actually reach. A controller localhost URL is the most common timeout cause, because the microVM cannot dial the controller's loopback.

First pipeline

Install from the Jenkins plugin index. First release 24.vfe318c36a_db_8, 30 September 2026. Install it from Manage Jenkins > Plugins > Available plugins, or with the plugin installation manager:

jenkins-plugin-cli --plugins createos-sandbox

The GitHub README carries the same steps plus the HPI release if you install by hand.

High-level path:

Create a CreateOS account and API key.
Install the plugin (above).
Add a Secret text credential with the API key.
Add a CreateOS Sandbox cloud and a Sandbox Template (label, shape, JVM-bearing rootfs, launch method).
Run a Pipeline that requests that label.

Minimal Declarative example:

pipeline {
    agent { label 'createos' }
    stages {
        stage('Build') {
            steps {
                echo 'Hello from CreateOS Sandbox'
                sh 'uname -a'
            }
        }
    }
}

For per-pipeline CreateOS settings, use Declarative agent { createos inheritFrom: 'createos', ... }. inheritFrom keeps privileged defaults (rootfs, launch mode, credentials) on administrator-defined templates. On controllers with untrusted Jenkinsfiles, disable pipeline-defined overrides on privileged templates.

Give the controller zero executors for this pattern. If the built-in node runs builds, work can land in the controller JVM where JENKINS_HOME and the API credential live. Name the CreateOS label explicitly instead of agent any.

FAQ

What is CreateOS Sandbox? CreateOS Sandbox is a Firecracker microVM execution environment for untrusted and agent-written code, with host-enforced egress control, pause/fork, and BYO options.

What is the CreateOS Sandbox Jenkins plugin? It is an official Jenkins cloud plugin hosted at jenkinsci/createos-sandbox-plugin. It provisions an ephemeral CreateOS Sandbox microVM as a Jenkins build agent and destroys that agent when the build finishes.

Does each Jenkins build get its own CreateOS Sandbox microVM? Yes, for the default template posture: each queued build gets its own one-executor sandbox (up to the container cap), and the agent is destroyed when that build finishes. Reuse between builds is off by default.

Does the CreateOS Jenkins agent use Firecracker? Yes. The workload runs in a CreateOS Sandbox Firecracker microVM with its own guest kernel, not as a bare process on the controller.

Does CreateOS Sandbox enforce egress at the host for Jenkins agents? Yes. Host-enforced egress control is part of the Sandbox execution environment. Outbound access is constrained by that host allowlist, not only by guest-side policy.

Should I use WebSocket or SSH with the CreateOS Sandbox Jenkins plugin? Use Inbound WebSocket when the sandbox can reach the Jenkins URL over HTTPS/WebSocket. Use SSH over CreateOS tunnel when the controller must initiate the connection because inbound agents are blocked.

What root filesystem do I need for a CreateOS Sandbox Jenkins agent? A JVM-bearing agent rootfs. Stock images without a JVM will not start agent.jar. Build from Dockerfile.agent in the plugin repo and point the template at that rootfs name.

How do I install the plugin? From the Jenkins plugin index: https://plugins.jenkins.io/createos-sandbox. Open Manage Jenkins > Plugins > Available plugins and search for CreateOS Sandbox, or run jenkins-plugin-cli --plugins createos-sandbox. The HPI is also on the GitHub releases page.

Can I run untrusted or agent-written code as a Jenkins build inside CreateOS Sandbox? That is the intended fit: ephemeral Firecracker guests for untrusted and agent-written CI steps, with host-enforced egress, then destroy-on-finish. Your Jenkinsfile still has to request the CreateOS label and use a JVM-capable rootfs.

What we are not claiming

Honesty is part of the launch.

We are not saying Jenkins project CI (ci.jenkins.io) runs on CreateOS in production.
We are not claiming Windows agents.
We are not attaching SOC2, ISO, HIPAA, install counts, or improvised pricing to this announcement.
We are not naming design-partner accounts in this post without consent.
We are not positioning this as Softbox, Studio, or any other product line. CreateOS Sandbox only.

If you need fleet economics, compliance packets, or a co-announce with Jenkins infra, that is a different conversation with different evidence. This post is the plugin, the mechanism, and the first green build path.