> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opencomputer.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Migrating from v1
> Every breaking change between v1 and v2, and how to find out whether you are affected
v2 is the same API with the same SDK calls. Most code runs unchanged. What follows is the
complete list of behaviour that differs, ordered by how likely it is to matter.
Nothing changes for you until your org is moved to v2. The v1 documentation stays accurate
until then and is archived permanently at [docs-v1.opencomputer.dev](https://docs-v1.opencomputer.dev).
## Am I affected?
Seven questions. If every answer is "no", your migration is a configuration change.
v2 sandboxes have a hard 8-hour lifetime, counting hibernated time. See
[Sandbox lifetime](/sandboxes/lifetime).
v2 checkpoints capture the filesystem only. Restoring gives a fresh boot with your files,
not a resumed process tree. See [Checkpoints](/sandboxes/checkpoints).
A template that carries a rootfs image is refused. Most v1 templates do. See
[Templates](/sandboxes/templates).
The 16 GB tier does not exist in v2, and memory cannot change after launch.
Disk is fixed at \~16 GB in v2, down from 20 GB, and `diskMB` is ignored.
None of these exist in v2.
Image builds are unavailable. Fork is unavailable today and being worked on.
## Finding the calls in your code
```bash theme={null}
# Hard failures in v2
rg -n "\.scale\(|setAutoscale|\.mounts\b|createFromCheckpoint|buildImage|image:"
# Behaviour changes — review these
rg -n "createCheckpoint|restoreCheckpoint|\.hibernate\(|setTimeout|cpuCount|diskMB"
```
## The breaking changes
### Sandboxes end after 8 hours
A v2 sandbox is destroyed 8 hours after its host started, counting running **and** hibernated
time. It cannot be extended, and the disk goes with it.
Read `endAt` on the sandbox rather than computing a deadline — sandboxes come from a warm pool,
so the host often started before your create did:
```typescript theme={null}
const info = await getSandbox(sandbox.sandboxId);
const msLeft = Date.parse(info.endAt) - Date.now();
```
Work that assumed a long-lived sandbox needs to checkpoint and roll over, or keep its state
outside the sandbox.
### 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 | v1 | v2 |
| ------ | -- | ----------------- |
| 1 GB | ✓ | ✓ |
| 2 GB | — | ✓ |
| 4 GB | ✓ | ✓ default |
| 8 GB | ✓ | ✓ |
| 16 GB | ✓ | **not available** |
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:
```json theme={null}
{ "applied": false, "requested": 86400, "timeout": 0 }
```
Check `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](/sandboxes/secrets).
### Not available in v2
| | |
| --------------------------- | -------------------------------- |
| `scale()`, `setAutoscale()` | memory is fixed at launch |
| Mounts (FUSE, NFS, overlay) | the guest cannot perform `mount` |
| Image builds (`image:`) | no build pipeline in v2 |
| Fork from a checkpoint | in progress |
| Checkpoint patches | not wired up |
| Live migration | not applicable |
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 `running` is 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.