Network endpoints
The hosts your deployment reaches over outbound HTTPS, so your network team can allow them.
Audience: IT (the enabler)
A self-hosted deployment communicates with a small set of Sema4.ai services over outbound HTTPS (port 443) for licensing, image and update distribution, and a few managed services. Allow egress from your environment to the hostnames below.
These are the Sema4.ai endpoints, plus the registries that serve the sandbox runtime. Your deployment also needs egress to the services you connect it to: model providers, MCP servers, integrations, and data sources. See Connections.
Required endpoints
| Endpoint | Purpose |
|---|---|
get.sema4.ai | Enterprise Portal. Licensing, and install and update instructions. |
proxy.sema4.ai | Container image distribution. Pulling the application images. |
registry.sema4.ai | Helm chart registry. Pulling and upgrading the application Helm chart. |
app-updates.sema4.ai | Application update service. Release availability and update delivery. |
backend.sema4.ai | License validation, issue and support report uploads, and Document Intelligence. |
Nothing is fetched at node bootstrap. The node needs no platform packages
and downloads nothing at boot. The data root is formatted from inside the
application's own image, which arrives from proxy.sema4.ai like every other
image. See The data root.
Sandbox runtime registries
The sandbox runtime is not distributed by Sema4.ai. You install it yourself from the Kata Containers project's registries, so allow these before the install described in Install the sandbox runtime.
| Endpoint | Purpose |
|---|---|
ghcr.io | The kata-deploy Helm chart, pulled as an OCI artifact. |
quay.io | The Kata Containers images the chart runs on each node. |
Both registries serve their blobs from other hosts. ghcr.io redirects to
pkg-containers.githubusercontent.com, and quay.io to its cdn*.quay.io
endpoints, so an allow-list that names only the two registries fails at the
layer pull. Allow the blob hosts too, or mirror the chart and images into a
registry you already permit.
Optional endpoints
These are only needed when the corresponding capability is enabled for your deployment:
| Endpoint | Purpose |
|---|---|
llm.backend.sema4.ai | Sema4.ai-managed LLM proxy. Only required if Sema4.ai provides a managed model endpoint for your deployment. |
dx.sema4.ai | Product usage telemetry. |
product-assets.sema4.ai | Sandbox runtime assets for the Firecracker backend. Not used by the Kata Containers configuration in this guide, which pulls its runtime image from proxy.sema4.ai. |
Data sources use their own ports
Most egress is plain HTTPS on 443, but data connections are the exception. When you connect a database, allow egress to that host on its own port, which is usually not 443. Common defaults:
| Database | Default port |
|---|---|
| PostgreSQL | 5432 |
| MySQL | 3306 |
| Amazon Redshift | 5439 |
| Snowflake | 443 |
| Google BigQuery | 443 |
| Databricks | 443 |
Unrestricted outbound HTTPS is the simplest configuration and what we recommend for most deployments. If your environment requires an explicit allow-list, the hosts above are the Sema4.ai destinations to include.
When to add rules
Egress is not a one-time task. Add outbound rules whenever you introduce something new:
| You added | Allow egress to |
|---|---|
| A new model provider | The provider's API endpoints |
| A new MCP server | The endpoints that server calls upstream |
| A new OAuth provider for an integration | The provider's OAuth and API endpoints |
| A new observability vendor | The vendor's OTLP ingest endpoint |
| A new data source | The database host, on that database's port |
What this article will cover
- Proxy configuration for environments without direct egress
- Verifying egress from inside the cluster