Provision a gateway for a project
A gateway is a single inference endpoint, one customer-facing URL, provisioned by a data plane and mapped to exactly one project. Provisioning and binding a gateway is the step that turns a project from configuration into something applications can call. This guide creates the gateway, binds the project to it, and confirms it is ready.
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. Binding a project to a gateway is the event that drives the data plane to configure the runtime.
Persona: Platform operator working in the Admin Dashboard, with a data plane already available to provision on.
Estimated time: 10--20 minutes, plus reconciliation and DNS propagation.
Outcomes
By the end of this guide:
- A gateway exists on a chosen data plane, with the customer-facing URL applications will call.
- The project is bound to the gateway (one gateway serves exactly one project).
- The gateway has reconciled and reports ready, and its URL is shown on the project.
Prerequisites
- A project that already has its providers and models granted. See Create a project and grant models.
- At least one data plane deployed and connected to the management plane. See Deploy and register 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: Provision a gateway on a data plane
- In the Admin Dashboard, open Gateways and create a gateway on the target data plane.
- 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.
The data plane is shared provisioning capacity: it can provision and manage many gateways at once, one per project. Choosing which data plane hosts the gateway is how a project is placed in a particular region or cloud.
Step 2: Bind the project to the gateway
- Attach the project to the gateway. A gateway serves exactly one project, and a project maps to exactly one gateway.
This mapping is the control-plane event that makes the assigned data plane provision and configure the gateway's runtime. Until a project is bound, the gateway has no configuration to serve; until a gateway is bound, the project has access rules but nowhere to send traffic.
Step 3: Confirm the gateway is ready
- Watch the gateway's status as the data plane reconciles the desired configuration.
- 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.
- Keep existing keys: the same key continues to work, so nothing needs to be re-issued.
- Repoint each application's base URL (or Host) from the shared endpoint to the project's gateway hostname.
- 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.
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.
- Grant MCP servers and profiles to a project: expose tools through the same gateway. See Grant MCP servers and profiles to a project.
Where to go next