Am I affected?
Seven questions. If every answer is “no”, your migration is a configuration change.1
Does any sandbox need to live longer than 8 hours?
v2 sandboxes have a hard 8-hour lifetime, counting hibernated time. See
Sandbox lifetime.
2
Do you restore checkpoints expecting a running process?
v2 checkpoints capture the filesystem only. Restoring gives a fresh boot with your files,
not a resumed process tree. See Checkpoints.
3
Do you use templates built on v1?
A template that carries a rootfs image is refused. Most v1 templates do. See
Templates.
4
Do you run sandboxes larger than 8 GB?
The 16 GB tier does not exist in v2, and memory cannot change after launch.
5
Does any sandbox need more than ~16 GB of disk?
Disk is fixed at ~16 GB in v2, down from 20 GB, and
diskMB is ignored.6
Do you call scale, autoscale, or mount anything?
None of these exist in v2.
7
Do you build images or fork from checkpoints?
Image builds are unavailable. Fork is unavailable today and being worked on.
Finding the calls in your code
The breaking changes
Sandboxes end after 8 hours
ReadendAt on the sandbox rather than computing a deadline — sandboxes come from a warm pool,
so the host often started before your create did:
Checkpoints are filesystem-only
v1 captures disk and memory. v2 captures the filesystem. Restoring gives you a freshly booted sandbox with your files in place. If your checkpoints capture an installed environment, nothing changes. If they capture a warmed process — a loaded model, an open connection pool — that state is gone on restore.kind: "full" is refused rather than silently producing a disk-only checkpoint.
Templates built on v1 are refused
A v1 template captures the whole disk. v2 can only replay the workspace half, and doing that silently would hand you your files while dropping every system change the template existed for. So it refuses, loudly, at create. Rebuild affected templates as workspace templates or checkpoints on v2.Sizes are fixed steps, and 16 GB is gone
Memory cannot be changed after launch.
cpuCount and diskMB are accepted for compatibility
but are not controls in v2 — CPU follows memory, and disk is fixed at ~16 GB.
Hibernation suspends rather than parks
v1 hibernation writes a checkpoint and releases the host, so a sandbox can stay hibernated indefinitely. v2 suspends in place, and that time still counts against the 8-hour lifetime. A sandbox hibernated overnight will not be there in the morning.Idle timeouts are clamped
A timeout longer than the remaining lifetime cannot fire, so v2 reports what it applied instead of accepting it:applied.
Secrets: same model, one difference
Sealed placeholders, host-scoped substitution, fail-closed bypass and restart-free rotation all work exactly as in v1, and your code does not change. The difference is where the real values are held: in v2 the substituting proxy runs inside your sandbox as a root-owned process, rather than outside it. Your code runs unprivileged and cannot read them, but a privilege escalation inside a sandbox now reaches the secrets scoped to that sandbox. See Secrets.Not available in v2
Each of these is refused rather than silently ignored.
What improves
- Creates are served from a warm pool, so they start faster and more consistently.
- Deploys no longer disturb running sandboxes.
- An unavailable size is refused with the sizes that exist, instead of being reported as a capacity problem.
- A sandbox that reports
runningis running — rows can no longer outlive their host.
Testing before you move
Ask us to move a non-production org first. The same SDK and the same code run against both versions, so your existing test suite is the test.If something in your workload is blocked by the “in progress” items above, tell us. That list is
prioritised work, not a fixed decision.