Docker MCP Gateway: Setup, Security & Best Practices
TL;DR
Docker MCP Gateway is an open-source project that lets you run MCP servers inside Docker containers, providing process isolation and a catalog-based discovery system for AI agents. It simplifies setup but does not solve permission-level security -- for granular per-agent scope control, you need a dedicated MCP proxy like ScopeGate on top.
What Is Docker MCP Gateway?
Docker MCP Gateway is an open-source tool from Docker that allows you to run Model Context Protocol (MCP) servers inside Docker containers and expose them to AI agents through a unified gateway interface. Instead of manually installing and configuring each MCP server on your host machine, Docker MCP Gateway packages every server as a container image, manages its lifecycle, and provides a single entry point for agents to discover and invoke tools.
The project builds on Docker Desktop and integrates with the MCP Toolkit CLI, giving developers a familiar container-based workflow for managing AI tool infrastructure. When an AI agent connects to a Docker MCP Gateway, it sees a consolidated catalog of all available tools across every running container. The gateway handles routing each tool call to the correct container, passing parameters, and returning results.
Docker MCP Gateway is part of Docker's broader push into the AI development toolchain. It is free to use, open-source, and designed to work alongside existing Docker workflows. If you already use Docker Compose to orchestrate services, adding MCP servers to your stack feels natural. But as we will discuss throughout this guide, container isolation and permission-level security are fundamentally different problems -- and Docker MCP Gateway addresses only the first.
How Docker MCP Gateway Works: Architecture Overview
The architecture of Docker MCP Gateway follows a hub-and-spoke pattern. At the center sits the gateway process, which exposes a single MCP-compatible endpoint. Surrounding it are individual Docker containers, each running one MCP server -- for example, a GitHub server, a PostgreSQL server, or a filesystem server.
When an AI agent connects to the Docker MCP Gateway endpoint, the gateway aggregates the tool listings from every running container and presents them as a unified catalog. The agent sees all available tools in one response, regardless of which container provides them. When the agent invokes a tool, the gateway routes the JSON-RPC call to the appropriate container, waits for the response, and streams it back to the agent.
Credential management is handled through Docker secrets and environment variables. Each container receives only the credentials it needs -- a GitHub token for the GitHub MCP server, a database connection string for the PostgreSQL server, and so on. This is a meaningful improvement over running MCP servers directly on the host, where credentials often live in plaintext configuration files accessible to every process.
The MCP Toolkit CLI provides commands to manage the lifecycle: adding servers from a registry, starting and stopping containers, inspecting logs, and updating images. Docker Desktop users get a graphical interface for the same operations.
This architecture provides process-level isolation. If an MCP server is compromised -- say, through a malicious tool description or a dependency vulnerability -- the blast radius is limited to that container. The attacker cannot trivially pivot to other MCP servers or the host. However, it is important to understand that this is infrastructure isolation, not authorization. The Docker MCP Gateway does not enforce which agents can call which tools, what parameters are allowed, or which data can be accessed within a tool's scope.
Setting Up Docker MCP Gateway: Step-by-Step Guide
Getting started with Docker MCP Gateway requires Docker Desktop 4.40 or later. Here is a step-by-step walkthrough.
First, ensure Docker Desktop is installed and running. You can verify your version with
docker --version. If you need to update, download the latest release from the Docker website.
Next, enable the MCP Toolkit extension. Open Docker Desktop, navigate to the Extensions Marketplace, and search for MCP Toolkit. Click Install. Alternatively, use the CLI: docker extension install docker/mcp-toolkit.
Once the extension is installed, you can add your first MCP server. The MCP Toolkit maintains a catalog of pre-built server images. To add the filesystem MCP server, run: docker mcp server add filesystem. This pulls the container image and registers it with the gateway.
To configure the server, create a configuration file. For the filesystem server, you need to specify which directories to expose. Create a file at ~/.docker/mcp/servers/filesystem.json with content specifying args and volumes. Use the :ro flag to mount directories as read-only inside the container, which is a basic but important security measure.
Start the gateway with docker mcp gateway start. This boots all configured MCP server containers and starts the gateway process. The gateway listens on a local endpoint, typically http://localhost:8811/mcp. You can verify it is running with docker mcp gateway status.
To connect an AI agent, point it at the gateway URL. For Claude Desktop, add the gateway endpoint to your claude_desktop_config.json under the MCP servers section. For Cursor or other editors, configure the MCP endpoint in the settings panel.
Adding more servers follows the same pattern. For example, to add a GitHub MCP server: docker mcp server add github. Then configure its credentials: docker mcp server configure github --env GITHUB_TOKEN=ghp_your_token_here. The token is stored as a Docker secret, not in plaintext.
To see all running servers and their tool catalogs, run docker mcp server list. To inspect the tools exposed by a specific server: docker mcp server tools github. And to view real-time logs: docker mcp server logs github --follow.Key Features of Docker MCP Gateway
Docker MCP Gateway offers several features that make it appealing for local development and small-team deployments.
The MCP Toolkit catalog is a curated registry of pre-built MCP server images. Rather than building and maintaining your own containers, you can pull production-ready images for popular services -- GitHub, Slack, PostgreSQL, filesystem, web search, and dozens more. Each image is versioned and tested against the current MCP specification.
Container isolation is the headline feature. Every MCP server runs in its own container with its own filesystem, network namespace, and process tree. A vulnerability in one server cannot directly compromise another. This is a significant step up from running MCP servers as bare processes on your host, where a single compromised server could access everything.
Credential management through Docker secrets and scoped environment variables ensures that each container receives only the tokens and keys it needs. The GitHub server never sees your database password, and the filesystem server never sees your API keys.
The unified tool catalog aggregates tools from all running containers into a single discovery response. Agents do not need to know which server provides which tool -- they connect to one endpoint and see everything. This simplifies agent configuration and reduces the number of MCP endpoints you need to manage.
Docker Compose integration means you can define your entire MCP server stack in a
docker-compose.yml file, version it alongside your application code, and spin up identical environments on any machine with a single docker compose up command.
Log aggregation through docker mcp server logs gives you a single pane of glass for troubleshooting. You can tail logs from all servers simultaneously or filter by server name, log level, or time range.Security Considerations: What Docker MCP Gateway Does and Does Not Protect
Docker MCP Gateway provides meaningful infrastructure-level security, but it is critical to understand its boundaries.
Containers are not sandboxes. Docker containers share the host kernel, and container escape vulnerabilities -- while rare -- are a known attack surface. If your threat model includes sophisticated attackers targeting the container runtime, you need additional hardening: rootless containers, seccomp profiles, AppArmor or SELinux policies, and regular kernel patching.
Prompt injection is still possible. When an AI agent discovers tools through the Docker MCP Gateway, it receives tool descriptions and parameter schemas from each MCP server. A malicious or compromised MCP server can embed prompt injection payloads in these descriptions, potentially hijacking the agent's behavior. The gateway does not inspect or sanitize tool descriptions -- it forwards them as-is from the container.
There are no per-agent permissions. This is the most significant security gap in Docker MCP Gateway. Every agent that connects to the gateway sees the same catalog of tools and has the same level of access. You cannot restrict Agent A to read-only filesystem operations while allowing Agent B to write files. You cannot prevent a code assistant from invoking email-sending tools. The gateway treats all connected agents as equally trusted.
There is no cross-service permission dashboard. If you run ten MCP servers behind Docker MCP Gateway, there is no central place to define policies like "this agent can read GitHub issues but not merge pull requests" or "this agent can query the database but not modify rows."
Audit trails are limited to Docker container logs. You can see that a tool was called and what parameters were passed, but there is no structured audit log with agent identity, session correlation, or compliance-ready formatting. For SOC 2 or ISO 27001 environments, this is insufficient.
Network security requires manual configuration. By default, Docker MCP Gateway listens on localhost only, which is secure for single-machine setups. But if you expose it on a network interface, you need to add TLS termination, authentication middleware, and firewall rules yourself.
Limitations of Docker MCP Gateway
Beyond the security considerations above, Docker MCP Gateway has several practical limitations that affect production readiness.
No granular per-agent scope control means you cannot implement least-privilege access for individual AI agents. In a real-world deployment, you might have a coding assistant, a customer support bot, and an analytics agent -- each should only see the tools relevant to its function and operate within strict permission boundaries. Docker MCP Gateway cannot enforce this.
No cross-service permission dashboard means there is no unified view of who can access what across all your MCP servers. As your MCP server count grows, managing permissions becomes an exercise in tracking individual Docker environment variables and service credentials across multiple configuration files.
No built-in audit trail dashboard means compliance teams cannot easily review agent activity, investigate incidents, or generate access reports. Container logs are a starting point, but they lack the structure, searchability, and retention policies required for enterprise compliance.
Scaling beyond a single machine is not natively supported. Docker MCP Gateway is designed for local and single-host deployments. If you need to distribute MCP servers across multiple machines, handle failover, or load-balance agent connections, you need additional infrastructure.
No multi-tenant support means all agents share the same gateway instance and credential set. In SaaS or platform scenarios where different customers or teams need isolated MCP environments with separate credentials and permissions, Docker MCP Gateway does not offer tenant-level separation.
Docker Desktop licensing: while Docker MCP Gateway itself is open-source, Docker Desktop requires a paid subscription for commercial use in organizations with more than 250 employees or $10 million in annual revenue.
Docker MCP Gateway vs Permission-Focused MCP Proxies
Docker MCP Gateway and permission-focused MCP proxies like ScopeGate solve different problems and work well together.
Docker MCP Gateway excels at infrastructure concerns: running MCP servers in isolated containers, managing credentials via Docker secrets, and providing a catalog of vetted server images. It answers the question: "How do I run MCP servers reliably and with basic isolation?"
A permission-focused MCP proxy excels at access control: defining per-agent, per-service, per-scope permissions, maintaining structured audit trails, enabling instant revocation, and providing a visual dashboard for managing agent access. It answers the question: "What is each agent allowed to do, and how do I prove it?"
For production deployments, the ideal architecture layers both. Docker MCP Gateway provides the infrastructure layer -- running MCP servers in containers with credential management. An MCP proxy like ScopeGate sits in front, providing the policy layer -- per-agent permissions, audit trails, and revocation. The agent connects to ScopeGate, which enforces policies and routes approved requests to Docker MCP Gateway, which routes them to the appropriate container.
This layered approach gives you infrastructure isolation (Docker) plus application-level permission control (ScopeGate) -- defense in depth for AI agent access.
Alternatives to Docker MCP Gateway
Several alternatives address different aspects of the MCP gateway and MCP proxy problem space. The right choice depends on whether you need infrastructure isolation, permission control, or both.
ScopeGate is a purpose-built MCP proxy that focuses on the permission layer. Users connect external services, define granular permissions -- down to individual tool calls and parameter constraints -- and receive a single MCP endpoint URL for each agent. ScopeGate handles authentication, token management, and audit logging as core features. Best for: developers and teams who need permission control, not just infrastructure isolation.
Traefik Hub is an API gateway that can be configured as an MCP proxy with middleware. It offers strong networking features -- TLS termination, load balancing, circuit breaking -- and has added Task-Based Access Control (TBAC) for MCP. Best for: enterprise teams already running Traefik.
Gravitee is an API management platform with MCP proxy capabilities. It provides protocol-level governance, per-method ACLs, and analytics. Best for: enterprise API management teams.
MetaMCP is an open-source MCP aggregator and gateway. Server aggregation, namespace grouping, rate limiting, OIDC auth. Best for: self-hosted enthusiasts who want full control.
LiteLLM Proxy is an open-core AI gateway with MCP permission management. Access groups, tool-level filtering, cost tracking across 100+ LLM providers. Best for: teams that also need an LLM proxy.
Microsoft MCP Gateway is a Kubernetes-native MCP reverse proxy with Entra ID authentication and role-based authorization. Best for: enterprise Kubernetes teams in the Microsoft ecosystem.
For most teams, the practical architecture is Docker MCP Gateway for container isolation combined with a dedicated MCP proxy like ScopeGate for permission control. This separation of concerns mirrors how the industry handles API security: you would not rely solely on Docker networking to enforce API permissions, and the same principle applies to MCP.
Best Practices for Production Docker MCP Gateway Deployments
If you deploy Docker MCP Gateway beyond local development, follow these practices to harden your setup.
Run containers as non-root users. Override the default with
--user 1000:1000 in your Docker run command or set user: "1000:1000" in your docker-compose.yml. This limits damage if an attacker gains code execution inside a container.
Mount volumes as read-only whenever possible. If an MCP server only needs to read files, mount with the :ro flag. Write access should be granted only when the tool's function explicitly requires it.
Use Docker secrets instead of environment variables for sensitive credentials. Docker secrets make credentials available as files inside the container rather than environment variables, which can leak through process listings and debug endpoints.
Enable resource limits on every container. Set --memory=512m and --cpus=0.5 to prevent a misbehaving MCP server from consuming all host resources.
Restrict network access with Docker network policies. Create isolated Docker networks for your MCP servers: docker network create --internal mcp-internal. This prevents a compromised MCP server from exfiltrating data to external endpoints.
Pin container image versions. Do not use latest tags in production. Pin to specific digests to prevent supply chain attacks where a malicious image is pushed under an existing tag.
Add a TLS-terminating reverse proxy in front of the Docker MCP Gateway if you expose it beyond localhost. Use Nginx, Caddy, or Traefik to handle TLS certificates.
Layer a permission proxy on top. Deploy ScopeGate or an equivalent MCP proxy between your agents and the Docker MCP Gateway to add authorization, audit logging, and per-agent scope control. This is the single most impactful security improvement you can make to a Docker MCP Gateway deployment.Conclusion: When Docker MCP Gateway Is (and Isn't) Enough
Docker MCP Gateway is a solid, free, open-source tool for running MCP servers with container-level isolation and credential management. It is the right choice for personal projects, development environments, and teams that need basic MCP infrastructure without complex setup.
However, Docker MCP Gateway is not a complete security solution for AI agent access. It lacks per-agent permission control, structured audit trails, cross-service revocation, and the compliance features that production deployments and regulated industries require.
For teams that need to answer "what can each agent access, and can we prove it?", a permission-focused MCP proxy is essential -- either on its own or layered on top of Docker MCP Gateway for defense in depth.
The MCP gateway category is still early, and the right architecture depends on your scale, security requirements, and compliance obligations. Start with Docker MCP Gateway for infrastructure isolation, add a permission layer as your agent fleet grows, and invest in audit trails before your compliance deadline arrives.
Frequently Asked Questions
Is Docker MCP Gateway free?
Yes, Docker MCP Gateway is free and open-source. It is included with Docker Desktop and can be used without any paid subscription. However, Docker Desktop itself requires a paid subscription for commercial use in organizations with more than 250 employees or more than $10 million in annual revenue.
How do I install Docker MCP Gateway?
Install Docker Desktop 4.40 or later, then enable the MCP Toolkit extension from the Extensions Marketplace or run docker extension install docker/mcp-toolkit. Use docker mcp server add <name> to install MCP servers and docker mcp gateway start to launch the gateway.
Docker MCP Gateway vs Traefik: which should I use?
Docker MCP Gateway is purpose-built for MCP servers -- it understands the MCP protocol, aggregates tool catalogs, and manages container lifecycles. Traefik is a general-purpose reverse proxy that can route MCP traffic but requires custom middleware for MCP awareness. Use Docker MCP Gateway for turnkey MCP server management; use Traefik when you already run it as your primary ingress.
How do I secure MCP servers with Docker?
Run each MCP server in its own container for process isolation. Mount volumes as read-only where possible. Use Docker secrets for credentials. Run containers as non-root users. Set memory and CPU limits. Restrict network access with internal Docker networks. Pin image versions. And add a permission proxy like ScopeGate in front for per-agent access control, which Docker alone does not provide.
Can Docker MCP Gateway restrict which tools an agent can access?
No. Docker MCP Gateway exposes all tools from all running containers to every connected agent. It does not support per-agent permissions, tool-level access control, or parameter constraints. For granular permission control, you need a dedicated MCP proxy like ScopeGate in front of the gateway.
Can Docker MCP Gateway prevent prompt injection?
No. Docker MCP Gateway provides container-level isolation, which prevents MCP servers from accessing each other's data. However, it cannot detect or prevent prompt injection attacks that trick an agent into making authorized-but-unintended tool calls. Prompt injection defense requires agent-level guardrails, not infrastructure-level isolation.
Should I use Docker MCP Gateway or ScopeGate?
They solve different problems and work well together. Docker MCP Gateway provides infrastructure isolation (containers, credential storage, server catalog). ScopeGate provides permission management (per-agent scope control, audit trails, instant revocation). For production, layer ScopeGate in front of Docker MCP Gateway for defense in depth. For personal projects, Docker MCP Gateway alone is often sufficient.
How ScopeGate Helps
Docker MCP Gateway gives you container isolation for MCP servers, but it cannot control what each AI agent is allowed to do. ScopeGate adds the missing permission layer: define per-agent scopes down to individual tools and parameters, get a structured audit trail for every tool call, and revoke access instantly without touching your Docker infrastructure. Free tier available.
View on GitHub