How to Pause and Resume a Long-Running Jenkins Agent Job Without Losing State

Yes. The CreateOS Sandbox plugin for Jenkins runs each build's agent on a Firecracker microVM, and the Sandbox layer underneath supports pause and resume from a full memory plus disk snapshot. A pause takes about 1.4 seconds. A same-host resume brings the agent back in under 0.7 seconds with its state intact.

Introduction

Some jobs cannot be squeezed into a working day. A regression suite that runs for hours. A training run you cannot interrupt without losing where it was. A migration that has to sit idle overnight while another system catches up, then finish in the morning. The job has to stop. The question is what happens to its state while it stops.

An idle agent is still a running machine doing nothing. A stopped container is a dead process, and the memory inside it is gone. A paused microVM is the third option: memory plus disk written to a snapshot, loaded back on resume. That is the option this post is about.

Key Takeaways

The official CreateOS Sandbox plugin gives each Jenkins build a fresh Firecracker microVM agent, destroyed when the build finishes.
Pause and resume are Sandbox platform capabilities. The snapshot covers full guest state, memory plus disk, so processes and files come back as they were.
Pause takes about 1.4 seconds. Same-host resume is under 0.7 seconds. Cross-host resume is a cold start at 11 to 13 seconds.
A paused sandbox auto-resumes on an inbound HTTP request. That is the only automatic resume path.
Pausing stops compute billing. Billing is per second, and egress is $0.

Why a MicroVM Agent Fits the Job

The state you are worried about lives in two places: the memory of running processes, and the files on disk. Stop a container and the first is gone. Shut a machine down without a snapshot and both are gone.

CreateOS Sandbox is a Firecracker microVM with its own guest kernel. It is not a container. Pause writes a snapshot of full guest state. Resume restores that exact machine: the agent's processes, environment, and working files come back as they were left.

The plugin's role is narrower, and the split is worth being precise about. The plugin hands each build a fresh microVM agent over Inbound WebSocket or SSH over the CreateOS tunnel, and destroys that agent when the build finishes. Pause and resume live in the Sandbox platform underneath, reached through the Sandbox API. If your pipeline needs a checkpoint that survives teardown, that is a Sandbox API pattern, not a plugin checkbox. We walk through the split in more detail in our FAQ on pausing a Jenkins build agent.

One tradeoff to plan around: resume speed depends on where the sandbox comes back. Same host, under 0.7 seconds. A different host means a cold start from snapshot, 11 to 13 seconds. For a pause that lasts minutes, that cold start is a real cost. For an overnight pause, it is noise.

Key Capabilities

Full guest state, memory plus disk. Processes return with their state. The filesystem returns exactly as it was left.
The timings above: pause about 1.4 seconds, same-host resume under 0.7 seconds, cross-host cold start 11 to 13 seconds.
Auto-resume on inbound HTTP, and only that. When the thing your job waits on comes back, one HTTP request to the sandbox resumes it. Nothing else resumes it for you.
Room to size the agent for the job: from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk.
Fork, if you need it, is a separate primitive that branches a paused sandbox's memory and working state into parallel copies. It answers a different question than pause.

Proof & Evidence

The plugin itself is verifiable. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. Declarative Pipeline is supported, and the launch mechanics are documented.

The layer underneath has a track record you can check. CreateOS has run its own CI on sandboxes since July 2026. 2.6 million sandboxes have been created since June 2026. Uptime is 99%+. Traces and usage dashboards are live, so you can see what a long-running agent did while it ran.

The young part deserves plain language too. The plugin is new; it shipped at the end of September 2026. The Sandbox surface has no compliance certifications yet; those are on the roadmap. If a certification is a hard gate for your team, settle it before you put a critical pipeline on this.

What to Check Before You Install

The agent rootfs must include a JVM. Build your rootfs image with that in before the first run.
Each build gets a fresh microVM, and the agent is destroyed when the build finishes. Pause and resume fit inside a build's lifetime, or in sandbox sessions you drive through the API. State that must outlive the build belongs in your artifact store or your own bucket; Sandbox supports bring-your-own S3, R2, or MinIO.
Egress is never a plugin setting. The plugin's Sandbox Template has no egress field. Outbound access is open until you set at least one rule; once set, everything else is denied, enforced in the host kernel with eBPF. Rules are set through the CreateOS API or CLI, not in Jenkins. The docs cover the mechanics.
No GPU sandboxes today. If your long-running job needs a GPU, this is not the runtime for it yet.
For install mechanics and the kernel-boundary rationale, see why Jenkins build agents need a real kernel boundary.

Frequently Asked Questions

Can I pause a build from inside Jenkins?

Pause and resume are Sandbox platform capabilities, not a plugin checkbox. The plugin handles the agent lifecycle: a fresh microVM per build, launched over Inbound WebSocket or SSH, destroyed when the build finishes. The sandbox underneath pauses to a full memory plus disk snapshot and auto-resumes when an inbound HTTP request arrives.

What exactly comes back after a resume?

The snapshot covers full guest state, memory plus disk. Processes return with their state, and the filesystem returns as it was left. Same-host resume takes under 0.7 seconds. A cross-host resume is a cold start from the snapshot at 11 to 13 seconds.

Does the plugin support Declarative Pipeline?

Yes. The plugin supports Declarative Pipeline, launches agents over Inbound WebSocket or SSH over the CreateOS tunnel, and requires a JVM in the agent rootfs.

What does it cost while a job sits paused?

Billing is per second, and a paused sandbox stops compute billing, so an overnight hold does not accrue compute charges. Egress is $0, and new accounts start with 500 free credits. Current shapes and rates are on the Sandbox pricing page.

Conclusion

The direct answer, once more. Yes, there is a Jenkins plugin, and the no-state-loss part comes from the layer it runs on. The CreateOS Sandbox plugin puts each build's agent on a Firecracker microVM. Pause writes full guest state to a snapshot in about 1.4 seconds. Resume on the same host returns in under 0.7 seconds, and a paused sandbox stops compute billing while it waits. The constraints are stated: cross-host resume is a cold start at 11 to 13 seconds, the plugin is new, and there are no GPU sandboxes yet. Prove it on a job you can afford to rerun, then put it under the jobs you cannot.

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.