> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Gateway Deployment Strategies
> How to choose a gateway topology in MCP Manager: the building blocks (servers, gateways, teams, roles), the picker versus locked connection URLs, and four strategies — one organization-wide gateway, one per team, one per server, and one per use case — with when each fits and the trade-offs.
There is no single right way to deploy [gateways](/mcp-gateway-concepts/mcp-gateways) in **MCP Manager**. The best setup depends on how your teams work, how many MCP servers you plan to connect, and how much control you want at each layer. This guide walks through the common strategies, when each makes sense, and the trade-offs to watch for. Whichever you choose, the security guarantees are the same — per-user identity (or a shared service account when you choose it), logs that always tie back to a real person, and the ability to enable or disable anything in real time. **The strategy is about packaging and experience, not the level of security you get.**
Creating gateways and assigning servers is part of the **Basic gateway management** capability; making a gateway available to a team uses **Manage team-gateway provisioning**. If you can't create or provision gateways, your role lacks the relevant capability — access depends on the capability, not on any fixed role name. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## First, the building blocks
A quick refresher so the strategies make sense:
* [**MCP servers**](/mcp-gateway-concepts/mcp-servers/overview) are your back of house. Adding a server to MCP Manager does **not** expose it to anyone — it just registers it so you can decide what to do with it.
* [**Gateways**](/mcp-gateway-concepts/mcp-gateways) are your front of house. A gateway packages one or more servers and is the only way users actually connect. This is where you provision which tools are available (see [Feature Governance](/security/feature-governance)) and which [rules](/features/gateway-rules/overview) apply.
* [**Teams**](/deployment/teams) are how you grant access. Assigning a gateway to a team makes it available to everyone on that team, and teams can sync from your identity provider through [SCIM](/enterprise/scim).
* [**Roles**](/deployment/rbac-and-roles/overview) are what a person can *do* with the gateways they have. Roles are independent of teams, so you can give the same gateway to two teams while controlling capabilities separately.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
S1["🖥️
Server A"] --> GW["🛡️
Gateway
(servers + provisioned tools + rules)"]
S2["🖥️
Server B"] --> GW
GW -->|"provisioned to"| T["👥
Team"]
T -->|"membership"| U["👤
Users"]
R["Role"] -.->|"capabilities"| U
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
classDef user fill:#c3c9d4,color:#12141d,stroke:#2c2c37,stroke-width:1.5px;
class GW gateway;
class S1,S2 server;
class T,U user;
```
Most policy in MCP Manager is scoped **per gateway**: each gateway has its own [rules and rule engines](/features/gateway-rules/overview), [tool allowlists](/security/feature-governance), redaction behavior, and [identity schemes](/security/authentication-and-identity), so two gateways can govern the same server differently — which is what lets a topology scope policy per client, team, or tenant. A few settings are instead **organization-wide** regardless of topology, most notably the [log retention period](/features/viewing-logs#how-long-logs-and-exports-stay-available).
## How users connect: two URL modes
Before choosing a topology, know that you control whether a user **picks** a gateway or **lands in** a specific one. The picker URL is the base path; the locked URL appends the gateway ID to it.
**Picker URL (no gateway specified).** The user sees every gateway their team membership grants and chooses one. This pairs naturally with a single company-wide connector: distribute one URL to everyone and let team assignments route people to the right place. If a user's teams map to only one gateway, that is effectively the only option they see.
```text Picker URL theme={null}
https://app.mcpmanager.ai/gateway/v1/mcp
```
**Locked URL (gateway specified).** The connector loads with that specific gateway already selected — no picking step. Hand this to a specific team or workflow so the experience is one click and unambiguous. You can copy a gateway's URL from its overview page at [Gateways](https://app.mcpmanager.ai/settings/gateways).
```text Locked URL theme={null}
https://app.mcpmanager.ai/gateway/v1/mcp/
```
You can mix the two: distribute the picker URL broadly for general use, and hand specific teams a locked URL for their dedicated gateway. Locked URLs you handed out previously in the `?gateway=` query form continue to work, so there's nothing to migrate.
## Strategy 1: One gateway for the whole organization
**What it is.** A single gateway holds every server you want broadly available, and you distribute one connector to the entire company.
**Why pick it.** The simplest possible rollout — one link to communicate, one connector to manage, and users never think about which gateway to use. Modern AI clients trim and discover tools well at runtime, so a large catalog behind one connector is far less of a cost or performance burden than it used to be. A strong default when most of your team needs broadly the same tools, or when you're early in your rollout and want minimal overhead.
**Watch out for.** Everyone behind the gateway shares the same provisioned tool set and the same gateway-level rules. Per-user identity and [roles](/deployment/rbac-and-roles/overview) still scope what each individual can actually do, so it isn't a free-for-all — but if different groups need genuinely different tool subsets or guardrails, you'll eventually want to split them out. Very large tool catalogs can also add context overhead for clients that don't trim well.
## Strategy 2: One gateway per team
**What it is.** A gateway for each department or function (Sales, Legal, Engineering, IT), each containing the servers and tool subsets that group needs, with policies tuned to them.
**Why pick it.** A clean mental model that mirrors your org chart. Each team gets exactly the tools relevant to them and nothing else, reducing context bloat and narrowing the security surface. You can apply different guardrails per team — for example, stricter PII redaction for a group that touches customer data. Hand each team a locked URL so they drop straight into their gateway, and let team membership (synced from your IdP) do the routing as you grow.
**Watch out for.** More gateways to maintain. Cross-team work is a little awkward: someone on two teams either sees two connectors or relies on the picker URL. And if your teams need mostly the same tools anyway, the per-team split is overhead without much payoff.
## Strategy 3: One gateway per MCP server
**What it is.** A one-to-one mapping — each gateway exposes a single MCP server (one for Atlassian, one for Google Workspace, one for Slack, and so on).
**Why pick it.** Maximum isolation and the most granular control. Switch any single integration on or off instantly without touching the others, govern each with its own rules, and reason about each independently. Especially useful during evaluation: stand a new server up in its own gateway, put it through its paces, and decide later. Also a good fit for a small number of high-sensitivity servers you want walled off, and it makes auditing one integration at a time straightforward.
**Watch out for.** The most connectors for end users to manage. If someone needs five servers, that's five connectors and five connections to establish. At scale that's heavier for everyone — so this works best as a **staging and preview** pattern, or for a handful of sensitive servers, rather than the whole-company default.
## Strategy 4: One gateway per use case or work stream
**What it is.** A hybrid. You build a gateway around a workflow or project that cuts across teams, bundling only the servers and tools that workflow needs, regardless of which department people sit in.
**Why pick it.** Some work doesn't follow the org chart. A cross-functional project or a specific agentic workflow may need a curated set of tools drawn from several servers. A use-case gateway delivers exactly that set to exactly the people on that work stream, keeping the toolset tight and purpose-built — which helps both security and agent performance, since the agent only ever sees the tools it actually needs.
**Watch out for.** These can proliferate if every short-lived project spins one up. Reserve the pattern for durable, important workflows rather than every passing effort.
## Quick comparison
| If you want | Use this |
| ------------------------------------------------------------------- | ----------------------------- |
| The simplest rollout, with one link to manage | One organization-wide gateway |
| Tools and policies tailored to each department | One gateway per team |
| Maximum isolation, plus easy evaluation of new or sensitive servers | One gateway per server |
| A curated toolset for a workflow that spans teams | One gateway per use case |
## You are not locked in
Most organizations don't pick one strategy and stop. A very common path is to start simple with a single gateway, then split out per-team or per-use-case gateways as needs diverge. Because access is always governed by the combination of **team, role, and per-user identity**, and because every change takes effect in real time, you can evolve your topology without disrupting people who are already connected.
If you're not sure where to begin, start with **one gateway and the picker URL.** It's the lowest-effort setup, and it's easy to grow from there.
## Further reading
What a gateway is and how it aggregates servers, brokers identity, and applies rules.
How provisioning a gateway to a team grants access, and how access resolves across teams.
How roles control what a person can do with the gateways they can reach.
Provisioning which tools each gateway exposes, per server.
Put a strategy into practice: create a team, build its gateway, and invite someone.