Skip to main content
By default, a deployment can make outbound requests to any host on the internet. Egress restrictions limit a deployment’s outbound traffic to an allow list of IP ranges and domains that you define in its config.yaml, so you can lock down a sensitive model without affecting any other deployment in your organization.

​
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: 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.
  • 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:
config.yaml

​
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:
config.yaml

​
Block all egress

To block all outbound traffic from the deployment, set both allow lists to null or []:
config.yaml
To return to the default of allowing all egress, 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 or cache them at build time with the model cache.

​
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 Baseten UI, so you can audit what each deployment is allowed to reach.

​
Limitations

  • Egress restrictions apply to model deployments only. They’re not supported for Chains, training jobs, or dedicated BIS-LLM deployments. To restrict a workload that’s currently a Chain, deploy the relevant chainlet as a standalone model.
  • ip_allow_list accepts 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. For Baseten’s broader isolation and compliance posture, see secure model inference.