Checkpoints

Creating a Checkpoint

Capture the current state of a running sandbox:

oc checkpoint create sb-abc123 --name before-migration
# or using the shortcut:
oc cp create sb-abc123 --name before-migration

The checkpoint saves the filesystem and installed state. Status starts as processing and transitions to ready.

oc cp list sb-abc123
# ID          NAME               STATUS  SIZE     CREATED
# cp-7f3a1b2c before-migration   ready   128 MB   2025-01-15T10:30:00Z

Forking from a Checkpoint

Create new sandboxes from a saved checkpoint. Each fork is independent:

# Spawn two independent sandboxes from the same checkpoint
ID1=$(oc cp spawn cp-7f3a1b2c --json | jq -r '.sandboxID')
ID2=$(oc cp spawn cp-7f3a1b2c --json | jq -r '.sandboxID')

# Run different experiments
oc exec $ID1 --wait -- ./experiment-a.sh
oc exec $ID2 --wait -- ./experiment-b.sh

Forked sandboxes start with a fresh boot from the saved disk state — don’t assume running processes carry over.

Checkpoint vs Hibernate

	Checkpoint	Hibernate
Original sandbox	Keeps running	Stopped
Can fork	Yes — unlimited new sandboxes	No
Use case	Branching, parallel testing	Pause and resume, cost savings

Use checkpoints when you need to explore multiple paths from the same state. Use hibernation when you just want to pause and resume later.

SDK usage: Checkpoints. Full flags: CLI Reference.

Getting Started

Sandboxes

Reserved Capacity

Agent SDK

Hosted Agents

CLI

Guides

TypeScript SDK

Python SDK

CLI Reference

API Reference

Resources

Creating a Checkpoint

Forking from a Checkpoint

Restoring

Listing and Deleting

Checkpoint vs Hibernate

​Creating a Checkpoint

​Forking from a Checkpoint

​Restoring

​Listing and Deleting

​Checkpoint vs Hibernate

Creating a Checkpoint

Forking from a Checkpoint

Restoring

Listing and Deleting

Checkpoint vs Hibernate