Documentation/docs/volume/fork

#Volume Fork

Volume Fork creates a new Volume from an existing Volume using s0fs Copy-on-Write (COW) clone.

Why Use Fork?#

  • Fast Clone: Create a new Volume quickly without copying all data blocks
  • Storage Efficient: Source and fork share unchanged data blocks
  • Write Isolation: Writes to the fork do not affect the source Volume
  • Great for Branching: Create per-task or per-experiment data branches

How Fork Works#

API#

  • Endpoint: POST /api/v1/sandboxvolumes/{id}/fork
  • Path Parameter: id is the source Volume ID
  • Request Body: Optional, used to set the forked Volume access mode
  • Success Response: 201 Created, returns the new SandboxVolume including source_volume_id
  • Common Errors: 400 (invalid access_mode), 404 (source Volume not found or not visible to your team)

Optional Request Fields#

FieldTypeDescription
access_modeenumAccess mode for the forked Volume. If omitted, defaults to RWO

Fork a Volume#

go
forked, err := client.ForkVolume(ctx, volume.ID, &apispec.ForkVolumeRequest{ AccessMode: apispec.NewOptVolumeAccessMode(apispec.VolumeAccessModeRWO), }) if err != nil { panic(err) } fmt.Printf("Forked Volume: %s ", forked.ID) if sourceVolumeID, ok := forked.SourceVolumeID.Get(); ok { fmt.Printf("Source Volume: %s ", sourceVolumeID) } else { fmt.Println("Source Volume: <nil>") }

Verify Isolation#

  1. Mount both the source and the forked Volume to a Sandbox at different paths.
  2. Modify a file only in the forked Volume.
  3. Read the same file from the source Volume and verify it is unchanged.

Fork uses COW at the filesystem metadata layer, so unchanged data is shared while changed data is isolated.

Fork does not require the source Volume to be mounted.


Next Steps#

Overview

Connect Sandbox0 with external developer workflows.

GitHub CI

Build Sandbox0 templates from GitHub Actions and CI pipelines.