Machine Capabilities

Every sandbox is a Linux VM with a curated set of tools available from the moment you SSH in. Nothing to install before you start working.

Machine types

Four sizes, all x86_64. Pick one with --type when you create the sandbox:

Size	Per hour	CPU	RAM	Disk
`small`	$0.018	2 vCPU	4 GB	12 GB
`default`	$0.036	4 vCPU	8 GB	50 GB
`large`	$0.072	8 vCPU	16 GB	125 GB
`xlarge` *	$0.200	16 vCPU	32 GB	251 GB

“Disk” is what your own files can grow to; the operating system and pre-installed tools sit outside it. Run df -h / inside a sandbox for the live figure. * xlarge needs the $100 plan or higher, with no request to us. See Pricing & Limits for plans, concurrency and start limits.

boat new
boat new --type small
boat new --type large

curl -sS -X POST "https://boat.dev/api/v1/sandboxes" \
  -H "Authorization: Bearer $BOAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"large","ttlSeconds":3600}'

const created = await sandbox.create({ type: "large", ttlSeconds: 3600 });

created = sandbox.create(CreateSandboxRequest(type="large", ttl_seconds=3600))

Stopping, resuming and forking all preserve the type by default, and a fork inherits the type of the sandbox it came from.

Changing size

Pass --type to resume or fork to move a sandbox to a different size. Both already restore a snapshot onto a fresh machine, so resizing costs nothing beyond the resume or fork itself. Resume changes the sandbox in place; fork leaves the source sandbox untouched and applies the new size to the copy.

boat resume bx_23456789 --type large
boat fork   bx_23456789 --type small

curl -X POST https://boat.dev/api/v1/sandboxes/bx_23456789/resume \
  -H "Authorization: Bearer $BOAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"large"}'

await sandbox.resume({ sandboxId: "bx_23456789", type: "large" });

sandbox.resume(sandbox_id="bx_23456789", resume_request=ResumeRequest(type="large"))

Growing always works. Shrinking is rejected with type_too_small when the sandbox holds more data than the smaller machine can take, and the sandbox is left exactly as it was, so a refused resize never costs you the sandbox. Delete data and let the sandbox snapshot again if you need to shrink past that point. A bigger size costs more per hour because it is more machine: the table above is the whole price.

Fail fast

Creating, deploying from a named snapshot, forking and resuming all land on a machine that is already running and waiting, so they get one in under a second. When a burst uses up the ready machines of one type, the next ones wait while fresh machines are built. If you would rather fall back to something else than wait, pass failFast to any of them. The call then answers within about 1.5 seconds with one of two results:

the usual 202, on a machine that was ready;
503 no_ready_machine. Nothing was started, nothing is billed, and the attempt does not count against your start limits: no sandbox or fork is created, and a resumed sandbox stays stopped. Retry or fall back right away.

boat new --fail-fast --type large
boat new --fail-fast --from ci-runner
boat fork --fail-fast bx_23456789
boat resume --fail-fast bx_23456789

curl -sS -X POST "https://boat.dev/api/v1/sandboxes" \
  -H "Authorization: Bearer $BOAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"failFast":true,"from":"ci-runner"}'
# same field on POST /sandboxes/{id}/fork and /sandboxes/{id}/resume

try {
  const created = await sandbox.create({ failFast: true, from: "ci-runner" });
  // also: sandbox.fork({ sandboxId, failFast: true }), sandbox.resume({ sandboxId, failFast: true })
} catch (error) {
  // 503 no_ready_machine: nothing was started; fall back or retry.
}

try:
    created = sandbox.create(CreateSandboxRequest(fail_fast=True, var_from="ci-runner"))
except ApiException as error:
    # 503 no_ready_machine: nothing was started; fall back or retry.
    pass

The machine


OS	Ubuntu 24.04 LTS, Linux 6.8, x86_64
Access	Full root through passwordless `sudo`, real `systemd` (services, timers, `journalctl`)
Containers	Docker with BuildKit, running on the sandbox’s own kernel
Network	Public IPv4 or IPv6 plus outbound internet; expose ports with Hosting
GPU	None. Graphics run on the CPU (the desktop and headless Chrome work)

Virtualization (KVM, Android emulator)

Sandboxes run on our standard machines: dedicated AMD Ryzen 9 9950X (Zen 5) hosts. Internally we call these “baremetal”, but your sandbox is still a full VM with its own kernel, not a bare-metal server. Their CPU virtualization extensions are passed through, so /dev/kvm exists and you can run VMs inside the sandbox: QEMU/KVM, Firecracker, or the Android emulator at full speed. When the standard machines are temporarily out of capacity, a new sandbox is placed on a Hetzner cloud VM with an older AMD CPU instead of waiting in a queue. That fallback costs the same, has no /dev/kvm, and is slower on CPU-heavy work (about 3x on our build benchmark). If you need KVM and /dev/kvm is missing, create a new sandbox a bit later. Check before you rely on it:

