> ## Documentation Index
> Fetch the complete documentation index at: https://docs.boat.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Short answers on accounts, regions, billing, snapshots, lifecycle, and running a platform on Boat.

## Accounts and sign-in

<AccordionGroup>
  <Accordion title="Do I need a GitHub account?">
    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](/quickstart#sign-in-methods).
  </Accordion>

  <Accordion title="I signed in with Google and my sandboxes are gone.">
    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](https://boat.dev/dashboard?tab=account). Merging two accounts that already exist is support-side only, so contact us if that happened.
  </Accordion>

  <Accordion title="How do I change the email address Boat writes to?">
    Account notifications go to whichever connection is marked primary. Connect the address you want, then make it primary from [Dashboard > Account](https://boat.dev/dashboard?tab=account). You cannot remove your primary connection or your last remaining one.
  </Accordion>
</AccordionGroup>

## Regions and trust

<AccordionGroup>
  <Accordion title="Where do sandboxes run?">
    In the EU: Germany, Finland, and France. Your data and snapshots stay there. How we handle account data is in the [Privacy Policy](https://boat.dev/privacy).
  </Accordion>

  <Accordion title="Is EU latency a problem from the US or Latin America?">
    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](/platform-guide).
  </Accordion>

  <Accordion title="Do you have compliance certifications?">
    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).
  </Accordion>
</AccordionGroup>

## Billing

<AccordionGroup>
  <Accordion title="Am I billed when a sandbox is stopped?">
    No. Stopped sandboxes are free, and their snapshot is kept for the life of the sandbox.
  </Accordion>

  <Accordion title="What do snapshots, IP addresses, and egress cost?">
    Nothing extra. The latest snapshot per sandbox is kept (up to your sandbox type's [data size](/machines#machine-types)), every sandbox has a dedicated IPv6 or IPv4, and egress is included up to 2 TB per sandbox per month. See [Billing & Limits](/billing).
  </Accordion>

  <Accordion title="Do unused credits expire?">
    Plan time resets monthly. Purchased credit packs never expire.
  </Accordion>

  <Accordion title="How much has one sandbox cost me?">
    `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](/billing#per-sandbox-usage).
  </Accordion>
</AccordionGroup>

## Lifecycle

<AccordionGroup>
  <Accordion title="How do I get rid of a sandbox?">
    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](/snapshots#deleting-a-sandboxs-snapshots).
  </Accordion>

  <Accordion title="Why does a sandbox sometimes come back up instead of stopping?">
    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](/snapshots#when-a-stop-is-refused).
  </Accordion>

  <Accordion title="How fast are resume and fork?">
    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.
  </Accordion>

  <Accordion title="Do processes survive stop and resume?">
    Files, installed packages, and enabled systemd services do. Hand-run processes do not; restart them or [make them a systemd service](/long-running-tasks#run-an-always-on-service). Docker containers, their images and named volumes come back; the build cache does not; see [Docker builds across resume and fork](/snapshots#docker-builds-across-resume-and-fork).
  </Accordion>
</AccordionGroup>

## Running a platform

<AccordionGroup>
  <Accordion title="One sandbox per user, per project, or per session?">
    Compare the three patterns and their costs in [Build a Platform on Boat](/platform-guide).
  </Accordion>

  <Accordion title="How long should I leave a user's sandbox running before stopping it?">
    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.
  </Accordion>

  <Accordion title="What counts as a machine start, and what are the limits?">
    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](/billing), and [Machine starts](/billing#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.
  </Accordion>

  <Accordion title="How do I handle launch spikes?">
    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](/snapshots#template-sandboxes).
  </Accordion>

  <Accordion title="Do prepared templates actually reduce billed time?">
    Yes. A fork inherits the whole filesystem in seconds, so you never pay for repeated installs.
  </Accordion>

  <Accordion title="Is Boat good for sustained heavy compute?">
    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.
  </Accordion>

  <Accordion title="Can I resize a sandbox?">
    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](/machines).
  </Accordion>
</AccordionGroup>