Kubernetes' Pod Checkpoint/Restore Is Headed for Alpha in v1.37 — What That Means for Preview Environments Right Now

Zeropod, a containerd shim built by a solo maintainer, has been checkpointing idle Kubernetes pods to disk and resuming them on the first incoming packet — in tens to a few hundred milliseconds — in production for over a year. Kubernetes itself, meanwhile, still can't do that. The control plane can create a checkpoint through a beta kubelet API. It has no supported way to restore one. That gap is what the newly formed Checkpoint/Restore Working Group exists to close, and the honest status update is: not yet, and not in the way the "instant-resume preview environment" pitch implies.

What the working group actually shipped, and what's still three PRs away​

The Checkpoint/Restore Working Group was announced January 21, 2026, led by Radostin Stoyanov, Viktória Spišaková, Adrian Reber, and Peter Hunt, meeting biweekly under SIG Node. Its scope reads like a wish list: resource optimization for interactive workloads (Jupyter notebooks, AI chatbots), faster startup for slow-initializing apps, periodic checkpointing for fault tolerance, checkpoint-aware preemption scheduling, cross-node pod migration, and forensic snapshotting for incident response. Pod migration and instant-resume for idle workloads — the preview-environment use case — is explicitly in scope.

What exists today, though, predates the WG and only does half the job:

That last row is the one worth being precise about. Kubernetes v1.37 is scheduled to ship August 26, 2026; as of two days before this post, it's at v1.37.0-alpha.3 — a pre-release, not GA — and the pod-level checkpoint/restore work is still landing across separate PRs targeting that window, not merged and gated behind a flag today. "Alpha in v1.37" is the plan, not a shipped feature. Even once it lands, alpha means off-by-default, no upgrade/downgrade guarantees, and explicitly not for production. There is currently no Kubernetes-native way to say "restore this pod" and have the control plane do it — full stop.

The number that actually matters: what checkpoint/restore buys over what you already have​

Namespace-per-PR preview environments are a solved cost problem already. Auto-sleep — scaling a preview's pods to zero after a period of inactivity — is standard practice on every preview-environment platform, and it routinely cuts idle spend by 60–70%. That's not the gap checkpoint/restore closes. The gap is what happens on the way back up.

A cold start from zero — a fresh Pod scheduled, image pulled or cached, container process launched, application init code running (dependency injection, DB connection pool warmup, JIT warmup, cache priming) — takes a few seconds. For a reviewer clicking a preview link, that's a small but real tax, and it resets every time: the process has no memory of the request it served five minutes before it scaled down.

Checkpoint/restore is not a faster cold start. It's the absence of a cold start. Zeropod — a containerd shim that pairs eBPF traffic monitoring with CRIU checkpointing — hibernates a pod after its last TCP connection goes idle, and restores the exact in-memory process state, live DB connections and all, on the first new packet: "tens to a few hundred milliseconds," scaling with how much memory the checkpointed process was holding.

A Node process with a small heap restores near the low end of that range; a JVM app with a warmed-up heap restores nearer the high end — still an order of magnitude under a cold start, but not a fixed number, and any post claiming otherwise is rounding off a real cost. A one-year production retrospective on Zeropod backs up that it holds up outside a demo.

Stack the two together and the honest framing is: scale-to-zero already gives you the cost cut, and checkpoint/restore is what would let a preview environment keep that cost cut without asking every reviewer to eat a multi-second reinit on the first click.

Zeropod proves the mechanism works. It doesn't prove Kubernetes supports it.​

This is the distinction the "still-alpha feature" framing in the WG's own scope glosses over. CRIU-based checkpoint/restore, as a mechanism, is not experimental — Zeropod has run it in production for over a year, on real traffic, orchestrated entirely outside the Kubernetes API by a custom containerd shim that intercepts container lifecycle calls before they reach the kubelet. The primitive works. What doesn't exist is a way to drive it through Kubernetes itself: no kubectl checkpoint and matching restore verb, no controller that watches for idle pods and requests a checkpoint, no scheduler awareness that a "pending" pod might actually be a warm checkpoint waiting to be resumed on the right node.