ls /dev/kvm && echo "KVM available"

Headless Android emulator, tested on a large sandbox (about a minute to install, then Android 14 boots in 20 to 30 seconds):

sudo apt-get install -y openjdk-17-jre-headless
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 ANDROID_HOME=$HOME/android
mkdir -p $ANDROID_HOME/cmdline-tools && cd /tmp
curl -fsSLo clt.zip https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip
unzip -q clt.zip -d $ANDROID_HOME/cmdline-tools && mv $ANDROID_HOME/cmdline-tools/cmdline-tools $ANDROID_HOME/cmdline-tools/latest
SDK=$ANDROID_HOME/cmdline-tools/latest/bin
yes | $SDK/sdkmanager --licenses >/dev/null
$SDK/sdkmanager "platform-tools" "emulator" "system-images;android-34;google_apis;x86_64"
echo no | $SDK/avdmanager create avd -n phone -k "system-images;android-34;google_apis;x86_64" -d pixel_6
if [ ! -e /dev/kvm ]; then
  echo "No KVM on this sandbox: the Android emulator cannot start here." >&2
else
  $ANDROID_HOME/emulator/emulator -avd phone -no-window -no-audio -gpu swiftshader_indirect &
  $ANDROID_HOME/platform-tools/adb wait-for-device
fi

The emulator needs about 3 GB of RAM, so use default or bigger. adb exec-out screencap -p > screen.png takes a screenshot.

Pre-installed tools

AI & automation

Tool	Description
`claude`	Claude Code CLI, an AI coding assistant
`codex`	OpenAI Codex CLI
`pi`	Pi coding agent (pi.dev)
`opencode`	OpenCode terminal coding agent
`hermes`	Hermes Agent by Nous Research (browser tools not preinstalled: `hermes` offers to add them)
`openclaw`	OpenClaw CLI (gateway not started; run `openclaw gateway` yourself if you want it)
`agent` / `cursor-agent`	Cursor CLI agent
`prime-agent`	Prime Intellect’s Prime Agent
`kimi`	Kimi Code CLI by Moonshot AI
`vibe`	Mistral Vibe by Mistral AI (`--provider mistral`)
`host`	Expose localhost services to the internet
`lux`	Desktop and browser automation with demo recording
`boat`	Boat CLI inside the VM

These harnesses are installed system-wide (/usr/local, /opt), so they cost nothing in your snapshots and come back after a stop/resume. Each one signs in with its own login command; boat prompt and the Agents page drive claude and codex today. Installing your own copy (for example npm i -g or the vendor installer into ~/.local/bin) shadows the preinstalled one and is kept in your snapshots as usual.

Languages & runtimes

Tool	Description
`node` / `npm` / `nvm`	Node.js 24 with npm by default (nvm-managed, also linked into `/usr/local/bin` so non-login shells get it); the apt Node.js 20 remains for compatibility, and nvm installs other versions
`bun` / `bunx`	Bun JavaScript runtime
`deno`	Deno JavaScript/TypeScript runtime
`pnpm`	JavaScript package manager
`python3` / `pip` / `venv`	Python 3 and standard Python packaging tools
`uv`	Python project and dependency manager
`go`	Go toolchain
`rustc` / `cargo` / `rustup`	Rust compiler, package manager, and toolchain manager
`java` / `mvn` / `gradle`	Java/OpenJDK, Maven, and Gradle
`kotlin` / `kotlinc`	Kotlin runtime and compiler
`scala` / `scalac` / `sbt`	Scala compiler and build tools
`ruby` / `gem` / `bundle`	Ruby, RubyGems, and Bundler
`php` / `composer`	PHP CLI and Composer
`erl` / `elixir`	Erlang and Elixir
`dotnet`	.NET SDK
`R`	R runtime and development packages
`gcc` / `g++` / `clang` / `cmake` / `ninja`	C/C++ build toolchain

Version control

Tool	Description
`git`	Git
`gh`	GitHub CLI for PR creation, issue management, etc.

Utilities

Tool	Description
`rg`	ripgrep for fast code search
`jq`	JSON processor
`curl`	HTTP client
`docker`	Container runtime with BuildKit. Layer cache is per machine; see Docker builds across resume and fork
`google-chrome-stable`	Chrome browser and headless browser runtime
`ffmpeg`	Media processing

​Machine types

​Changing size

​Fail fast

​The machine

​Virtualization (KVM, Android emulator)

​Pre-installed tools

​AI & automation

​Languages & runtimes

​Version control

​Utilities

​Related