Hosted MCP gateway or self-hosted: which one should carry your AI tool calls?
Choose hosted unless a policy or network rule forces the gateway onto your hosts. Elaichi is a governed MCP control plane and hosted MCP gateway, so weigh the trade-offs with that in mind.
A hosted MCP gateway and a self-hosted one do the same job. The difference is who runs it. The request usually reaches IT as a security requirement: every AI tool call must pass through one checkpoint that checks access and records the call. The platform team offers to run one. A vendor offers to run it for you.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An MCP gateway is the layer between AI clients and the tools they call. It signs each person in, decides which tools that person may reach, and writes down what happened. The four shapes the name covers are set out separately. This post takes one question only: should that layer sit on your infrastructure or on someone else's?
What does a self-hosted MCP gateway put on your servers?
It puts the gateway's data plane, the part that handles each call, and usually the MCP servers behind it, on infrastructure you operate. Some of these products are managed through a vendor's console; the traffic still runs on your hosts. Your team installs the data plane, upgrades it and keeps it up.
Three products show the range of gateways whose data plane runs on your infrastructure. Docker calls its MCP Gateway an "open source solution for orchestrating Model Context Protocol (MCP) servers". It "runs MCP servers in isolated Docker containers", and with Docker Desktop's MCP Toolkit enabled it runs in the background (Docker docs, checked October 2026). Docker's docs tag the whole MCP Catalog and Toolkit section Beta (same page, checked October 2026). The Docker gateway comparison covers it in depth.
Kong AI Gateway is managed through Kong's Konnect, while its data plane nodes "run in your environment (self-hosted, cloud, or Kubernetes)" (Kong docs, checked October 2026). Kong's AI MCP Proxy plugin supports per-tool access lists for its Consumers and Consumer Groups. All access attempts, allowed or denied, go to the plugin's audit log, and the plugin is part of Kong's AI Gateway Enterprise offering (Kong plugin docs, checked October 2026).
Lunar.dev presents MCPX as an enterprise MCP gateway, and its FAQ says MCPX is fully self hosted, running entirely inside your infrastructure (lunar.dev, checked October 2026). Counting servers before choosing MCPX goes further on that product.
Each of these is built for a team that already runs services and wants policy in front of them.
What do you run and patch on each side?
Self-hosted, you run the gateway and everything it depends on. Hosted, you run nothing for the gateway itself.
On the self-hosted side the list is concrete. There is the gateway binary or containers, the hosts under them, TLS certificates, the sign-in wiring to your identity provider, and each MCP server behind the gateway. Every one has its own release cycle. The cost of running MCP servers yourself prices the servers line by line, so this post does not repeat it.
On the hosted side, Elaichi hosts the one MCP endpoint and the catalog connectors behind it. A company does not need to run an MCP server to use Elaichi. Running one is a choice. What stays with you is configuration: who holds which role, which tools each role may reach, and which accounts are connected.
Where do the app credentials live?
With a self-hosted gateway, they live in your secret store. With Elaichi, they live in a separate credential service that Elaichi runs.
Someone has to hold them. The MCP authorization spec says an MCP server must only accept tokens valid for its own resources and "MUST NOT accept or transit any other tokens". The token used at the upstream app is a separate one. So the gateway, or the servers behind it, hold every app's credential. Docker describes its gateway as a proxy that manages configuration, credentials and access control (Docker docs, checked October 2026). On a self-hosted gateway, that store, its encryption and its key rotation are yours.
Elaichi keeps connector credentials out of its main data. A separate credential service holds them, encrypted at rest with AES-256-GCM, and the key can be rotated without re-encrypting old rows. Elaichi fetches a credential into memory only for the call that needs it. The AI client holds only an Elaichi token. Elaichi never forwards that token to a remote MCP server, so a server sees only tokens its own authorization server issued.
The trade is custody. You trust the hosted vendor's handling instead of your own. For key custody, customer-managed keys in AWS KMS come with the Black plan, which is launching soon.
Who writes the connectors behind the gateway?
A self-hosted gateway governs servers that already exist. A hosted MCP gateway like Elaichi also serves the connectors, most of which it writes.
A gateway in front of servers adds a door, not apps. Kong's route is to turn existing APIs into tools an agent can call over MCP, which suits a company whose APIs already sit behind Kong (Kong docs, checked October 2026). For SaaS apps, the servers come from your team, the app vendor or the community.
Elaichi's catalog holds 600+ connectors of two kinds. Elaichi authors and runs most of them itself, so an app's API change is Elaichi's to fix. The rest are native MCP connectors: the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. Datadog and Linear are there that way. How vendor MCP servers run through Elaichi covers that path.
A company can also bring its own server. On Gold, an Org Owner or Org Admin adds a remote MCP server as the organization's own connector. It must speak MCP over Streamable HTTP, the transport that sends each message as an HTTP request, and be reachable over public HTTPS. Restrictions and OAuth scopes, the permissions a person approves on the consent screen, are checked before a call leaves Elaichi, and only a tool on that connection's own active list can run.
How many addresses do AI clients point at?
With a self-hosted gateway, as many as you deploy. With Elaichi, one.
A self-hosted gateway's address count follows your topology. One gateway per laptop, one per team or one shared cluster are all possible, and each is a configuration someone keeps in step across Claude, ChatGPT, Cursor or any MCP client.
Elaichi serves every organization at https://api.elaichi.ai/mcp. The OAuth grant behind each token, not the URL, decides the organization and the person. OAuth is the sign-in standard that lets a client act as a named person without holding that person's password. Each member still connects their client once and approves their own grant. No URL carries a token, and there is no per-team or per-toolbox address to hand out or take back. Per-team and org-wide endpoints compares the two models.
Who carries upgrades, uptime and the pager?
Self-hosted, your team does, on its own schedule. Hosted, the vendor does, on the vendor's schedule.
Running the gateway yourself means you choose when to upgrade. You can hold a version through a busy quarter, test a release in staging first, and read the code before it runs. It also means the pager. A gateway outage stops every tool call routed through it, so it needs monitoring, failover and someone on call.
Elaichi patches the endpoint and the connectors it authors. For a native MCP connector, the vendor maintains its own server's tools. You give up control of timing: a change lands when Elaichi ships it. Ask any hosted vendor, Elaichi included, for its uptime commitment in writing before a rollout depends on it.
Changes you make yourself have timing too. In Elaichi a role or restriction change takes about two minutes to reach every surface. Removing or suspending a member revokes every live grant, so their AI clients fail on the next call.
Where does the data sit with a hosted MCP gateway?
With a self-hosted gateway, it sits where you put it. With Elaichi, an EU or US organization is pinned to its region, APAC carries no residency guarantee, and a few things sit outside the region.
Self-hosting gives the most control over placement. The gateway's logs, config and secrets stay on your hosts. Calls to SaaS apps still leave your network, because the apps live elsewhere.
Elaichi has three regions, EU, US and APAC. The organization picks one at creation, and it cannot change later. For an EU or US organization, the data store (the per-organization store that holds most organization data) and the execution of its requests and tool calls are pinned to that region. For an APAC organization, region is not a residency guarantee.
Some things sit outside the region. User accounts and SSO settings are not pinned to one. Files stored from tool results go to the EU for every organization. Elaichi's privacy policy says its audit-log store is one EU instance serving all regions, so a US or APAC organization should not expect its audit trail to stay in its region. Elaichi keeps 90 days of audit history. Data residency for AI agents in the EU goes deeper.
How do the two compare, question by question?
Self-hosting keeps control and work in-house. A hosted MCP gateway moves both to a vendor.
| Question | Self-hosted MCP gateway | Hosted MCP gateway (Elaichi) |
|---|---|---|
| What you run and patch | The gateway, its hosts, TLS, and the MCP servers behind it | Nothing for the gateway; Elaichi hosts the endpoint and catalog connectors |
| Where credentials live | Your secret store, encryption and rotation | A separate credential service, AES-256-GCM at rest; the client holds only an Elaichi token |
| Who writes the connectors | Your team, the app vendor or the community | Elaichi authors most; vendors run their own native MCP servers; you can add your own remote server on Gold |
| Addresses clients point at | One per gateway you deploy | One, https://api.elaichi.ai/mcp, for every organization |
| Upgrades and uptime | Your schedule and your pager | Elaichi's schedule; ask for the uptime commitment in writing |
| Data location | Wherever you run it | EU or US: data store and request execution pinned to the region. APAC: no residency guarantee. User accounts, stored tool files and the audit log sit outside the region |
| Inside your own network | Yes | No |
When is self-hosting the MCP gateway the right call?
Self-host when the servers or the policy require your own network. In these cases Elaichi is the wrong fit, and saying so saves a pilot.
- The servers cannot be exposed. Elaichi's remote MCP connector needs public HTTPS. A server on an internal hostname, an IP address or localhost cannot be added, so a gateway inside the network fits.
- Policy says the checkpoint runs on your hosts. Some security programs require every gateway to sit in infrastructure the company operates. Elaichi is hosted only.
- The tools are local. A filesystem or browser tool on a developer's machine belongs in a local container, which is where Docker's gateway runs.
- Your MCP traffic is your own APIs. If those APIs already sit behind Kong, exposing them as MCP tools is configuration, not a new vendor.
- You need to hold upgrades or read the code. Docker's gateway is MIT-licensed open source in the docker/mcp-gateway repository, checked October 2026.
- The audit trail or the data must stay in your region. Elaichi's privacy policy says its audit-log store is one EU instance serving all regions, so a US or APAC organization should not expect its audit trail to stay in its region (privacy policy). For APAC, the region is not a residency guarantee.
With one app, one client and a few engineers, no gateway is needed yet.
Can you run a self-hosted gateway and a hosted one together?
Yes. Split them by where the server lives. Internal and local tools stay behind the gateway you run. Company SaaS accounts go through Elaichi, where each person signs in once.
Keep each app on one path only. If Salesforce is reachable through both, Elaichi's restrictions and audit log miss the calls that took the other route. Shortlisting MCP gateways by shape lays out the vendors on each side. The connector catalog shows which apps Elaichi already serves, and team-by-team use cases show where a rollout usually starts.