That's precisely the gap the pod-level KEP is scoped to close — and precisely why it's landing as three separate PRs instead of a single merged feature. A preview-environment platform that wants this today has two paths, not one: wait for the native primitive to clear alpha, beta, and GA (each a multi-release cycle in Kubernetes' cadence — container-level checkpoint took from v1.25 alpha to v1.30 beta, roughly a year and a half), or build the same kind of bypass Zeropod did, running the CRIU plumbing under a custom shim without depending on Kubernetes' own orchestration layer catching up.

The three gaps that block this regardless of which path a PaaS takes​

Even a platform willing to build the Zeropod-style bypass today runs into three problems that have nothing to do with how mature the Kubernetes API is.

Sandboxed runtimes don't support it. A multi-tenant preview-environment platform running untrusted PR code has good reasons to isolate it harder than a bare runc container — gVisor or Kata Containers, for stronger kernel-boundary isolation. Neither is checkpoint/restore-ready. gVisor's own runsc has checkpoint/restore commands, but that support isn't wired into containerd's CRI shim — the path Kubernetes actually uses — so a gVisor-sandboxed pod can't be checkpointed through the kubelet API at all today.

Kata Containers is further behind: its guest kernel isn't even compiled with CONFIG_CHECKPOINT_RESTORE, so the capability doesn't exist at the VM level to begin with. If your preview environments run untrusted code in anything other than a bare container, this feature isn't reachable yet regardless of Kubernetes' own timeline.

A checkpoint is a memory dump of everything that was in the process, including secrets. Kubernetes' own documentation is blunt about this: a checkpoint archive contains all memory pages of all processes in the container, which means any private key, session token, or database password that was live in memory at checkpoint time is now sitting in a .tar file on local disk, root-only but fully readable if that file is moved anywhere else.

Preview environments routinely inject real secrets — staging API keys, database credentials pulled from a vault — specifically so the PR's code path can be exercised end-to-end. Checkpointing that pod means writing those secrets to disk in plaintext, a materially different risk posture than a process that only ever held them in memory.

Checkpoint size isn't free. The archive scales with the checkpointed process's memory footprint — a Python API server with a 200MB heap produces a proportionally sized checkpoint, and a platform running hundreds of concurrently idle previews multiplies that by however many it's holding hibernated at once. It's cheaper than keeping the pod running, but it's not zero, and it needs the same eviction/retention story as any other on-disk artifact a preview environment produces.

Where that leaves a git-push PaaS today​

The version-number framing — "alpha feature, wait for GA" — undersells how far along this actually is and oversells how close it is to being usable. The CRIU mechanism itself is proven in production, just not through Kubernetes; the thing genuinely stuck at "alpha, three PRs in flight, targeting a release still six weeks out" is Kubernetes-native orchestration of that mechanism, not the mechanism. A platform that wants sub-second preview resume today doesn't need to wait on SIG Node's release cadence — it needs to solve sandboxed-runtime compatibility and plaintext-secret exposure, which the native KEP won't solve either once it ships, because those are deployment-model problems, not API-surface problems.

That's the more useful way to read "how far is this from production": not as a Kubernetes version number, but as an open checklist — runtime isolation, secret handling, storage retention — that exists independent of whether the restore verb lives in kubectl or a third-party shim.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Preview environments today run on the same scale-to-zero model as everyone else's; checkpoint/restore is on the radar precisely because we control the machines and the container runtime end to end, rather than waiting on a managed platform to decide it's worth shipping. Star the repo on GitHub or deploy your first app today.

Sources:

• Announcing the Checkpoint/Restore Working Group
• Pod-Level Checkpoint/Restore KEP tracking issue
• Kubelet Checkpoint API reference
• Forensic container checkpointing in Kubernetes (alpha announcement)
• Zeropod: pod that scales down to zero
• zeropod v0.12.0: One Year Later, Does Scale-to-Zero Deliver?
• containerd: Support container checkpoint/restore for gVisor runtime (open issue)
• Kata Containers: Thoughts on CONFIG_CHECKPOINT_RESTORE?