Deployment
The Gateway runs from a single container image in the same shape everywhere: N stateless replicas sharing one Postgres. What changes between deployments is who runs the containers and where the database comes from.
Trying it for the first time? Follow the Quickstart. It brings up the Gateway, a database, and a TLS edge from one downloadable Compose file and two values from your tenant.
Choose Your Deployment
Whichever you pick, read Production as well - it covers the contracts that apply to all of them: the database, encryption at rest, upgrades, and backups.
Downloadable Files
| File | What it is |
|---|---|
| docker-compose.quickstart.yaml | Gateway, Postgres, and a self-signed TLS edge on one host. |
| docker-compose.replicas.yaml | Several replicas behind one edge, against your own database. |
| mcp-gateway-aws.cfn.yaml | CloudFormation template: ALB plus an ECS Fargate service. |
| mcp-gateway-k8s.yaml | Kubernetes manifests: Deployment, Service, Secret, and Ingress. |
There is no configuration file to download. Every setting lives on the gateway pool in your Britive tenant - see Configuration.
What Every Deployment Needs
Regardless of shape, four things are always true.
A Britive tenant and a pool token. The tenant name derives the platform API URL and both OAuth endpoints. The pool token is how the Gateway authenticates its own calls - syncing backends, publishing tools, forwarding audit events. Get it from the Britive admin console.
A Postgres database. The Gateway does not embed one. DATABASE_URL is required
at startup and the container exits with a clear message without it. Postgres 14 or
later. Schema migrations run automatically on every start, so upgrading the image
needs no separate migration step.
A URL that matches how clients reach you. OAuth redirect and resource URLs are
built from the pool’s publicBaseUrl setting, so it must be the address the browser
actually uses. If TLS terminates at a load balancer, that’s the load balancer’s URL -
not the container’s. It is set on the gateway pool in the tenant portal, not on the
container.
TLS. OAuth tokens and checked-out credentials cross the client-to-Gateway connection. Terminate TLS at the Gateway’s edge or at your load balancer; both work, but one of them must happen.
There is no master secret to manage. The key that protects stored tokens and sessions is minted by the platform per gateway pool and arrives with the pool’s settings, so it is automatically identical across replicas and survives every restart. Nothing to generate, distribute, or rotate by hand.
Sizing
The Gateway’s workload is low-QPS and its dataset is small: cached identity and policy answers, stored OAuth tokens, and an audit table. The audit table is the only thing that grows without bound, and retention bounds it.
Start with two replicas for availability rather than for throughput. Add more when your own metrics say to, not in anticipation.