# Sandbox
source: https://docs.chalk.ai/docs/compute/sandbox

## What Chalk sandboxes are, where they run, and when to use one.

### Overview

Chalk sandboxes are lightweight, isolated execution environments for running arbitrary
code — agent workloads, model inference, data pipelines, or any container-based task.
Each sandbox runs inside a gVisor-hardened container with its own filesystem, network
namespace, and resource limits.

Sandboxes are designed around three principles:

- Strong isolation. Workloads from different tenants (and different workloads from the same tenant) cannot observe or interfere with each other.
- Flexible deployment. The same sandbox abstraction runs on managed serverless infrastructure (compute_class=ComputeClass.HOST, the default) or on your own Kubernetes clusters (compute_class=ComputeClass.K8S).
- First-class GPU support. GPU-accelerated workloads use the same Sandbox API as CPU workloads — see Resources and GPUs for the compute_class requirement.

To create and run your first sandbox, see Quick Start.

### Deployment models

### Managed serverless

Chalk operates a fleet of bare-metal nodes optimized for sandbox workloads. When you create
a sandbox without additional configuration, it runs on this managed infrastructure:

```
from chalkcompute import Image, Sandbox

sandbox = Sandbox(image=Image.debian_slim()).run()
```

Managed serverless handles provisioning, scaling, and node maintenance. Sandboxes are
scheduled across availability zones and can cold-start in under two seconds for
common base images.

### Features by compute class

Sandboxes run on the host compute class unless you set
compute_class=ComputeClass.K8S. Some features work on only one of them:

| Feature                                                                        | `host` | `k8s` |
| ------------------------------------------------------------------------------ | ------ | ----- |
| [Mounting volumes](/docs/sandboxes/configuring-sandboxes#mounting-volumes)     | Yes    | Yes   |
| [`exec`, `exec_stream`, and `exec_start`](/docs/sandboxes/running-commands)    | Yes    | No    |
| [Workload identity federation](/docs/workload-settings/workload-identity)      | Yes    | Yes   |
| [MCP Gateway](/docs/sandboxes/mcp-gateway)                                     | Yes    | Yes   |
| [`KernelPolicy.RESTRICTED`](/docs/sandboxes/isolation#kernel-hardening)        | Yes    | Yes   |
| [`KernelPolicy.OPEN`](/docs/sandboxes/isolation#kernel-hardening)              | No     | Yes   |
| [Network policies](/docs/sandboxes/networking#network-policy)                  | Yes    | No    |
| [Resource detection](/docs/sandboxes/configuring-sandboxes#resource-detection) | Yes    | No    |
| [Managed SSH](/docs/sandboxes/networking#managed-ssh)                          | Yes    | No    |
| [Tunnels](/docs/tunnels)                                                       | Yes    | No    |

### When to use a Sandbox

Use a Sandbox for a task you address directly as a single workload: running generated
agent code, a one-off data backfill, or a per-session workspace that is torn down when
the session ends. Sandboxes also run for hours or days, as
Long-running sandboxes describes.

For replicated, HTTP-fronted workloads with autoscaling, use a
Scaling Group. For serverless, function-shaped
invocations, use Functions.

Run length alone does not decide between a sandbox and a scaling group, since both
survive disconnects and can be reattached to by name. Choose by how the workload is
reached: a sandbox is one instance you run commands in over exec, while a scaling
group serves an HTTP endpoint backed by replicas that Chalk scales. A long-lived agent
session that you drive through a web UI belongs in a scaling group, which is why
Deep coding agents uses one.