> ## Documentation Index > Fetch the complete documentation index at: https://docs.nanovm.dev.lithosai.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Sandbox launch guide > First run, pilot limits, image expectations, recovery behavior, and support. Start with the default sandbox, run one command, and confirm cleanup before moving to your own image or longer jobs. Access is by invitation. ## First run 1. Use the account setup or sign-in link in your invitation. Complete email verification if prompted. If access is still pending, contact your inviter with the email address you used. 2. Check the organization name in the console. API keys and sandboxes belong to that organization. 3. Open **API Keys**, create a key, and copy its one-time value. Keep it private. 4. Open **Sandboxes → Get started → Python** and run the block in a terminal with Bash, curl, and Python 3.10 or newer. The example asks for your key, prints the sandbox ID and `42`, then deletes the sandbox. The curl tab offers the same sequence without installing the SDK. 5. Confirm the sandbox was deleted. Then use the [introduction](/) to run your application. The first-run examples create a default sandbox only. The Python example requires a virtual environment; both examples clean up on normal completion and execution errors. If a request or cleanup cannot be confirmed, inspect the printed sandbox ID in the console before trying again. If virtual-environment setup reports that `ensurepip` is unavailable, install the Python venv package for your Python version (usually `python3-venv` on Debian/Ubuntu), or use a virtual environment you already maintain. Stop at a failed setup step; do not continue by installing the SDK into system Python. ## Launch limits | Resource or behavior | Initial pilot | | ------------------------ | ---------------------------------------------------------------------------------------------------------- | | Concurrent sandboxes | Up to 20 per invited organization; running, paused, and sleeping guests count toward the resident limit | | Sandbox shape | Up to 4 vCPU and 8 GiB RAM; default 2 vCPU / 1 GiB | | Fork fanout | Up to four children per branch request, within the organization limit | | GPU | Not available | | Images | CPU workloads using compatible OCI images; the first use may need an image build | | Public endpoints | Anyone with the URL can reach an exposed service; the application must provide any required authentication | | Availability and billing | Governed by the pilot terms supplied with your invitation | For larger jobs, contact your inviter before changing the workload assumptions. Deleting unused sandboxes releases their capacity. Stopping a sandbox archives its state; retained snapshots and archives can continue to consume storage. ## Images and waiting A first image build, a cold restore on a host, and creation from a warm cache have different costs. Development warm timings are not cold-start guarantees. Large images can take tens of minutes to prepare. Measured during the September 2026 qualification (typical/observed worst, not contractual guarantees): a warm create returns in well under a second; a cold restore of the largest pilot images took 60–110 seconds. Sandbox creation is allowed up to five minutes end to end (SDK 0.4.6 widens only the create call; other requests keep the 120-second default). If your own client timeout is shorter, a large-image create can time out client-side while the create still succeeds — inspect existing sandboxes before retrying. The SDK handles template-building responses within its configured wait budget. Inspect the template's `status` and `status_detail` if progress stops. An expired client wait does not by itself prove that the underlying build failed. Repeatedly creating new requests is not a substitute for checking the existing operation. Long-running commands belong in a session or background execution with later result collection. See [Run commands](/guides/run-commands). ## Networking Outbound connectivity is IPv4 only; software that tries IPv6 first will log an unreachable attempt before falling back. Sandboxes share pilot egress addresses, and public package mirrors occasionally throttle or stall downloads: during qualification roughly 2% of heavy package-install runs hit a stalled or refused mirror connection that was not a platform fault. Write install steps to retry (for example `apt-get -o Acquire::Retries=3`) and prefer images that pre-install heavy dependencies over installing them at runtime. ## Recovery | Action/state | What to expect | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Pause | Holds the guest on its current host; use Resume. It does not protect against host loss. | | Sleep | Holds the guest on its current host; an eligible request wakes it. It does not protect against host loss. Idle guests sleep automatically, measured 60–110 seconds after the last activity (median 80 s); wake is transparent and took \~25 ms median. | | Stop | Archives the guest and pins it stopped. Use Start explicitly. | | Snapshot: not durable yet | A checkpoint exists locally. It still depends on its source host. | | Snapshot: durable | A checkpoint is saved to object storage. Restoring creates a new sandbox at that checkpoint. | | Snapshot: unknown | Durability was not reported. Confirm it before relying on host-loss recovery. | | Interrupted | The host was lost. Contact support to recover from an available durable checkpoint; later work may be lost. | | Delete | Removes the live sandbox. Separately retained snapshots remain subject to their own durability and retention. | The pilot does not offer automatic same-ID continuation after host loss or live migration. Automatic archiving is not part of the pilot; explicitly Stop or Delete a guest when finished. A busy server or background job may intentionally remain awake. Before a risky experiment, take a snapshot and wait for `durable: true` if you need recovery after host loss. Test restoring important checkpoints. An earlier snapshot cannot recover work written after it. ## Usage and pilot terms The usage panel shows measured resource usage, not an invoice. Read the pricing or credit arrangement, pilot duration, storage retention, and end-of-pilot cleanup terms in your invitation before running sustained workloads. Ask your inviter if any of those terms are missing. Usage display and billing are different: do not infer a charge from a resource counter alone. Usage is sampled on 60-second intervals per state (running, paused, slept), so sub-minute state changes blend into the surrounding interval; network egress is not metered in the pilot. ## Support Use the support contact or channel supplied with your invitation. If you cannot sign in, contact the person who invited you; signing in again is necessary after access has been granted. Email delivery and access approval are separate steps. For a stuck request, slow image, missing resource, or unexpected result, include: * Organization name, sandbox or snapshot ID, and UTC time. * The action you attempted, the error text, and whether it still reproduces. * SDK version and image reference, if relevant. * A small reproduction with private data removed. Never include API keys, passwords, cookies, signed URLs, or private registry credentials. Preserve the failing sandbox when practical so support can investigate; delete it if you need to release capacity and record its ID first. Your invitation defines support hours and the incident-update channel. A reply window is not a guarantee of uninterrupted service. For a host-loss incident, avoid assuming repeated Start requests will recover the same guest.