Skip to main content

​
Accounts and sign-in

No. Sign in with GitHub, Google, or a 6-digit code emailed to you, on the CLI or the dashboard. GitHub is only required to clone your repositories into a sandbox, and you can connect it later without changing how you sign in. See Sign-in methods.
You are on a second account. A sign-in method creates a new account unless it is already connected to an existing one, matching email or not. Sign back in the way you did originally, then add the other method from Dashboard > Account. Merging two accounts that already exist is support-side only, so contact us if that happened.
Account notifications go to whichever connection is marked primary. Connect the address you want, then make it primary from Dashboard > Account. You cannot remove your primary connection or your last remaining one.

​
Regions and trust

In the EU: Germany, Finland, and France. Your data and snapshots stay there. How we handle account data is in the Privacy Policy.
Round trips are around 100 to 200 ms. Agentic work runs for minutes, so this is not noticeable in practice. For end-user production traffic, publish builds to a CDN or regional host and keep Boat for the agent and dev preview. See Build a Platform on Boat.
Not yet. SOC 2 is in progress. Sandboxes are full VMs with sudo, so you can add any controls you need inside them (firewall rules, proxies, encryption).

​
Billing

No. Stopped sandboxes are free, and their snapshot is kept for the life of the sandbox.
Nothing extra. The latest snapshot per sandbox is kept (up to your sandbox type’s data size), every sandbox has a dedicated IPv6 or IPv4, and egress is included up to 2 TB per sandbox per month. See Billing & Limits.
Plan time resets monthly. Purchased credit packs never expire.
boat usage <id>, or GET /sandboxes/{sandboxId}/usage, gives the machine time and list-price cost of a single sandbox, over its life or a billing window, running or stopped. It is the same meter your balance drains by, so platforms use it to bill their own users per sandbox. See Per-sandbox usage.

​
Lifecycle

Almost always boat stop: it snapshots, is free and reversible, and you can resume any time, months later included. Stopped sandboxes cost nothing, so there is rarely a reason to delete one.If you do want it gone, boat delete <id> (or Delete in the dashboard ⋯ menu) force-stops the sandbox and permanently deletes its snapshots. It cannot be resumed or forked afterwards and there is no undo, so reach for it only when you are sure the data is worthless. Snapshot data another sandbox forked or resumed from it still uses is kept, as are named snapshots saved from it. See Snapshots.
Stopping saves the disk first. If the sandbox has no successful snapshot in the last 30 minutes we take one to prove the pipeline works, and if that fails we leave the sandbox running rather than throw away your work. You are not billed for that time: the meter pauses by itself from the first failed attempt, so there is nothing to claim. If it persists, snapshots are failing on that sandbox: contact us. See When a stop is refused.
A few seconds, whatever the sandbox holds. Files stream in the background for the first moments after access is given; reading a file that has not arrived yet simply waits until it has, it never returns wrong data. Wait for state ready or idle before running commands; commands sent earlier run before your environment variables are applied.
Files, installed packages, and enabled systemd services do. Hand-run processes do not; restart them or make them a systemd service. Docker containers, their images and named volumes come back; the build cache does not; see Docker builds across resume and fork.

​
Running a platform

Compare the three patterns and their costs in Build a Platform on Boat.
Boat has no idle timer. The auto-stop TTL counts from creation or resume, never from last activity, so run your own countdown and call boat stop a few seconds to a couple of minutes after the agent finishes. Resume takes seconds, so a short countdown cuts cost with little UX impact. Budget the resumes: each one counts against your machine start limits exactly like a create.
Create, fork and resume each count as one machine start. Your plan sets a per-minute burst rate, and hour and day ceilings on top of it bound sustained spawning. The figures for every plan are in the table on Billing & Limits, and Machine starts explains how they scale. These limits rise as we add capacity, and we can lift them further for committed accounts, so contact us if you need more.
Prepare a template sandbox and boat fork it per user instead of installing from scratch, and check that your start limits cover the peak. See Template Sandboxes.
Yes. A fork inherits the whole filesystem in seconds, so you never pay for repeated installs.
Sandboxes have shared vCPUs and shine at agentic, IO-heavy, spiky work. boat new --type large doubles the CPU and memory of a default sandbox if a workload needs more headroom. For sustained multi-hour 100% CPU or GPU loads, dedicated compute primitives are a better fit.
Yes. Pass --type to resume or fork to move a sandbox between small, default, large, and xlarge. Growing always works; shrinking is refused when the sandbox holds more data than the smaller machine takes, and the sandbox is left exactly as it was. xlarge requires an effective $100-or-higher plan and an explicit bare-metal operator allocation. See Machine Capabilities.