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

# Routing & Modes

> Deployment modes, routing policies, capacity profiles, isolation, and egress for fleets.

Routing and modes control *where* and *how* a fleet runs. Choosing the right combination directly affects cost, latency, and isolation. A dev/test fleet might use serverless mode with cold starts allowed; a production fleet handling sensitive data might need dedicated compute in a VPC with an always-on pool. This page lays out the options so you can make that tradeoff deliberately.

A fleet's runtime behavior is governed by five configuration dimensions: deployment mode, routing policy, capacity profile, isolation profile, and egress policy. Together they determine cost, latency, resilience, and security posture.

## Deployment modes

How the fleet's compute capacity is provisioned.

| Mode         | Behavior                                                        | Best for                                   |
| ------------ | --------------------------------------------------------------- | ------------------------------------------ |
| `serverless` | Shared serverless plane; scales to zero when idle.              | Spiky or low-volume workloads.             |
| `fluid`      | Always-on with CPU throttling; millisecond wake, low idle cost. | Most production agents.                    |
| `dedicated`  | Reserved, isolated capacity.                                    | Predictable high load or strict isolation. |

## Routing policies

How incoming work is distributed.

| Policy     | Behavior                                                |
| ---------- | ------------------------------------------------------- |
| `pinned`   | Routes to a fixed target.                               |
| `geo`      | Routes by geographic proximity to the caller.           |
| `failover` | Routes to a primary with automatic fallback on failure. |

## Capacity profiles

The responsiveness-versus-cost tradeoff.

| Profile         | Behavior                                                   |
| --------------- | ---------------------------------------------------------- |
| `cold_start_ok` | Accepts cold starts to minimize idle cost.                 |
| `warm_pool`     | Keeps a warm pool ready for faster response.               |
| `always_on`     | Keeps capacity always ready; lowest latency, highest cost. |

## Isolation profiles

How fleet workloads are isolated from each other.

| Profile    | Behavior                                                                                 |
| ---------- | ---------------------------------------------------------------------------------------- |
| `shared`   | Shared infrastructure with logical isolation.                                            |
| `enhanced` | Dedicated isolation boundaries. Workloads from other fleets cannot access its resources. |
| `vpc`      | Dedicated VPC-level network isolation.                                                   |

## Egress policies

What outbound network access is permitted.

| Policy         | Behavior                                           |
| -------------- | -------------------------------------------------- |
| `standard`     | Unrestricted outbound access.                      |
| `restricted`   | Limited to approved destinations.                  |
| `private_only` | No public internet egress; private endpoints only. |

## Choosing a configuration

| Use case                         | Deployment   | Capacity        | Routing                           |
| -------------------------------- | ------------ | --------------- | --------------------------------- |
| Internal tool, occasional use    | `serverless` | `cold_start_ok` | `pinned`                          |
| Production agent, steady traffic | `fluid`      | `warm_pool`     | `geo`                             |
| Latency-critical, isolated       | `dedicated`  | `always_on`     | `failover`                        |
| Compliance-sensitive             | `dedicated`  | `warm_pool`     | `pinned` + `vpc` + `private_only` |

<Tip>
  Start conservative (`serverless` / `cold_start_ok`) and tighten as load patterns become clear. You can view fleet configuration with `client.orchestrator.fleet.get()` but changes are made through the Console.
</Tip>

<AccordionGroup>
  <Accordion title="Cost implications">
    `always_on` + `dedicated` has the highest baseline cost but lowest latency variance. `serverless` + `cold_start_ok` has near-zero idle cost but occasional cold-start latency. `fluid` + `warm_pool` balances the two for most production workloads.
  </Accordion>

  <Accordion title="Multi-region deployments">
    Use `geo` routing with `fluid` or `dedicated` mode to serve users from the nearest region. Combine with `failover` for resilience across regions.
  </Accordion>
</AccordionGroup>

## Choosing a configuration

| Workload                         | Deployment mode | Capacity profile | Routing             |
| -------------------------------- | --------------- | ---------------- | ------------------- |
| Internal tool, occasional use    | `serverless`    | `cold_start_ok`  | `pinned`            |
| Production agent, steady traffic | `fluid`         | `warm_pool`      | `pinned` or `geo`   |
| Latency-critical or isolated     | `dedicated`     | `always_on`      | `geo` or `failover` |

Start conservative and tighten as traffic becomes predictable. Reserve `always_on` for latency-critical fleets — it minimizes cold starts but maximizes idle cost.

<Note>
  A `primary_region` is required when you create a fleet. Routing policies such as `geo` and `failover` build on it to place and fail over work.
</Note>

## Related pages

<CardGroup cols={2}>
  <Card title="Fleets" icon="layer-group" href="/docs/orchestration/fleets">
    Where these settings apply.
  </Card>

  <Card title="Tasks" icon="list-check" href="/docs/orchestration/tasks">
    Work that runs under these settings.
  </Card>

  <Card title="Fleets (concept)" icon="layer-group" href="/docs/concepts/fleets">
    The conceptual model.
  </Card>

  <Card title="Billing & Usage" icon="gauge" href="/docs/billing/usage">
    How configuration affects cost.
  </Card>
</CardGroup>

## Next steps

Continue to [Approvals](/docs/orchestration/approvals).