Prerequisites
Before starting with Tetrate Agent Router, verify that the following access and environment requirements are in place.
Checklist
Use this checklist to confirm readiness to proceed to the management plane onboarding and data plane installation.
- The onboarding email from Tetrate with the Admin Console URL has been received
- The browser meets the minimum version requirements
- The necessary network ports have been opened and verified to confirm the network requirements
- A security review has the connection summary
- The proxy endpoint URL, referred to as the data plane URL, is known
- The cluster meets the Kubernetes version requirement
- The target version to install is known, whether that is a
tareCLI version or an explicit chart version - The SSO configuration details are collected
Browser requirements
Agent Router is fully browser-based; no desktop software installation is required. Both applications support the following browsers:
- Google Chrome 90+
- Mozilla Firefox 90+
- Microsoft Edge 90+
- Safari 15+
JavaScript must be enabled. A screen resolution of 1280×720 or higher is recommended for the best experience, particularly when viewing usage dashboards and request log details.
Network requirements
Where network firewalls, security groups, or outbound proxies are in use, the connections listed below must be permitted.
Where outbound traffic must leave through a corporate proxy, settle the proxy topology before running tare install: the installer asks about it interactively, and the answers set how both management traffic and LLM traffic leave the cluster. The questions, both supported topologies, and the non-interactive flags are in Route outbound traffic through a corporate proxy.
Endpoints, direction, and ports
Direction is stated from the customer's perspective: Out is traffic that leaves the customer domain, In is traffic that enters it. All ports are TCP, and every Tetrate-hosted endpoint is HTTPS on port 443. Tetrate-hosted endpoints follow the pattern <service>.<tenant>.tetrate.ai, where <tenant> is the identifier issued during onboarding (for example tare-pn-12345678).
Which connections apply depends on the deployment model, and the difference is larger than it first appears. In a Self-Hosted Data Plane deployment the gateway runs in a customer-managed cluster, which is what makes the cluster-side rows and the single inbound path necessary. In an Enterprise Fully Managed deployment Tetrate runs both planes and nothing is installed in the customer environment, so every required connection is outbound from a browser or an application and no inbound rule exists at all. Both tables are given below; see Deployment models for the wider comparison.
Self-Hosted Data Plane
This is the model described by this section: Tetrate hosts the management plane, and the Controller and the gateway run in a customer-managed Kubernetes cluster.
| Endpoint | Direction | Port | Opened by | Purpose |
|---|---|---|---|---|
https://router.<tenant>.tetrate.ai | Out | 443 | Developer browsers | Console access: API keys, model catalog, usage monitoring |
https://dashboard.<tenant>.tetrate.ai | Out | 443 | Administrator browsers | Admin Console access: models, providers, users, settings |
https://auth.<tenant>.tetrate.ai | Out | 443 | All browsers, at sign-in | Authentication, including the OIDC callback used by SSO |
https://api.<tenant>.tetrate.ai | Out | 443 | Controller, from inside the cluster | Configuration polling and data plane health reports (/v1/dataplane-status) |
https://registry.tetrate.ai | Out | 443 | Cluster nodes and the install host | Container images and the Helm chart. Install and upgrade only, and avoidable by mirroring to a private registry |
https://tare.tetrate.ai | Out | 443 | Operator workstation | tare CLI download. Once per workstation, not needed by the cluster |
AI provider APIs, such as https://api.openai.com and https://api.anthropic.com | Out | 443 | Gateway | Model requests to each configured provider. Not required where every provider is self-hosted or reached over private connectivity |
| Remote MCP servers referenced by MCP profiles | Out | 443 | Gateway | MCP tool calls to servers hosted outside the cluster |
External observability backend, such as https://otlp.nr-data.net or https://trace.agent.datadoghq.com | Out | 4317 (OTLP gRPC) or 443 | In-cluster OpenTelemetry collector | Telemetry export. Not required where the observability stack runs inside the customer environment |
https://acme-v02.api.letsencrypt.org | Out | 443 | cert-manager | Certificate issuance for the gateway hostname. Only where Let's Encrypt is used rather than an internal certificate authority |
Gateway endpoint on a customer-owned hostname, such as https://ai-gateway.acme.com | In | 443 | Client applications, agents, and coding assistants | AI request routing. This ingress is created and controlled by the customer and can be internal-only. It terminates on the in-cluster egress service on port 10080 |
| Corporate OIDC identity provider: discovery, authorization, and token endpoints | In | 443 | Tetrate-hosted authentication service | Validation of the discovery document and exchange of the authorization code. Applies only where the identity provider is self-hosted and not otherwise reachable from outside the customer domain. No rule is needed for a SaaS identity provider such as Entra ID, Okta, or Google |
| Let's Encrypt HTTP-01 challenge validation | In | 80 | Let's Encrypt validators | Certificate issuance only. Avoidable with the DNS-01 solver or a certificate supplied from an internal public key infrastructure |
| Tetrate management plane into the cluster | None | None | Nothing | No connection is ever initiated from Tetrate into the customer environment, so no inbound rule is required on Tetrate's behalf |
Only two of these entries are unavoidable: the outbound connection from the Controller to api.<tenant>.tetrate.ai, and the inbound path from client applications to the gateway, which the customer defines. Every other row is either conditional on a feature being used or removable, as described in the sections that follow.
Enterprise Fully Managed, for comparison
Nothing is installed in the customer environment, so there is no cluster, no ingress to create, and no cluster-side egress. The gateway is Tetrate-hosted and is called outbound like any other SaaS API.
| Endpoint | Direction | Port | Opened by | Purpose |
|---|---|---|---|---|
https://router.<tenant>.tetrate.ai | Out | 443 | Developer browsers | Console access: API keys, Base URL, request logs, usage |
https://dashboard.<tenant>.tetrate.ai | Out | 443 | Administrator browsers | Admin Console access: models, providers, users, settings |
https://auth.<tenant>.tetrate.ai | Out | 443 | All browsers, at sign-in | Authentication, including the OIDC callback used by SSO |
https://proxy.<tenant>.tetrate.ai/v1 | Out | 443 | Applications, agents, and coding assistants | AI request routing. This is the Base URL shown in the Console, and it is the row that reverses direction in a Self-Hosted Data Plane deployment, where the same function is served by a customer-owned hostname |
| Corporate OIDC identity provider: discovery, authorization, and token endpoints | In | 443 | Tetrate-hosted authentication service | As in the self-hosted case, and required only where the identity provider is self-hosted and not otherwise reachable from outside the customer domain |
Three consequences of the model are worth noting before a firewall change request is raised:
- Nothing that appears in the self-hosted table as cluster-side traffic applies.
registry.tetrate.aiandtare.tetrate.aiare not contacted, no certificate is issued for a customer hostname, and no inbound rule is opened for the gateway. - Connections to AI providers and to remote MCP servers originate from Tetrate's environment rather than the customer's. Where a provider account restricts access by source address, the allowlist must therefore cover Tetrate's egress and not the customer's.
- Telemetry export to a customer-hosted observability backend is the one case that reverses direction, since the exporter would run on Tetrate's side. Confirm the arrangement with Tetrate before assuming a self-hosted collector can be used.
Everything below applies to the self-hosted case.
Data plane connections
In a Self-Hosted Data Plane deployment the data plane (the Controller and the Agent Router gateway) runs in a customer-managed Kubernetes cluster, and Tetrate hosts the management plane. The connections the cluster needs are listed below, stated relative to the customer environment.
| Direction | Connection | Port | Required |
|---|---|---|---|
| Outbound | Controller to the management plane, for configuration polling | 443 | Yes. This is the only connection the data plane needs in steady state. |
| Outbound | Gateway to AI provider endpoints | 443 | Yes, unless every configured provider is self-hosted or reached over private connectivity. |
| Outbound | Cluster to registry.tetrate.ai, for container images and the Helm chart | 443 | At install and upgrade only. Avoidable by mirroring the images and chart into a private registry. |
| Inbound | Client applications to the gateway | 443 | Yes, but this ingress is created and controlled by the customer, and it can be internal-only. |
| Inbound | Tetrate or the public internet into the cluster | None | No. Nothing outside the environment opens a connection into the data plane. |
Mirroring images and the chart to a private registry is covered under Data plane installation; keeping provider traffic off the public internet is covered under Private provider connectivity.
Outbound-only applies to every self-hosted deployment
The outbound-only design is a property of the architecture, not a separate deployment mode. Network and Security discusses it under the heading Intranet deployment, which describes the most restrictive network posture rather than a distinct product configuration: the whole page applies to Self-Hosted Data Plane deployments. A standard self-hosted install therefore has the same property as the intranet case. The management plane never opens a connection into the customer environment, and no inbound firewall rules are needed on Tetrate's behalf.
What an intranet posture adds is a choice the customer makes about the gateway's own ingress. Where every application calling the gateway is itself internal, the gateway can be exposed on an internal address only and no public ingress is needed at all.
Summary for a security review
The points a security team most often asks about, collected for a review or a firewall change request:
- The management plane never initiates a connection into the customer environment. There is no exposed listener for Tetrate to call and no inbound firewall rule to open.
- Configuration reaches the data plane over a single outbound HTTPS connection on port 443, opened from inside the cluster by the Controller and used to poll for updates.
- Prompts and responses travel only through the data plane in the customer's environment. The outbound configuration connection carries configuration, not request content. What request detail is sent to the management plane is itself configurable; see Control what request data leaves the cluster.
- Traffic to AI providers can be held on private connectivity (Azure Private Link, AWS PrivateLink, GCP Private Service Connect) so it never crosses the public internet, and a fallback chain built only from private endpoints cannot route to a public provider.
- Gateway ingress is the customer's own. It can be restricted to internal networks, and mutual TLS can be required of callers.
- Registry access is needed only at install and upgrade, and can be removed entirely by mirroring images and the Helm chart into a private registry.
Full detail on each control, written for a reader without a networking background, is in Network and Security. For topology, see Deployment models and Architecture Overview.
The Data plane URL field
A customer-facing gateway URL, the address that client applications call. The management plane stores it against the workspace and it gets pulled into the data plane's own configuration, so that the Console can show developers the endpoint to use and the gateway knows the address it serves. Nothing in the management plane dials it.
Three consequences follow, all useful to know before onboarding starts:
- The URL does not need to be reachable from the management plane or from the internet. It needs to be reachable by whatever calls the gateway, so an internal-only hostname is correct when every caller is internal.
- The URL does not need to resolve at install time. It is recorded as configuration, and DNS can be wired afterward.
- The field is optional. It can be left empty during onboarding and registered later under System → Settings → Data planes.
The onboarding wizard's Data plane URL field is described in the interface as the URL the management plane uses to reach the AI Gateway. That label is misleading and has caused the field to be read as an inbound connection requirement. It is not one, as outlined in the security summary review.
Until a URL is registered, the message The administrator needs to complete the DP URL configuration is shown. It means no gateway address has been recorded yet, not that a connection is failing. The message has two causes, and they are cleared in different places:
- No data plane URL at all, which is the case this field covers. Register it under System → Settings → Data planes.
- A project whose own gateway has no URL, which is common once a second project is created on a data plane exposing a single hostname. Registering the shared workspace URL again does not clear it, because the project needs a hostname of its own. See Each project gateway needs its own hostname.
See Management plane onboarding for the field in context, and Manage multiple gateways on a data plane for why a data plane can own more than one such URL.
Kubernetes requirements
Self-hosted data plane installs require a Kubernetes cluster running a release in the supported range for the current release, 1.32 to 1.35. The range is fixed per release and enforced at install time, and the range for every supported release is listed on Release compatibility.
A cluster already running Envoy Gateway
The data plane installs a GatewayClass named tars-egress, whose controllerName is the Envoy Gateway default, gateway.envoyproxy.io/gatewayclass-controller. An Envoy Gateway installation that already watches the whole cluster therefore claims tars-egress as well, and the two controllers contend over it.
The controllerName cannot be overridden, so this has to be settled before installing rather than after. Where Envoy Gateway already runs cluster-wide, install the data plane in a cluster of its own.
Confirm the cluster is clear before starting:
kubectl get gatewayclass
kubectl get deployments -A -l app.kubernetes.io/name=envoy-gateway
Which version to install
The registry publishes a long list of versions carrying pre-release identifiers such as alpha and rc, which makes the choice look more consequential than it is. Which version applies depends on the install path.
With tare install, no version is chosen. The CLI carries an embedded Helm chart and deploys that, so the data plane version follows the version of the tare binary in use. Installing a current CLI is the whole of the decision, and tare --version reports what is installed. The --chart-version flag exists only for overriding the embedded chart with a remote or OCI one through --chart-path, which is not the usual path.
With a direct Helm install, a version is required, because the chart is pulled from the registry as an OCI artifact:
CHART_VERSION="0.1.0-alpha.1+17f076b"
Unless Tetrate has pinned a version for the deployment, use the most recently published chart version. The pre-release identifiers currently in use reflect a pre-1.0 release train that is moving to a plain SemVer scheme; they are not a reason to prefer an older tag, and there is no separate stable channel to select from. Where a version is being chosen for a production install, confirm the intended one with Tetrate rather than inferring it from the tag list.
Two constraints on the version string itself cause most install failures:
- The value must be a full SemVer version. A bare commit SHA is rejected before Helm contacts the registry.
- Build metadata is joined with
+, as in0.1.0-alpha.1+17f076b. The registry stores the same tag internally with_, but Helm's--versionrequires the+form. A release-build version such asv0.1.0-beta.3is also accepted.
Record the version that was installed, since upgrades and support conversations both depend on knowing it. The mechanics of both paths, including mirroring the chart to a private registry, are in Data plane installation and the tare install reference.
SSO requirements
Single sign-on (SSO) lets users access the Console and Admin Console through the corporate identity provider. Any OIDC-compliant identity provider is supported.
Before configuring SSO, collect the following details:
- Issuer (Identity Provider URL)
- Client ID
- Client Secret
- Discovery URL (optional)
When SSO is required depends on the deployment path. Open the relevant path from the Get started sidebar, or see Deployment models where it is unclear which applies.
- Agent Router Service: SSO is handled by Tetrate; no customer SSO setup.
- Enterprise Fully Managed: Configure SSO during onboarding (wizard Step 2) or confirm it is already set up in a PoC environment.
- Enterprise Self-Hosted Data Plane: Gather SSO details before starting. They are entered during onboarding (wizard Step 2), and sign-in to the Console and the Admin Console afterward goes through the identity provider.
In Tetrate-provisioned PoC environments, SSO may already be configured; confirm with the administrator before starting the onboarding wizard. Mapping IdP roles to Agent Router roles is optional and can be done after the data plane is running.
Where to go next