# MCP data residency: self-hosted vs managed

> On MCP data residency self-hosted vs managed: compare a managed endpoint pinned to an EU or US jurisdiction before you build your own.

**TL;DR** On MCP data residency self-hosted vs managed, the comparison is narrow. Self-hosting gives you placement you control everywhere. Elaichi pins an EU or US organization's data store, and the execution of its org-scoped requests, to that jurisdiction. An APAC organization's data store is placed there on a best-effort basis only, and some stores sit outside the region whichever option you pick.

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](/privacy/), 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](https://www.lunar.dev/), checked October 2026). Composio's Enterprise page offers self-hosting at the Enterprise tier ([composio.dev](https://composio.dev/enterprise), 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](https://www.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](https://docs.zapier.com/mcp/manage/security), 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](/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](/blog/self-hosted-mcp-servers-vs-control-plane/) sets it out. For the case where the answer is neither option, read [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/).

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](/blog/hosted-mcp-gateway/).

## 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](/blog/eu-data-residency-ai-agents/) goes through each hop. For the control questions that sit beside residency in most reviews, start with the [MCP security review checklist](/blog/mcp-security-review-checklist/). [MCP governance](/blog/mcp-governance/) covers who may do what once the data is where you want it.

## FAQ

### Does Elaichi's APAC region guarantee data stays in Asia-Pacific?

No. Elaichi has three regions: EU, US and APAC. For EU and US organizations, the organization's data store and the execution of its org-scoped requests stay in that jurisdiction. An APAC organization's data store is placed in that region on a best-effort basis. Best effort is not a residency guarantee. If an obligation names an APAC geography and demands a guarantee, the APAC region does not provide one.

### Which Elaichi data is not stored in the organization's region?

Not everything is placed by region. Elaichi's shared D1 database and its KV namespaces are not pinned to any jurisdiction. User accounts, the organization row including its plan and region, API tokens and SSO connections sit in D1. Sessions, API-token records, MCP OAuth authorization requests, access and refresh tokens, social-login OAuth state and short-lived permission caches sit in KV. Every organization's audit trail is stored in one log instance in the EU, as Elaichi's privacy policy and DPA state. Files stored from tool results go to one private bucket in the EU, for every organization.

### Can an organization change its Elaichi region later?

No. An organization's region is chosen when the organization is created. That happens on the signup form, on the create-organization form, or during onboarding by Elaichi staff. No member, admin or staff route accepts a new region afterwards. The signup form states this directly: "Where your organization's data is stored. This can't be changed later." If no region is sent at creation, Elaichi creates the organization in US.

### Where do connector credentials live for an EU organization?

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. Connections created earlier stay where they were until they are copied, and reconnecting a connection copies it into the region. Credentials themselves are held by a separate credential service, in encrypted form. They are encrypted at rest with AES-256-GCM. Elaichi fetches them into memory only for the call that needs them.

### Is self-hosting the only way to satisfy a residency requirement for MCP?

Not if the requirement names the EU or the US. Elaichi pins an EU or US organization's data store to that jurisdiction, along with the execution of its org-scoped requests. That includes POST /mcp and connected-tool calls. Every response a region gateway builds names the location that ran it, so the claim is checkable. Self-hosting is still the honest answer when the obligation names a geography Elaichi does not pin, such as one in APAC. It is also the honest answer when the obligation covers a store Elaichi keeps outside the region. The audit trail is one of those: it sits in a single EU instance for every region.

## Read next

- [Hosted MCP gateway vs running the gateway yourself](/blog/hosted-mcp-gateway/) — A hosted MCP gateway runs the checkpoint every AI tool call passes through. Self-hosting puts it on your servers. Six questions decide which fits.
- [Open source MCP servers vs paid: the real cost](/blog/free-mcp-servers-vs-paid-control-plane/) — The real choice in open source MCP servers vs paid is operating cost: sign-in, credentials, per-person access, the audit trail and offboarding, itemized.
- [Docker MCP Gateway vs a managed MCP platform](/blog/docker-mcp-gateway-vs-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.