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

# Egress restrictions

> Restrict a deployment's outbound network traffic to an allow list of IP ranges and domains.

By default, a deployment can make outbound requests to any host on the internet on TCP ports 443 and 80. Egress restrictions limit a deployment's outbound traffic to an allow list of IP ranges and domains that you define in its [`config.yaml`](/reference/truss-configuration), so you can lock down a sensitive model without affecting any other deployment in your organization.

<Note>
  Egress restrictions must be enabled for your organization. [Contact support](mailto:support@baseten.co) to request access.
</Note>

## How egress restrictions work

Egress restrictions are scoped to the deployment they're configured on. Two allow lists, `ip_allow_list` and `fqdn_allow_list`, determine one of three behaviors:

| Configuration | Behavior |
| - | - |
| `egress_restrictions` omitted or `null` | All egress to TCP ports 443 and 80 is allowed (default). |
| Both lists set to `null` or `[]` | All egress is blocked. |
| One or both lists have entries | Only traffic matching an entry is allowed. |

Outbound requests that don't match an entry in either list fail. After applying restrictions, test your deployment's outbound calls to confirm everything it needs is allowed.

## Configure egress restrictions

Add an `egress_restrictions` section under the `runtime` block in `config.yaml`. It accepts two allow lists:

* `ip_allow_list`: IPv4 addresses or CIDR ranges, for example `203.0.113.10/32` or `198.51.100.0/24`. Bare IPs like `203.0.113.10` are normalized to `/32` at deploy time. IPv6 addresses aren't supported and fail validation at [`truss push`](/reference/cli/truss/push). Entries must be public IP space: any entry that overlaps private or otherwise reserved ranges also fails validation.
* `fqdn_allow_list`: fully qualified domain names. The wildcard `*` can appear anywhere in a label, for example `*.baseten.co` or `api-*.example.com`.

Allow lists can't be updated in place on an existing deployment. To change them, deploy a new version with the updated `egress_restrictions`.

### Allow specific IPs and domains

To allow egress to select IPs and domains only, list each one:

```yaml config.yaml theme={"system"}
model_name: my-llm
resources:
  cpu: "4"
  memory: 16Gi
  accelerator: L4
runtime:
  egress_restrictions:
    ip_allow_list:
      - 203.0.113.10/32      # an external API your model calls
      - 198.51.100.0/24      # your internal service range
    fqdn_allow_list:
      - "*.baseten.co"
      - huggingface.co
```

### Allow calls to other Baseten models

To let a deployment call specific Baseten model endpoints and nothing else, allow each model's exact hostname rather than a broad wildcard like `*.api.baseten.co`, which would permit calls to any Baseten-hosted model:

```yaml config.yaml theme={"system"}
runtime:
  egress_restrictions:
    fqdn_allow_list:
      - model-wd1pneew.api.baseten.co
      - model-qjd0j2jq.api.baseten.co
```

### Block all egress

To block all outbound traffic from the deployment, set both allow lists to `null` or `[]`:

```yaml config.yaml theme={"system"}
runtime:
  egress_restrictions:
    ip_allow_list: null
    fqdn_allow_list: null
```

To return to the default of allowing all egress to TCP ports 443 and 80, set `egress_restrictions` to `null` or remove the section entirely.

## Allow runtime downloads

Egress restrictions apply to all outbound traffic, including downloads your model makes at runtime. If your model pulls weights from `huggingface.co`, installs packages at startup, or calls external APIs from `predict`, add those hosts to the allow lists or the requests fail.

To avoid downloading weights at runtime entirely, load them through the [Baseten Delivery Network](/development/model/bdn) or cache them at build time with the [model cache](/development/model/model-cache).

## Restrict BIS-LLM deployments

For [BIS-LLM](/engines/bis-llm/overview), pass the same `runtime.egress_restrictions` block in `config.yaml`. Your organization must have BIS egress restrictions enabled. [Contact support](mailto:support@baseten.co) to request access.

BIS-LLM has no default host allow list. If the deployment downloads weights from Hugging Face at runtime, allow the download hosts it needs or mount the weights with [BDN](/development/model/bdn). If `bis_llm.config` calls another Baseten model, allow that model's exact hostname.

[`truss push`](/reference/cli/truss/push) warns when these required hosts are missing from the allow list. Interactive pushes ask whether to continue; non-interactive pushes and the Python SDK report the warning without prompting.

## View egress restrictions

A deployment's egress restrictions appear with the rest of its configuration in the Truss config viewer on the model's page in the dashboard, so you can audit what each deployment is allowed to reach.

## Limitations

* Egress restrictions apply to model deployments only, including dedicated deployments using the [Baseten Inference Stack (BIS)](/engines/bis-llm/overview). They're not supported for [Chains](/development/chain/overview) or [training jobs](/training/overview). To restrict a workload that's currently a Chain, deploy the relevant chainlet as a standalone model.
* Egress restrictions do not apply to traffic routed through the [BDN proxy](/development/model/bdn#bdn-proxy). If the BDN proxy is enabled for your organization, any requests your model sends through it can reach any destination the proxy serves, regardless of the `ip_allow_list` and `fqdn_allow_list` you define.
* `ip_allow_list` accepts public IPv4 only.
* `fqdn_allow_list` enforcement is IP-based and can't isolate individual resources on shared infrastructure. Each allowed domain is enforced by resolving it to its current IP addresses and permitting traffic to those IPs; the hostname on the outbound request itself isn't inspected. Providers such as Amazon S3 serve many resources (for example, every bucket in a region) from a shared pool of IPs, so allowing one bucket's hostname permits traffic to any resource reachable at the same IPs. In practice this means a request can reach a different bucket on that endpoint even though only one is listed.

## Next steps

Egress restrictions are one part of locking down a deployment. To keep credentials out of your config and code, use [secrets](/development/model/secrets). For Baseten's broader isolation and compliance posture, see [secure model inference](/observability/security).