Skip to main content
@boxd/run re-exports the boxd TypeScript SDK as boxd, pre-authenticated as the account this machine belongs to. Import it and call it. Authentication is already handled.
Everything the SDK offers is there: machines, snapshots, checkpoints, disks, env vars and secrets, domains, organizations, API keys. This page covers what is specific to using it from an automation. The method reference is the SDK page.

What it can reach

The client is scoped like the machine it runs on: This is the same rule the in-machine boxd CLI follows, so a script can do exactly what a shell on that machine can do.

Fan work out to fresh machines

The reason to reach for the SDK from an automation is usually fan-out. Something happens, and you want one clean machine per unit of work rather than doing it all on the machine the script lives on.
machines.create({ fromSnapshot }) boots a copy of a snapshot with everything already installed and running. exec collects stdout, stderr, exitCode and success. An array command is shell-quoted for you, and a string is passed to a shell as is.

Fork the machine you are on

A fork copies a running machine, memory and disk included, in about 160 ms. From a script that means “take a copy of exactly this state and try something on it”:
A forked machine also inherits the automations of its source and starts them immediately, so forking is how an automation scales itself out. See Jobs.

Checkpoint before a risky step

Checkpoints are per-machine save points, up to ten per machine.

Keep a fleet alive on a schedule

Your laptop, through the same object

boxd.local is the laptop bridge: files under your home directory and your own Chrome, via the client utilities. It is covered in Scripts and Browsers.

Errors

SDK calls throw typed errors exactly as on the SDK page. A script that lets one escape a handler logs it and carries on. One that lets it escape the top level counts as a crash and enters the retry ladder.