# Host Pools
source: https://docs.chalk.ai/docs/compute/host-pools

## Configure the hosts that back Chalk sandboxes, and size them so sandbox workloads can be scheduled.

### Overview

A host pool is a group of hosts that Chalk sandboxes run on. Each host is sized with a fixed
amount of CPU and memory, and Chalk packs sandbox containers onto the available hosts.

Host pools back workloads that use the host compute class, which is the default for
Sandboxes, along with interactive sessions and outbound managed SSH
connections from a sandbox. Scaling Groups,
Functions, model deployments, and notebook kernels run on Kubernetes
directly and do not use host pools.

Host pools size the hosts that sandboxes run on. Sizing an individual sandbox is done in
code with the cpu and memory parameters, and sizing Chalk's own platform services is done
under Infrastructure, described in Chalk Machine Types and
Resource Configuration. Those are separate systems.

### Where host pools are configured

Host pools can be configured at two scopes, both from the Chalk dashboard:

- Cluster: the pool serves every environment in the cluster. This is the recommended scope, because one pool can be shared cluster-wide. To edit these pools, click Clusters in the team navigation, select the cluster to open its Settings tab, and find Compute Host Pools.
- Environment: the pool serves a single environment, and cannot be shared with other environments. To edit these pools, open the environment's Settings, then Compute, and find Host Pools.

If a cluster has any host pool configured, sandbox placement uses the cluster's pools and
environment-scoped pools are ignored. Sandbox isolation is enforced the same way regardless of
scope, so workloads from different environments can share a cluster pool safely.

Editing host pools requires the deploy.create permission, held by the Admin, Owner, and Team
Manager roles. Every change is recorded in the audit log.

Host pools are not available in serverless environments.

### The default host pool

Until you configure a pool of your own, Chalk manages an implicit pool for you. It is created the
first time a host-class workload runs in an environment, and it appears in the dashboard marked
System managed with its fields locked:

| Setting         | Default  |
| --------------- | -------- |
| Minimum hosts   | 0        |
| Maximum hosts   | 2        |
| CPU per host    | 3        |
| Memory per host | 12Gi     |
| Idle timeout    | 1 minute |

A sandbox requesting more than 3 CPU or more than 12Gi of memory does not fit on these hosts and
fails to schedule. To run larger sandboxes,
configure a pool.

Creating your own host pool removes the system-managed default pool. Your pools then serve every
host-class workload in scope, so size them to cover your smallest and largest sandboxes, not only
the large one you added the pool for. Deleting your last pool restores the default.

### Configuring a host pool

Both scopes use the same editor, which lists one row per pool. Click the add (+) button to
create a pool, fill in its fields, and click Save changes. To delete a pool, click the remove
icon on its row and save. The system-managed default pool appears with a System managed badge,
and its fields cannot be edited.

Each pool has the following fields:

| Field               | Description                                                                                                                                               |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**            | A unique name within the scope. Use 3 to 63 characters: lowercase letters, numbers, and hyphens, starting with a letter.                                  |
| **Minimum hosts**   | Set to `0` for on-demand capacity, or to the same value as **Maximum hosts** for fixed capacity. Values in between are rejected.                          |
| **Maximum hosts**   | How many hosts the pool runs when it is active. Must be at least 1.                                                                                       |
| **Idle timeout**    | How long the pool sits empty before scaling back down, in minutes. Required for on-demand capacity, minimum 1 minute, and unavailable for fixed capacity. |
| **CPU per host**    | Cores per host, written as a core count such as `2`, `1.5`, or `500m`. Minimum `100m`.                                                                    |
| **Memory per host** | Memory per host, written as a byte quantity such as `512Mi`, `12Gi`, or `1T`. Minimum `512Mi`, maximum `1T`.                                              |

CPU and memory are set per host, not for the pool as a whole. A pool of 2 hosts at 8 CPU each can
run two sandboxes of 8 CPU, not one sandbox of 16. Chalk selects host hardware that satisfies the
CPU and memory you set, so there is no machine type to choose.

### On-demand and fixed capacity

Setting Minimum hosts to 0 gives you on-demand capacity. The pool runs no hosts while it is
empty, starts all of its hosts the first time a sandbox needs one, and returns to zero once it has
been empty for the idle timeout. The idle timeout is measured from the moment the last sandbox
leaves the pool, not from host CPU idleness.

Setting Minimum hosts equal to Maximum hosts gives you fixed capacity. The hosts stay
running, so sandboxes do not wait for a host to start.

On-demand pools scale as a unit: they run either zero hosts or the full Maximum hosts count.

### Troubleshooting

### A sandbox fails with "no configured host pool can satisfy"

```
Unschedulable: no configured host pool can satisfy cpu=8000m, memory=8589934592 bytes
```

No pool in scope is large enough to hold this sandbox. Chalk compares the request against the CPU
and memory of a single host in each pool, so a request larger than any one host fails even when
the pool's hosts add up to more than the request. The values in the message are the sandbox's
request: 8000m is 8 cores, and memory is in bytes, so 8589934592 is 8Gi.

To resolve it:

- Raise CPU per host or Memory per host on an existing pool so a host can hold the sandbox.
- Add a pool sized for the larger workload. Chalk places each sandbox on the smallest pool that fits it, so adding a large pool alongside a small one does not waste the small one.
- Reduce the sandbox's cpu or memory request.

Size hosts somewhat larger than the biggest sandbox you intend to run. A host reserves part of its
memory for its own overhead, so a sandbox requesting exactly the host's memory may still fail to
be placed.

### A sandbox fails with "all registered host-pool capacity is allocated"

```
Unschedulable: all registered host-pool capacity is allocated
```

The pools are sized correctly, but their hosts are full. Raise Maximum hosts, or wait for
running sandboxes to finish.

### A sandbox reports "no host with sufficient capacity"

```
Unschedulable for at least 600s: no host with sufficient capacity
```

Chalk waited for a host to become available and none did. This usually means the pool is still
waiting on the cloud provider for a host. If it persists, check whether the pool's CPU per
host and Memory per host are larger than the hardware available in your region.





