# Provision a gateway for a project > Select a data plane on a project in Tetrate Agent Router so the platform auto-provisions a gateway and gives the project a stable customer-facing inference URL. Enterprise Tier A gateway is a single inference endpoint, one customer-facing URL, provisioned by a data plane and mapped to exactly one project. Selecting a data plane on the project is the step that turns configuration into something applications can call: the platform provisions the project's first gateway automatically. There is no separate top-level Gateways menu and no create-then-select flow for that default path. This guide places the project on a data plane, sets its URL, and confirms the gateway is ready. Attaching additional gateways for high availability is optional and covered later in this page. A project owns the logical configuration (models, keys, policy); a gateway is the physical capacity that serves it. The two are separate on purpose: the project's setup is decoupled from the runtime that runs it, so the endpoint can later be upgraded or moved between data planes without the project's configuration or its URL changing. Choosing which data plane hosts the project is the event that drives that data plane to provision and configure the gateway runtime. **Persona:** Platform operator working in the Admin Dashboard, with a data plane already available to provision on. **Estimated time:** 10 to 20 minutes, plus reconciliation and DNS propagation. ## Outcomes By the end of this guide: - The project is placed on a chosen data plane, and a gateway is auto-provisioned for it with the customer-facing URL applications will call. - By default the project has one gateway; each gateway still serves exactly one project. On Enterprise, additional gateways can optionally be attached later for high availability (see [Optional: attach additional gateways for HA](#optional-attach-additional-gateways-for-ha)). - The gateway has reconciled and reports ready, and its URL is shown on the project. ## Prerequisites - A project that already has its models granted. See [Create a project](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/create-a-project). - At least one data plane deployed and connected to the management plane. See [Deploy and register a data plane](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/deploy-a-data-plane). - Control of the DNS name that will resolve to the data plane ingress, if the endpoint is to be reachable by hostname outside the cluster. ## Step 1: Select a data plane on the project 1. In the Admin Dashboard, open **Projects** and select the project. 1. On the project, select the data plane that should host this project's gateway. 1. Set the customer-facing URL that developers will call, for example `https://bedrock-team.acme.example.com`. Routing is by hostname, so each project's gateway carries its own hostname. Selecting the data plane provisions the **first** gateway automatically. There is no separate create step in a top-level **Gateways** menu for that default path. Additional gateways are attached later only when you configure high availability (see [Optional: attach additional gateways for HA](#optional-attach-additional-gateways-for-ha)). The data plane is shared provisioning capacity: it can provision and manage many gateways at once. Choosing which data plane hosts the gateway is how a project is placed in a particular region or cloud. ## Step 2: Confirm the gateway is ready 1. Watch the gateway's status as the data plane reconciles the desired configuration. 1. Confirm the gateway reports ready and its URL is shown on the project. Once ready, requests sent to the gateway's hostname, authenticated with a key issued for the project, resolve to that project's configuration and nothing else. Cross-project requests are refused: a key from another project returns `403`, and a model the project has not been granted returns `404`. ## Repoint existing clients If applications previously called a single shared endpoint on the data plane and are moving onto project gateways, the change is small and does not require new keys. 1. Keep existing keys: the same key continues to work, so nothing needs to be re-issued. 1. Repoint each application's base URL (or Host) from the shared endpoint to the project's gateway hostname. 1. Confirm the project is wired up: its gateway has a URL, DNS resolves that hostname to the data plane ingress, and the models the application uses are granted to the project. Calling a project's models over the OpenAI-compatible API is covered on the developer side in [Make an API call](/agent-router-service/quickstarts/make-an-api-call). ## Optional: attach additional gateways for HA Most projects run with the single gateway provisioned in Steps 1 and 2. Attaching more members is an **optional** Enterprise high-availability step: it is not required for a working project. :::info Availability Attaching more than one gateway to a project requires an Agent Router Enterprise release that includes multi-gateway projects, and the deployment must declare the Enterprise product line (`DEPLOYMENT_PRODUCT=enterprise`, chart-derived; the gate fails closed). This surface does not exist on Agent Router Service (SaaS). ::: When HA is needed, a project can attach several gateways at once. Every attached gateway receives the identical project configuration by construction — authentication, guardrails, and catalogs cannot diverge between members — which is what makes the members safe failover targets for one another. The full membership model, the health-probe contract, and the DNS failover pattern are covered in [Gateway sets and DNS-level failover](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/gateway-sets-and-dns-failover). ### Attach 1. In the Admin Dashboard, open the project and its **Gateways** tab. 1. Choose **Attach gateway** and select an existing unattached gateway, or provision a new one on a target data plane (provisioning remains the only way a gateway is created). 1. The new member appears with status `syncing` while it converges on the project's configuration. It is promoted to `ready` — and starts answering its membership probe — only once convergence is confirmed, so it cannot receive health-checked traffic half-configured. The **Gateways** tab lists each member with its URL, status, health, configuration version, and last-seen time, so fleet consistency is verifiable at a glance. ### Detach 1. Shift any client traffic away from the member first (via the DNS layer that fronts the members), and verify the drain through request attribution for the member's **data plane**. Attribution is per data plane, not per gateway: the count is only the member's own when no other serving gateway shares its data plane. The full verification procedure, including this caveat, is in the failover guide's runbook. 1. Choose **Detach** on the member's row. The confirmation shows the request count for the member's data plane over the trailing hour — a fixed window, so traffic from before the DNS shift still counts toward it for up to an hour. 1. The member is actively emptied — routes, credentials, and catalogs removed — and lands in a terminal state: `detached — zeroized` (teardown confirmed) or `detached — unreachable` (credentials revoked; verify decommissioning manually). Detach is not delete: the gateway record survives, and the project is untouched. The ordered runbook, with the terminal-state interpretation, is in [Gateway sets and DNS-level failover](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/gateway-sets-and-dns-failover#runbook-detach-a-member-gateway). ### The gateway cap The number of gateways a project can attach is capped — **10 by default, configurable per deployment**. Attaching beyond the cap fails with a clear at-cap error rather than silently queueing; raising the cap is a deployment-configuration change, not a project setting. ### Zero gateways is a valid state A project with no attached gateways remains a fully valid, fully configured project: keys, models, policy, and members are all retained, and the Gateways tab shows a "nothing serving" state. Use it to stage a project's configuration before capacity exists, or to drain a project to zero without tearing anything down. Attaching a gateway later (re)materialises the existing configuration. ## What to do next - **Issue a project-scoped API key**: create the credential developers use against this gateway. See [Issue a project-scoped API key](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/issue-a-project-api-key). - **Grant MCP servers and profiles to a project**: expose tools through the same gateway. See [Grant MCP servers and profiles to a project](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/scope-mcp-to-a-project). - **Gateway sets and DNS-level failover**: optional Enterprise HA — attach additional gateways and fail over with customer-managed DNS. See [Gateway sets and DNS-level failover](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/gateway-sets-and-dns-failover). Where to go next Issue a project-scoped API key Create a key that works only against this project's gateway. Manage multiple gateways on a data plane Review the gateways a single data plane manages after projects select it.