# Docker MCP Gateway vs a managed MCP platform

> Docker MCP Gateway vs a managed MCP platform: Docker runs MCP servers in containers you operate. Elaichi serves connectors behind one sign-in URL.

**TL;DR** Docker's MCP Gateway runs open-source MCP servers as containers on a machine you operate, which suits developers who want local tools with strong isolation. Elaichi is a managed MCP platform: it serves the connectors from its own infrastructure behind one organization-wide URL, and each employee signs in with their own OAuth grant. For a company rollout to support, finance and sales, Elaichi adds roles, restrictions, frozen parameters, one audit log and next-call offboarding. You can run both, split by audience.

## Docker MCP Gateway vs a managed MCP platform: which fits a whole company?

Docker MCP Gateway vs a managed MCP platform comes down to who runs the servers. Docker's gateway runs MCP servers as containers on a machine you operate, usually a developer's laptop. A managed MCP platform such as Elaichi serves the connectors itself, so staff in support, finance and sales connect an AI client and sign in.

The request usually starts in engineering. A few developers switched on Docker's MCP Toolkit and gave Cursor a GitHub tool. It worked, so IT is asked whether the same setup can serve the whole company. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The answer turns on whether the people asking can run containers, and whether you need one record of every call.

## What is Docker's MCP Gateway, in Docker's own words?

It is an open source proxy that starts MCP servers in containers and routes client requests to them. Docker's [MCP Gateway page](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) (checked October 2026) describes it as a centralized proxy that manages configuration, credentials and access control.

Three parts work together, per Docker's [MCP Catalog and Toolkit overview](https://docs.docker.com/ai/mcp-catalog-and-toolkit/) (checked October 2026). The MCP Catalog lists 300+ verified servers packaged as container images. The MCP Toolkit is the Docker Desktop interface for adding servers and connecting clients. Underneath, the gateway starts a server's container when a tool is called, injects credentials and forwards the request.

