CLI Commands

Sandbox Commands

Lifecycle

heyvm create --name demo --image default   # create a sandbox (--name is required)
heyvm create --name demo --backend firecracker --image default
heyvm start <id>                        # start a stopped sandbox
heyvm stop <id>                         # stop it
heyvm restart <id>
heyvm get <id>                          # inspect one
heyvm rm <id>                           # delete (aliases: delete, destroy)
Command Purpose
create Create a sandbox (--name required; --image, --backend — alias --backend-type — …)
start / stop / restart Lifecycle control
get Inspect a single sandbox
rm Delete (aliases delete, destroy)
fork Fork a sandbox into a copy
list / list-inactive List sandboxes
prune Remove stopped sandboxes
checkpoint / snapshot Capture state
resize Change CPU / memory / disk
edit-ttl Change time-to-live
edit-start-command Change the persistent start command
update Replace a deployed sandbox's mount contents from an archive
wait-for Block until a sandbox reaches a state
backends List available backends on this host
wt Create a git-worktree sandbox and open a shell in it

Running code

heyvm exec <id> -- <command>     # run a command, capture output
heyvm sh <id>                    # interactive shell
heyvm run-host -- <command>      # run on the host
heyvm logs <id>                  # view logs

# Run an isolated code snippet (experimental, hyperlight-based — no sandbox id)
heyvm run --lang js --code 'console.log(1 + 1)'
heyvm run --lang python --file script.py
Command Purpose
exec Execute a command inside a sandbox
sh Open an interactive shell
run-host Run a command on the host machine
logs Show sandbox logs
run Execute an isolated JS/Python snippet with the experimental hyperlight runner (--lang, --code/--file) — not tied to a sandbox

Transferring VMs

heyvm transfer moves a VM to another machine over P2P: disks, config, and (where the backend supports it) the memory snapshot travel directly to the destination daemon, and the source sandbox is destroyed once the destination verifies the restore.

# Move a VM to one of your registered daemons (by name or id),
# or directly to a daemon's heyo:// connection ticket
heyvm transfer demo --to office-mac
heyvm transfer demo --to heyo://…

# Copy instead of move — the source keeps running
heyvm transfer demo --to office-mac --keep-source

# No cloud account? Serve the bundle and pull it from the other machine
heyvm transfer demo --serve          # prints a sync ticket
heyvm sync pull <ticket>             # run this on the destination

# Skip the memory snapshot — or insist on it
heyvm transfer demo --to office-mac --disk-only
heyvm transfer demo --to office-mac --require-memory

# Rename on arrival and leave it stopped
heyvm transfer demo --to office-mac --name demo-2 --no-start
Flag Purpose
--to <daemon> Destination: the name or id of a daemon registered to your account, or a daemon's heyo:// connection ticket
--serve No-cloud fallback: package the VM, serve it over P2P, and print a ticket for heyvm sync pull on the destination
--keep-source Keep the source sandbox running (copy instead of move)
--disk-only Transfer disk + config only; skip the memory snapshot
--require-memory Fail (and roll back the destination) if the memory snapshot can't be restored there, instead of degrading to disk-only
--name <name> Name for the sandbox on the destination (defaults to the source name)
--no-start Don't start the restored VM on the destination
--timeout-secs <n> How long to wait for the destination to pull + restore before resuming the source (default 1800)
-r, --relay <url> Relay URL for short-code ticket registration/resolution

Memory snapshots travel on the Firecracker backend; KVM and macOS (Apple Virtualization) transfers carry disk + config only. If the memory snapshot can't be restored on the destination, the transfer degrades to disk-only — pass --require-memory to make that a hard failure instead.