mcpgate vs Docker MCP Gateway
These two solve different problems despite sharing the words “MCP gateway”. Docker’s tool is a Docker-CLI plugin that puts isolated MCP servers in front of one developer’s AI client. mcpgate is a team-production gateway that puts central policy, audit, PII handling, and SSO between many users and their company’s tool APIs. Both are useful. They’re mostly not in each other’s way.
Last reviewed: . We maintain mcpgate. Spot something off? We’ll fix it.
The 30-second verdict
Pick Docker MCP Gateway if…
- You’re a developer who wants isolated MCP servers running locally, managed by a single CLI.
- You already live in Docker Desktop and want the MCP Toolkit to Just Work.
- You need a curated catalog of 200+ MCP servers ready to pull and run.
- Container isolation is the security model you trust.
- You don’t need multi-user OAuth/SSO — one developer, one machine.
Pick mcpgate if…
- You have a team (5, 50, 500 people) connecting AI agents to the same set of company tools.
- PII handling matters — mcpgate pseudonymizes outbound, rehydrates on the way back.
- You need OIDC SSO so users sign in once and the gateway propagates identity.
- You want per-user policy hooks alongside operator-level rules.
- The deployment story is “a service we run, like our other backend services”, not “each dev runs it locally”.
Many teams will use both. A developer experimenting with new MCP servers locally via Docker MCPG; the same team running mcpgate in production for everyone’s daily AI workflow. They’re not direct substitutes.
Where each one sits
You can run both
Of all the comparisons on this site, Docker MCP Gateway is the one where “competition” is the wrong frame. Docker MCPG is the developer-workstation half of the stack: pull MCP servers from the Docker Hub catalog, run them in isolated containers, route a single dev’s Claude Desktop / Cursor / Windsurf to them. mcpgate is the team-production half: a hosted gateway behind OIDC SSO, with PII handling, audit, per-user policy hooks, and 22 deep integrations.
A realistic team probably uses both:
- Locally — developers use Docker MCPG to experiment with new MCP servers, sandbox third-party tools in containers, prototype new integrations without touching team infrastructure.
- In production — the team gateway runs mcpgate, with the integrations actually used in daily work, behind central authentication and audit.
Building “mcpgate-equivalent on top of Docker MCPG” isn’t really the architectural question — Docker MCPG isn’t a platform you compose other things onto; it’s a CLI plugin for local container management. The question is whether you want one piece for both jobs (you probably don’t — they’re different jobs) or the right tool for each.
Side by side
| mcpgate | Docker MCP Gateway | |
|---|---|---|
| License | BSL 1.1 (source-available; converts to Apache 2.0 after 3 years) | MIT (OSI-approved open source) |
| Maturity | Public since March 2026. Early stage — community signals catching up. | Established Docker org project. ~1,392 stars / ~244 forks (verified 2026-05-17). |
| Primary form factor | Standalone HTTP service (container) | Docker CLI plugin (docker mcp) + standalone binary |
| Primary audience | Teams in production | Developers, dev workstations, AI-IDE setups |
| Deployment | Docker Compose, Kubernetes-deployable. Hosted by the operator, used by many users via HTTP/SSE. | Runs on Docker Desktop 4.59+ or Docker CE. Local-first; the gateway proxies MCP traffic from one machine. |
| SSO / multi-user identity | OIDC SSO for any IdP (Google, Microsoft, Okta, Keycloak, …). Each user has their own OAuth tokens for downstream services. | No multi-user SSO model. Secrets stored in Docker Desktop secrets store, scoped to the local dev environment. |
| PII pseudonymization with rehydration | Built in. Sensitive fields are pseudonymized outbound; mapping is on-prem, encrypted, 24h TTL; values are rehydrated when the agent calls back into the source system. | Not in scope. Security model is container isolation, not data sanitization. |
| Policy hooks | Two layers: company-wide (operator) + per-user (each user defines their own from their AI client). YAML, hot-reloaded. | Profile-based tool allowlists / denylists in dot notation (e.g. github.create_issue). No per-user runtime hooks. |
| Service integrations / catalog | 22 services pre-configured with hand-written native YAML (Jira, GitLab, GitHub, Notion, Confluence, Slack, M365, GWS, Grafana, Sentry, …). Plus OpenAPI import for any REST API, plus any MCP server reachable via URL — anything not built-in, you add yourself in YAML, no code. | Catalog of 200+ MCP servers via Docker Hub (mcp/docker-mcp-catalog). OCI-image-based — every server is a container. |
| Auth flows supported | OAuth 2.1, DCR, PKCE, static-bearer, API-key, no-auth — unified handler. | Built-in OAuth flows per integrated server; depends on what each MCP server in the catalog supports. |
| Audit log | Yes (admin-gated, tamper-evident hashing). Captures who-did-what-when across all users. | Standard Docker logs of the gateway and MCP server containers. No unified audit surface across users. |
| Sandboxing / isolation | Service-level: each YAML extension is loaded into the gateway process. Outbound calls are scoped via the per-user OAuth token. | Per-server: each MCP server runs in its own container, with minimal host privileges. Isolation is the first-line defense. |
| Managed cloud option | No (self-host only). | No (self-host only). Docker Desktop is the closest thing to a managed local experience. |
The case for Docker MCP Gateway
The CLI plugin paradigm. Docker MCPG hooks into docker mcp directly. If your team already uses Docker Desktop or Docker CE day-to-day, adding an MCP gateway is one CLI install away. mcpgate is a separate service that needs to be deployed, networked, and operated. For a single developer running Claude Desktop locally, that’s overkill.
The catalog. Docker MCPG composes from a published catalog of 200+ MCP servers, distributed as OCI images via Docker Hub. The composability is the point: you don’t configure integrations one-by-one in a wizard; you pull pre-built MCP servers from the catalog and the gateway routes between them. mcpgate’s 22 pre-configured services are deeper per-service but the menu is much shorter.
Container isolation as security. Each MCP server runs as its own container with limited host privileges. That’s a strong story for “I don’t fully trust this third-party MCP server but I want to try it” situations. mcpgate’s YAML services run in-process — different threat model.
Track record. Docker MCPG is the older project — 1,392 stars / 244 forks (verified 2026-05-17 via the GitHub API), maintained inside the Docker org. mcpgate is early stage (public since March 2026). For evaluators whose checklist includes “has been in the open long enough that issues are visible”, Docker MCPG has the head start. That gap is stage-of-life, not product-quality — but stage-of-life is real.
The case for mcpgate
Multi-user identity. Docker MCPG’s security model is “this is my dev machine, my secrets, my containers”. There’s no model for “30 teammates each authenticating through SSO and reaching downstream APIs with their own OAuth tokens”. mcpgate is built around exactly that — OIDC SSO with any IdP, per-user OAuth tokens per service, audit log that captures who-did-what-when.
PII handling for production data. If your daily AI workflow touches real customer names, employee emails, support tickets with people’s identities — Docker MCPG doesn’t sanitize that. The container isolation is about untrusted MCP servers, not about preventing PII from reaching the LLM. mcpgate’s pseudonymization layer pseudonymizes outbound and rehydrates inbound; the LLM provider literally never sees the real names.
Policy that meets users where they are. Docker MCPG’s allowlist model is operator-defined and profile-bound. mcpgate adds a second layer: each end-user can write their own policy hooks (YAML, hot-reloaded) from their AI client. Practical example: a PM defines “always assign Jira tickets to me, default project = PRODUCT” without the operator’s involvement.
Deep per-service integrations. mcpgate’s 22 services aren’t generic MCP wrappers — each one has hand-written YAML covering the actions teams actually use (Jira ADF conversion, Slack channel resolution, Confluence storage-format handling, …). When you pull a generic MCP server from a catalog, you get the surface that server’s author chose, which is often thinner.
Tradeoffs
- License. BSL 1.1 is source-available, not OSI-approved open source. Docker MCPG is MIT. If your org will only adopt OSI-OSS, Docker MCPG fits and mcpgate doesn’t.
- Stage of life. Docker MCPG: 1,392 stars / 244 forks (verified 2026-05-17), active commit cadence inside the Docker org. mcpgate: public since March 2026 The external-validation surface — stars, third-party citations, talked-to references — naturally has to catch up. That’s a real consideration for evaluators who pattern-match on adoption signals; it’s not a product-quality statement.
- Catalog defaults. Docker MCPG starts you with a 200+ MCP-server catalog pulled from Docker Hub. mcpgate starts you with 22 deeply integrated services + an OpenAPI / MCP-server-URL import path for anything else. The reachable surface ends up similar; the defaults are different. If “pull a new server, run it” describes your workflow more than “configure deep actions once for the tools we use daily”, Docker MCPG is the closer fit.
- Container-level isolation. We don’t sandbox each YAML service in its own container. For high-trust internal-only setups this isn’t the dominant threat model — but if you’re running third-party MCP servers you’d rather not fully trust, Docker MCPG’s isolation is more defense-in-depth.