The code is MIT-licensed in the [docker/mcp-gateway repository](https://github.com/docker/mcp-gateway). Docker's [profiles page](https://docs.docker.com/ai/mcp-catalog-and-toolkit/profiles/) marks profiles as Early Access on Docker Desktop 4.63 or later, and the Toolkit and Catalog as Beta (both checked October 2026).

## Where does Docker's gateway run, and who keeps it running?

It runs wherever Docker runs, and someone on your side operates it. With the MCP Toolkit enabled, it runs in the background in Docker Desktop. On Docker Engine alone, you install the binary yourself ([MCP Gateway docs](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/), checked October 2026).

The default transport is stdio, which is local to the client that launched the gateway. Docker's [gateway guide on GitHub](https://github.com/docker/mcp-gateway/blob/main/docs/mcp-gateway.md) also shows it under Docker Compose, serving several clients over HTTP on any Docker engine. Per Docker's [security model](https://github.com/docker/mcp-gateway/blob/main/docs/security.md), those HTTP requests need a Bearer token by default, set in an environment variable or generated (both checked October 2026).

So a company gets two shapes: a gateway on each laptop, or a shared one on a server. The first means one configuration per machine. The second means one token that every client presents.

## How does Docker's gateway handle secrets and OAuth?

Credentials stay with the Docker installation that runs the gateway. API keys go into Docker Desktop's secrets store, or a local `.env` file as a fallback. Docker's [security model](https://github.com/docker/mcp-gateway/blob/main/docs/security.md) says each server receives only the secrets it declares (checked October 2026).

For apps such as GitHub and Notion, the [MCP Toolkit](https://docs.docker.com/ai/mcp-catalog-and-toolkit/toolkit/) runs OAuth in the browser. It lists authorized services in an OAuth tab, where each one can be revoked. Docker's [profiles page](https://docs.docker.com/ai/mcp-catalog-and-toolkit/profiles/) adds two details that matter for a rollout (both checked October 2026). OAuth credentials are shared across all profiles, so a second account means revoking and authorizing again. And a pushed profile carries no credentials, so each teammate configures OAuth after pulling it.

So each person authorizes each service in their own Docker installation, on whichever machine they use.

## What do profiles, tool filters and call logs give an admin?

They give a developer, or a team sharing a profile, control over which tools are offered. A profile is a named set of servers whose Tools tab can switch single tools on or off. Teammates can pull a profile from an OCI registry ([MCP Profiles](https://docs.docker.com/ai/mcp-catalog-and-toolkit/profiles/), checked October 2026).

A custom catalog narrows Docker's list to approved servers and can add private ones ([MCP Catalog](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/), checked October 2026). Per the [MCP Toolkit page](https://docs.docker.com/ai/mcp-catalog-and-toolkit/toolkit/), each tool runs in its own container, capped at 1 CPU and 2 GB of memory, with no host files unless the user grants a mount.

Call logging and secret blocking are on by default. Per Docker's [security model](https://github.com/docker/mcp-gateway/blob/main/docs/security.md), the call log holds the tool name and the shape of its arguments, never raw values. Docker's [gateway page](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) also says the gateway as part of Docker AI Governance is invite-only, through Docker Sales (all checked October 2026). Ask Docker what it adds.

## What does a company-wide rollout to non-engineers need?

It needs one address, a personal sign-in, nothing to run, and rules an admin sets once. Here is how Elaichi meets each need for Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent.

- **One URL per organization.** Every client connects to `https://api.elaichi.ai/mcp`, standard MCP over Streamable HTTP. The client registers itself through OAuth, so nobody types a client ID, secret or token.
- **A personal sign-in.** Each member connects once and signs in with their own OAuth grant, an access approval that belongs to that person.
- **Connectors, not containers.** Elaichi authors, maintains and serves 500+ connectors from its own infrastructure. A separate credential service holds account secrets, encrypted with AES-256-GCM, and owns token refresh.
- **Roles and restrictions.** Each member holds exactly one role. Restrictions decide which connectors and which individual tools a target may reach, for a role or one user. A change takes effect within about two minutes.
- **Frozen parameters.** An admin can fix an argument so the model never sees or changes it. Note that a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself.
- **One audit log.** It keeps one entry per tool-call attempt, succeeded or failed. Each entry names the account reached and the AI client used, and stores argument names and counts, and never argument values.
- **Offboarding.** Removal or suspension ends access on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
- **Region.** Pick `eu`, `us` or `apac` when the organization is created. The data store and connector credentials stay in that region, and every request runs there.

A restricted tool is invisible, so the model never tries it. [Frozen arguments on a payment tool](/blog/frozen-parameters-wire-transfer-receiver/) show the freeze in practice.

## How do Docker's gateway and Elaichi compare, row by row?

Docker's gateway gives developers control of local runtimes; Elaichi gives admins control of company-wide access. The Docker column comes from Docker's [documentation](https://docs.docker.com/ai/mcp-catalog-and-toolkit/) and its [GitHub repository](https://github.com/docker/mcp-gateway), both checked October 2026.

| Question | Docker MCP Gateway | Elaichi |
| --- | --- | --- |
| Who operates it | You: Docker Desktop on each machine, or Docker Engine on a server | Elaichi; no server on your side |
| Who writes the code | Docker, partners and contributors through its catalog, plus your private servers | Elaichi authors 500+ connectors |
| How clients connect | Client config that launches the gateway over stdio, or HTTP with a Bearer token | One URL; each person signs in with OAuth |
| Credentials | Docker Desktop secrets or `.env`; OAuth through the Toolkit, shared across profiles | Separate credential service, AES-256-GCM, owns refresh |
| Tool control | Enable or disable tools per profile; custom catalogs | Restrictions per role or user, per connector and tool; frozen parameters |
| The record | Call log of tool name and argument shape, on by default | One audit log per organization, naming the account and client |
| A leaver | A question to ask Docker | Access ends on the next call |
| Isolation | A container per tool, CPU and memory caps, no host files by default | Elaichi serves connectors from its own infrastructure |
| Location | Wherever you run Docker | `eu`, `us` or `apac`, chosen at creation |

## Managed MCP connectors vs open-source MCP servers: what changes for a company?

The difference is who writes, runs and repairs the code. With Docker's catalog, the code comes from many authors and your side runs it. With managed connectors, one vendor writes, runs and repairs them.

Docker's [MCP Catalog](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/) holds Docker-built local servers, partner servers, and remote servers that run on the provider's infrastructure (checked October 2026). New servers are submitted through Docker's public registry repository on GitHub. That breadth is its strength.

Three things move for a company. Upkeep: an app's API change becomes the connector author's work, not your deploy. Rules: Elaichi pins each rule to the underlying operation, so renaming a tool does not slip it past a restriction. Record: every call lands in one audit log with one shape, whichever connector made it. The trade is that Elaichi, not you, fixes the connectors it authors. You can fork one as a custom connector if you need your own change. [Registries and first-party connectors](/blog/mcp-registry-vs-first-party-connectors/) are compared in more depth elsewhere.

## Is there a hosted MCP service for all our business apps, so we run nothing?

Yes, and that is the job a managed MCP platform does. Elaichi serves 500+ connectors from its own infrastructure, so there is no server, container or token to look after.

Check the catalog against your app list first. GitHub, Datadog and Linear are not in Elaichi's catalog. Jira, Slack, Salesforce and the Google Workspace apps are. For a missing app, use the app's own MCP server, or build a custom connector from JSON config. The [connector catalog](/connectors/) shows what is there.

Hosted also means someone else keeps tokens fresh. [The refresh and credential costs](/blog/self-hosted-mcp-servers-vs-control-plane/) are priced in that post.

## When is Docker's MCP Gateway the better choice?

Choose Docker's gateway when the users are developers and the tools are local. In these cases Elaichi is the wrong fit, per Docker's [catalog](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/) and [gateway guide](https://github.com/docker/mcp-gateway/blob/main/docs/mcp-gateway.md) (checked October 2026):

- **The tools touch the developer's own machine.** A filesystem, a local database or a browser automation server belongs in an isolated container on that machine. Elaichi is hosted and does not run local tools.
- **The work stays offline or inside your network.** Docker says its local catalog servers work offline once downloaded.
- **You want code you can read and run.** Docker's gateway is MIT-licensed open source.
- **Agents run unattended.** Elaichi's sign-in needs a browser, so a headless agent in CI cannot complete it. Docker's guide shows the gateway under Docker Compose for other services to use.
- **The app is GitHub.** Docker's catalog lists it, and Elaichi's catalog does not.

## Can you run Docker's gateway and Elaichi side by side?

Yes, and the clean split is by audience and by where the tool runs. Developers keep Docker's gateway for local, container-isolated tools. Everyone, developers included, reaches the company's SaaS accounts through Elaichi.

In Cursor, that means two entries: the Docker gateway for local tools, and Elaichi's URL for Jira, Slack and Salesforce. Keep each business app in one place only. If Salesforce is reachable through both, Elaichi's restrictions and audit log miss the path through the laptop. [Finding personal MCP servers on laptops](/blog/replace-personal-mcp-servers/) covers the inventory step.

## Which questions should you ask Docker before a company rollout?

Ask the questions a rollout to non-engineers depends on, and get the answers in writing. Docker's [MCP Toolkit](https://docs.docker.com/ai/mcp-catalog-and-toolkit/toolkit/) and [gateway repository](https://github.com/docker/mcp-gateway) describe developer workflows (checked October 2026). Five questions close the gap:

1. How does an employee without Docker Desktop, on a managed laptop, connect Claude or ChatGPT?
2. On a shared gateway with one Bearer token, how is each call tied to a named person?
3. Where does an admin see every call from every machine in one log, and what does Docker AI Governance add?
4. When someone leaves, how are the OAuth authorizations on their machine revoked, and how fast?
5. Can a rule fix an argument's value, not only switch a tool on or off?

Put the same five to Elaichi. [The full cost of running MCP servers yourself](/blog/self-hosted-mcp-servers-vs-control-plane/) prices the self-run side, [cloud API gateways with MCP](/blog/kong-cloudflare-mcp-gateway-vs-managed-connectors/) are another option, and [team-by-team starting points](/use-cases/) show where to begin.

## FAQ

### Docker MCP Gateway vs a managed MCP platform: which is better for a company?

It depends on who will use it. Docker's MCP Gateway runs MCP servers as containers on a machine you operate, which suits developers who already run Docker Desktop (Docker docs, checked October 2026). A managed MCP platform such as Elaichi serves the connectors itself behind one organization-wide URL, and each employee signs in with their own OAuth grant. For staff in support, finance or sales, Elaichi also gives admins per-tool restrictions, frozen parameters and one audit log. Removing a member cuts their access on the next call.

### Should a company use managed MCP connectors or open-source MCP servers?

Use open-source MCP servers when developers need local tools, want to read the code, and can run and patch it themselves. Use managed connectors when many non-engineers need the same SaaS apps. Then one vendor writes, hosts and repairs the connectors, holds the credentials, and records every call in one audit log. Elaichi is a managed option: it authors its connectors, so nobody at the company runs a server or a container.

### Is there a hosted MCP service for all our business apps so we do not have to run servers?

Yes. Elaichi serves its connectors from its own infrastructure behind one URL, https://api.elaichi.ai/mcp, so there is no server, container or token to host. Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent connect to it, and each person signs in once. Check the catalog against your app list first: GitHub, Datadog and Linear are not in it, while Jira, Slack, Salesforce and the Google Workspace apps are.

### Can Docker MCP Gateway and Elaichi be used together?

Yes. A clean split gives developers Docker's MCP Gateway for local, container-isolated tools such as a filesystem or a browser automation server, and gives everyone Elaichi for the company's SaaS accounts. Keep each business app in one place only, so restrictions and the audit log cover every call to it.

## Read next

- [Running your own MCP servers: the real cost](/blog/self-hosted-mcp-servers-vs-control-plane/) — Running your own MCP servers wins for one internal tool. Managed wins once credentials, token refresh, per-user sign-in and audit multiply.
- [MCP server registry vs first-party connectors](/blog/mcp-registry-vs-first-party-connectors/) — MCP server registry vs first-party connectors comes down to who fixes a broken tool: each server's own author, or one vendor that wrote and serves them all.
- [Replace personal MCP servers on employee laptops](/blog/replace-personal-mcp-servers/) — Find the MCP servers employees run from each client's config file, then replace personal MCP servers and their tokens with one governed endpoint.