Dora NodaOn January 21, 2026, Kubernetes announced a new Checkpoint/Restore Working Group, chartered to turn container checkpointing into "a first-class pause/resume primitive." Read that headline fast and it sounds like the fix for the most annoying line item in any AI-agent platform's bill: paying to keep a mostly-idle coding-agent sandbox warm because tearing it down and cold-starting it back up is worse.
Read the working group's own scope document, and a different story shows up. Kubernetes can checkpoint a running container right now — that part shipped, is on by default, and has been stable since Kubernetes 1.30. What it still cannot do, natively, is restore one. Here's exactly where that line sits, why it matters more for GPU-backed agent sandboxes than for anything else on a cluster, and what the sandbox vendors who couldn't wait built instead.
The Capability Matrix
This is the part worth pinning to the top, because "checkpoint/restore is coming to Kubernetes" and "checkpoint/restore is in Kubernetes" describe two different products, and most coverage of the January announcement blurs them together.
| Capability | Status as of mid-2026 |
|---|---|
| Checkpoint a running container | Beta, on by default since Kubernetes 1.30. Exposed as a node-local kubelet HTTP API — you call it directly on a node, not through the cluster API server. |
| Restore a checkpointed container | Not implemented in kubelet. Today, restore happens outside Kubernetes entirely, at the container-engine level — CRI-O hands the checkpoint to runc, which invokes criu directly. |
| Convert a checkpoint into a runnable image | Possible via checkpointctl build, which produces an OCI image from a checkpoint archive. The image format is explicitly documented as pre-alpha and works only in combination with CRI-O. |
| Pod-level checkpoint (not just one container) | 2026 roadmap item. No committed GA version. |
| In-tree checkpoint/restore API (via the API server, not just kubelet) | 2026 roadmap item. A KEP is in progress; no committed GA version. |
| Checkpoint/restore for preemption and eviction (e.g., batch AI-training workloads) | 2026 roadmap item, named explicitly by the working group as a target use case. |
The gap in row two is the whole story. A kubelet can freeze a container's full process state — memory pages, open file descriptors, sockets — to a directory on disk. But getting that state back into a running pod is a manual, engine-specific operation today, not a Kubernetes primitive you call. If you want "pause an idle agent sandbox, resume it later" as an actual product feature backed by kubelet-native checkpoint/restore, you're building against a roadmap item with no ship date, not a shipped API.
The GPU Wrinkle
This matters more for AI-agent infrastructure than for almost any other Kubernetes workload, because CRIU — the userspace checkpoint/restore engine kubelet calls into — has no native concept of GPU state.
CRIU serializes CPU registers, memory pages, and file descriptors. It does not, on its own, know what to do with a CUDA context sitting in VRAM. Closing that gap requires two additional pieces: NVIDIA's own cuda-checkpoint utility, and CRIUgpu — a research project that integrates cuda-checkpoint with CRIU to transparently checkpoint GPU-resident process state. CRIUgpu was merged upstream into CRIU 4.0+ in 2025, which makes it available, but "recently merged" and "battle-tested in a multi-tenant fleet" are different claims. Treat it as early, not production-default.
The practical consequence: checkpoint an ordinary CPU-bound coding-agent sandbox today and CRIU handles it cleanly. Checkpoint a sandbox running local model inference or holding an active CUDA context, and you need the CRIUgpu path specifically — the generic kubelet checkpoint API alone will not capture what's in the GPU. Two more limits worth knowing before anyone assumes checkpoint/restore is a general-purpose primitive: CRIU cannot restore across CPU architectures (checkpoint on x86, restore on ARM doesn't work), and some open network connections need application-level reconnect logic on restore rather than transparently resuming mid-stream.
The Security Bill You Don't See Coming
A checkpoint is not a metadata snapshot. It's a copy of the container's actual memory pages — which means anything that was sitting in process memory at checkpoint time is sitting in that archive too: decrypted config values, session tokens, API keys a process pulled from an env var and held in a local variable.
checkpointctl, the tool the working group ships for inspecting checkpoints, includes a memparse command whose stated purpose is analyzing that memory data — including extracting secrets and configuration data back out of it. That's a deliberate forensic feature (the whole checkpoint mechanism started life as "forensic container checkpointing," aimed at security incident response), but it means the checkpoint archive itself is a secrets-bearing artifact, not an inert backup file.
Push that archive further — convert it to an OCI image with checkpointctl build and land it in a registry, which is the documented path to actually restoring a checkpoint as a new pod — and you've now put a plaintext-memory-dump image somewhere with registry-level access controls instead of node-local filesystem permissions. CRI-O's own documentation is candid about this: the security implications of running CRI-O with CRIU support enabled "are not yet clear," and the resulting image format should be used with care. That's not boilerplate hedging — it's the project telling you the threat model isn't finished.
What the Sandbox Vendors Actually Shipped Instead
None of the companies selling AI-agent sandboxes today waited for kubelet-native checkpoint/restore to ship, because it hasn't. They solved "stop billing for idle compute" at a different layer entirely:
| Vendor | How it actually pauses/resumes | Layer |
|---|---|---|
| E2B | Auto-pause (beta) preserves full memory state instead of shutting the sandbox down | Firecracker microVM snapshot |
| Daytona | Per-second billing; auto-stops after 15 minutes idle, auto-archives after 7 days stopped | Pre-warmed Docker snapshot |
| Modal | Sandboxes capped at a 24-hour lifetime; long-running state is preserved via filesystem snapshots and restored into a fresh sandbox | Filesystem snapshot, not process-state checkpoint |
The pattern across all three: pause/resume is a product feature they built themselves, at the microVM or filesystem layer, specifically because the kubelet checkpoint API doesn't yet do this for them. E2B's snapshot is a Firecracker VM image, not a CRIU checkpoint. Daytona's economics come from per-second billing plus aggressive idle timeouts, not from freezing process memory. Modal explicitly tells users to snapshot the filesystem and restore into a new sandbox rather than resume the same one — because in-place process restore isn't the primitive it's built on. Every "checkpoint" a working AI-sandbox product ships today sits above or beside Kubernetes' checkpoint/restore work, not on top of it.
What This Means for a Self-Hosted Fleet Today
For a Cluster-API-managed fleet running AI-agent sandboxes on owned hardware, the honest answer is: don't design the cost model around kubelet-native checkpoint/restore, because the piece that would make it a real product feature — native restore, a stable image format, pod-level scope — is a 2026 roadmap item with no committed ship date, not a dependency you can plan a billing model around this quarter.
What's usable now, with eyes open about the tradeoffs:
- Forensic-checkpoint-as-cold-pause, scoped narrowly. For a genuinely idle, CPU-only agent sandbox where a manual restore path (checkpoint →
checkpointctl build→ run as a new pod) is acceptable, the mechanism works today. Treat it as a cold-storage tier, not a warm-pause feature — there's no sub-second resume here, and none is promised. - Never a shared registry. Given that a checkpoint is a memory dump and the image format is pre-alpha and CRI-O-specific, checkpoint storage needs to be encrypted at rest and kept off any multi-tenant or externally reachable registry. Treat the artifact the same way you'd treat a database backup with secrets in it, because that's what it is.
- Skip it entirely for GPU-backed sandboxes. Until CRIUgpu has real production mileage, don't build a cost-savings story around checkpointing an inference or model-serving sandbox — the GPU context isn't reliably part of the checkpoint yet.
- For anything needing real pause/resume today, build at the layer the vendors already proved out. A snapshot at the microVM (Firecracker, Cloud Hypervisor) or filesystem layer, independent of kubelet checkpoint state, is the same bet E2B, Daytona, and Modal already made — and it's available now instead of on a roadmap.
The working group's own KubeCon EU 2026 talk title was "Ctrl-X, Ctrl-V Your Pods" — a fair pitch for where this is headed, but a fair reading of the current state is closer to "Ctrl-X works, Ctrl-V is still being written." Revisit the default node-pool story once pod-level checkpoint and an in-tree restore API actually ship with a version number attached — not before.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your agent sandboxes are burning budget on idle compute, check out the repo on GitHub and see what a Cluster-API-managed fleet on owned hardware actually costs to run one.
