Setting up Docker MCP Gateway

What the Docker MCP Gateway is and why it matters

The Docker MCP Gateway is, according to the vendor, Docker's open-source solution for centrally running and managing multiple Model Context Protocol (MCP) servers. MCP is an open protocol that lets AI applications such as Claude Desktop, Claude Code, Cursor, or VS Code access external tools, data sources, and APIs in a structured way. Without a gateway, every single client application has to know on its own how and where to start an MCP server, which credentials it needs, and how to secure it. The Gateway centralizes that job: according to Docker, it acts as a proxy between clients and servers, handling configuration, credentials, and access control, and automatically starting the actual MCP servers as isolated Docker containers when needed. This is particularly relevant for teams running several AI tools in parallel who don't want to maintain a separate, potentially insecure server configuration for each application. Technically, the project consists of the docker-mcp CLI plugin, which either runs embedded in Docker Desktop with the MCP Toolkit enabled, or standalone on Docker Engine without a desktop UI, for example under WSL2 or in containerized environments.

Prerequisites

For the simplest path, Docker states that Docker Desktop version 4.59 or later with the MCP Toolkit enabled is required; in that case the Gateway runs automatically in the background and doesn't need to be started manually. Anyone wanting to run the Gateway without Docker Desktop, for instance on a server running Docker Engine, needs the CLI plugin installed separately. Building from source additionally requires Go version 1.24 or later. To operate it at all, a working Docker installation is sufficient, since the MCP servers run as separate containers with restricted privileges. It's also important to have a clear picture of which MCP servers from the Docker MCP Catalog are actually needed, because every additional server adds attack surface and resource consumption.

Step-by-step setup

Docker Desktop users first enable the MCP Toolkit in settings and configure the desired servers from the catalog there; the Gateway then runs implicitly in the background. For standalone operation, the documentation describes downloading the current binary from the GitHub releases page and moving it to the OS-appropriate location for CLI plugins — on Linux and macOS, for example, to ~/.docker/cli-plugins/docker-mcp, and on Windows to the corresponding folder in the user profile. After setting execute permissions, the docker mcp --help command can be run to verify the installation. Servers are then organized into so-called profiles, which are reusable collections of MCP servers that can come from the Docker MCP Catalog, custom OCI images, the public MCP registry, or local files. A profile is created with the docker mcp profile create command and then connected to a client such as Claude Code or VS Code. In environments without Docker Desktop, such as plain Docker CE, the vendor notes that the profiles feature must first be explicitly enabled with docker mcp feature enable profiles.

Security and best practices

The Gateway's central security concept is isolation: each MCP server runs in its own container with restricted privileges, restricted network access, and limited resource usage, rather than running directly on the host system with the calling user's permissions. This reduces the risk that a compromised or buggy server can reach the rest of the system. According to the vendor, credentials such as API keys are handled through Docker Desktop's secrets management rather than stored as plaintext environment variables, which lowers the risk of accidental leaks into logs or version control. The Gateway also provides built-in logging and call tracing, so it's possible to review afterward which tool was called when and with what data. Anyone running the Gateway in production should still only allow servers from trusted sources in their profile and regularly review what permissions individual servers actually request, since MCP servers can in principle gain access to sensitive data and systems.

Practical example and limitations

A typical scenario is a development team that wants to reach GitHub, a database, and an internal search server simultaneously from several different AI clients. Instead of configuring each application separately, a shared profile containing all three servers is created and connected to every client, producing consistency and central control. It's worth noting that, according to Docker's own documentation, certain advanced features of the Gateway are currently part of what's called Docker AI Governance and are invite-only, while the core of the CLI plugin remains openly available. The Gateway also does not replace scrutiny of individual MCP servers' actual behavior: isolation protects against system-level access, but not against a server itself returning incorrect or unwanted results. Anyone using MCP servers in production should therefore still critically review the data returned by individual servers before feeding it into automated workflows.