You have a data protection obligation, a customer contract or a regulator question that names a geography. Somebody on the team has concluded that self-hosting is the only way to satisfy it. They want to run the MCP software themselves, in a region they picked. MCP (Model Context Protocol) is the protocol AI clients use to reach tools. The question underneath is where the data behind those tool calls sits and executes. That is the real subject when people argue MCP data residency self-hosted vs managed.
Self-hosting is a real answer to that question. It is also an expensive one if residency is the only reason you are doing it. Before you commit, compare the two options against the legs that actually carry data. Comparing deployment models as a whole hides the detail that decides the review.
MCP data residency self-hosted vs managed: what each one actually fixes
Self-hosting fixes placement by construction. You choose the cloud, the region and the database, so every store is where you put it. A managed endpoint fixes placement by contract and by configuration. It fixes it only for the parts the vendor pins. So this is not control versus convenience. It is a list of legs, checked one at a time.
| Leg | Self-hosted | Elaichi EU or US region | Elaichi APAC region |
|---|---|---|---|
| Organization data store | Where you put it | Stays in that jurisdiction | Best-effort placement, not a guarantee |
| Execution of org-scoped requests, tool calls included | Where you put it | Stays in that jurisdiction | Best-effort placement |
| Connector credentials, connections made since 2026-10-05 | Where you put it | In the organization's region | Best-effort placement |
| Audit trail | Where you put it | One EU log instance | One EU log instance |
| Files stored from tool results | Where you put it | One EU bucket | One EU bucket |
| Accounts, sessions, API tokens, SSO connections | Where you put it | Not pinned to any region | Not pinned to any region |
| Operational burden | Yours | Elaichi's | Elaichi's |
Elaichi has three regions, labeled EU, US and APAC. An organization's region is chosen when the organization is created. For EU and US organizations, the organization's data store and the execution of its org-scoped requests stay in that jurisdiction. Org-scoped means requests made inside an organization. That covers the REST API called inside it, everything under the organization's own routes, POST /mcp, the SCIM endpoint and file downloads. Invite acceptance, connection callbacks and MCP consent approval count too.
That is a specific claim about specific legs. It is not a claim that every byte Elaichi touches lives in the region. A post that said so would be wrong.
How is the APAC region placed?
No. An EU or US organization's data store is pinned to that jurisdiction. An APAC organization's data store is placed in that region on a best-effort basis, which is not a residency guarantee.
This matters because the three regions look symmetric in the picker and are not. The signup and create-organization forms offer United States, European Union and Asia-Pacific, preselected to United States. Each carries the line "Where your organization's data is stored. This can't be changed later." Suppose your obligation names Australia, Japan, Singapore or India specifically. If it requires a guarantee rather than a best effort, the APAC region does not give you one. Self-hosting in that geography does, if you build it there.
That is the honest case for self-hosting in this post: a residency obligation that names a geography outside the EU and the US. Say it plainly in your own review. Discovering it during an audit is worse.
Which stores sit outside the organization's region either way
Some stores are not placed by region. A comparison usually skips this part. Elaichi's shared D1 database and its KV namespaces are not pinned to any jurisdiction. User accounts, the organization row, API tokens and SSO connections live in D1, outside the per-organization store. The organization row carries its plan, trial, billing fields and region. Sessions and API-token records live in KV. So do MCP OAuth authorization requests, access and refresh tokens, social-login OAuth state and short-lived permission caches.
Two more are explicit. Every organization's audit trail is stored in one log instance in the EU, whatever its region. Elaichi's privacy policy, DPA and GDPR page all say so in the same words. Files stored from tool results go to one private bucket in the EU, for every organization.
If you self-host, these are legs you place yourself. If you adopt a managed endpoint, they are legs you accept, document and get reviewed. Neither is automatically the right call. Assuming a region picker covers them is the error.
Where other vendors place the same legs
Each vendor draws the line somewhere different, and its own page is where to check it. Lunar.dev's FAQ says MCPX is fully self-hosted, running entirely inside the customer's infrastructure (lunar.dev, checked October 2026). Composio's Enterprise page offers self-hosting at the Enterprise tier (composio.dev, checked October 2026). Its stated reason is teams whose infrastructure, network or data-residency needs call for it. MintMCP lists EU and US data residency among its enterprise-ready features (mintmcp.com, checked October 2026). Zapier's MCP security page says customer data is stored in AWS US-East 1 in the United States (docs.zapier.com, checked October 2026). The same page says region-specific data residency is not available unless otherwise agreed. Read each page yourself before quoting it in a review, because vendors move.
What the region does cover for a tool call
For a connected-tool call, Elaichi fetches the account's credential from the credential service, passing the organization's region. It applies that credential and calls the third party inside the organization's region gateway. So the third-party request is sent, and its response handled, there. Elaichi's tool executors run only inside the organization's region gateway or its in-app assistant thread. That covers connected-tool proxy calls, toolbox tools, synthetic tools and Code Mode. Anywhere else, they refuse.
The gateway keeps no storage of its own, so the organization's data store stays the single source of truth. An EU or US organization's gateway is created inside that jurisdiction. A gateway that can read its own name and jurisdiction refuses a request signed for a different one. Every door that opens an organization's data refuses to run outside that organization's gateway.
Per-organization background work runs there too: billing webhook events, observability forwarding, notification delivery, the deletion purge, the tool-file sweep and lifecycle emails.
What runs outside a region gateway
Requests that do not act inside an organization run in the edge worker, wherever the request lands. That is sign-in and sign-up, a person's own profile, creating and listing organizations, and staff administration. It also covers the OAuth server's registration, authorization, token, revocation and userinfo endpoints, and webhook intake.
A few paths deliberately read or write an organization's data store from the edge. They are creating an organization, listing a person's organizations, reading the signed-in user, staff administration, sign-in side effects, and membership changes made at login. The OAuth token, revoke and userinfo endpoints do too. None of them executes a connected tool.
Every response a region gateway builds names the location that ran it and the organization's region. So you can check the claim rather than take it.
Connector credentials, which are their own question
Connections created since 2026-10-05 have their credentials placed in the organization's region. That means inside the EU or US jurisdiction for those regions, and best-effort placement for APAC. Older connections stay where they were until they are copied. Reconnecting copies an older connection into the region.
Whether credentials for connections created before that date are now in the organization's region is not something Elaichi states either way. Do not treat it as settled. If your review needs an answer, ask for one in writing. Reconnecting a connection is the documented way to move it.
Connector credentials are not kept in Elaichi's main data. A separate credential service holds every connected account's secrets in encrypted form, and Elaichi's own row carries only ownership and lifecycle. Secrets are encrypted at rest with AES-256-GCM, and the key can be rotated without re-encrypting old rows. Elaichi fetches credentials into memory only for the call that needs them.
The cost side of self-hosting, honestly stated
If residency is your only driver, weigh what you take on. Running the thing yourself means you own the OAuth server, the credential store and its key rotation. You also own the audit pipeline, the connector catalog and the per-region placement of every one of them. Elaichi's catalog holds 650+ connectors, most of them authored and run by Elaichi. The rest are native MCP connectors, where the vendor builds and runs its own MCP server. Reproducing that is not a residency project.
For the broader engineering bill, the real cost of running your own MCP servers sets it out. For the case where the answer is neither option, read when you don't need an MCP gateway yet.
There is a middle path. A company that runs a remote MCP server reachable over public HTTPS can add it to Elaichi as its own connector on Gold. An Org Owner or Org Admin creates it. Calls through that connector are checked against the caller's access and written to the audit log before they leave Elaichi. That keeps a server you placed yourself, for the data that needs it, under one hosted gateway's rules.
How to decide
Write down the obligation in its own words, then map it to legs.
Suppose it names the EU or the US, and covers the data store and the execution of tool calls. A managed endpoint pinned to that jurisdiction answers it. Document the unpinned stores and have them reviewed. If it names a geography in APAC and requires a guarantee, Elaichi's APAC region is best-effort placement rather than a guarantee. Self-hosting there is the honest answer. If it reaches the audit trail specifically, note that every region's audit trail is stored in one EU instance. An organization wanting a longer history forwards it to its own log service, which comes with the Black plan, launching soon.
For the leg-by-leg version of the EU question, EU data residency for AI agents goes through each hop. For the control questions that sit beside residency in most reviews, start with the MCP security review checklist. MCP governance covers who may do what once the data is where you want it.
