Templates and sizing

Provision from a template

Do not install your stack on a new sandbox for each user. Build it once, then fork it:

Create a sandbox. Install the runtimes, the dependencies and your daemon.
Stop it. Its snapshot is now your template.
Fork the template for each user. This takes a few seconds.

boat new                            # install runtimes, deps, your daemon
boat stop <template-id>             # its snapshot is now your template
boat fork <template-id> --no-env    # per user, a few seconds

curl -sS -X POST "$BOAT_API_BASE/sandboxes/<template-id>/fork" \
  -H "Authorization: Bearer $BOAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"noEnv":true,"env":{"TENANT_ID":"acme"}}'

const forked = await sandbox.fork({
  sandboxId: templateId,
  noEnv: true, env: { TENANT_ID: "acme" },
});

forked = sandbox.fork(template_id, ForkRequest(no_env=True, env={"TENANT_ID": "acme"}))

The per-fork env replaces the per-sandbox variables that the fork gets from the source. This is the same in the CLI (boat fork <id> -e KEY=V), the API and the SDKs.
A fork gets the whole file system of the template.
A fork is usable in seconds, at an almost constant cost, whatever the template holds.
A fork always uses the latest snapshot of the template.

To update the template:

Resume it.
Change it.
Stop it again.

See Template Sandboxes.

Sizing

The number of concurrent sandboxes follows your daily active users, not your signups. A rough rule from platforms on Boat:

Signups	Active users on an average day	Concurrent sandboxes
10,000	About 100	10 to 100

On a launch day, the peak is several times higher. Plan against two different limits:

Limit	What it controls
Concurrent-sandbox cap of your plan	How many sandboxes exist at the same time
Machine start limits	How fast you can start them

Create, fork and resume each count as one start. So pattern 3 uses starts each time a user comes back, not only at signup. See Pricing.

​Provision from a template

​Sizing

Provision from a template

Sizing