> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Hosting & Data Residency

> Where MCP Manager is hosted — Google Cloud Platform in the United States — whether a self-hosted or on-premise version exists and why the hosted model usually fits, what you keep in your own environment (your servers, an EU copy of your logs, redaction before logging, static egress IPs), and the status of EU data residency.

**MCP Manager** is a hosted cloud service operated by Usercentrics. This page covers where it runs, whether you can self-host, how it reaches servers inside your network, and EU data residency.

## Where MCP Manager runs

MCP Manager runs inside **Usercentrics' own cloud platform** — **Google Cloud Platform**, US region `us-east1` — under the same security and compliance program Usercentrics runs as a data-privacy company. The services that process your traffic and the database holding your configuration and logs are all there. There is no region selection today, so the data MCP Manager processes and stores resides in the United States.

That operator matters for a governance product. Usercentrics is a global leader in consent management and data privacy — based in Munich, active in 100+ countries, processing billions of user consents a month across millions of websites and apps. Handling personal data and meeting regulatory obligations at scale is its core business. See [Architecture & Trust](/mcp-gateway-concepts/architecture-and-trust) for how the path is secured.

## Self-hosted and on-premise

Wanting a self-hosted control plane is a common, reasonable security-review ask. **MCP Manager ships only as the Usercentrics-operated cloud service** described above. There is no on-premise, customer-deployed, or air-gapped build today, and none is planned. For most teams, the hosted model fits the real goal better than self-hosting would:

* **The traffic is mostly cloud-to-cloud already.** The servers a gateway fronts are usually SaaS (Atlassian, GitHub, HubSpot) and the AI clients (Claude, ChatGPT, Cursor) are cloud too, so that traffic already leaves your network — an on-premise gateway wouldn't contain it. The gateway's value is identity, governance, and audit on top of that flow, delivered without you running more infrastructure.
* **No infrastructure to run.** Self-hosting means operating and securing the whole stack yourself, from Kubernetes to scaling, patching, and uptime. On the hosted model that work falls to a high-trust provider whose global team monitors the systems around the clock, so you can meet your compliance obligations without taking on the cost and complexity of running it yourself. You can review Usercentrics' security posture and certifications at its [trust center](https://trust.usercentrics.com/).
* **You still control what stays in your environment.** See [what you keep](#what-you-keep-in-your-own-environment) for the levers that decide what ever leaves your network.

If a self-hosted control plane is a hard requirement for your organization, tell your MCP Manager contact, since customer demand shapes what we build next.

### Reaching a server inside your network

A common version of the on-premise question is *"how does MCP Manager connect to a server that's only reachable inside my network?"* It needs nothing self-hosted:

* **Workstation server (best fit).** A small agent inside your network opens an **outbound, encrypted WireGuard tunnel** to the gateway. The server stays behind your firewall, opens **no inbound ports**, and is never exposed to the internet — the gateway reaches it only through that tunnel. See [Workstation servers](/mcp-gateway-concepts/mcp-servers/workstation).
* **Managed or self-hosted remote server.** Whether the server already runs at a URL in your network (a [remote server](/mcp-gateway-concepts/mcp-servers/remote)) or you launch it there as a [managed server](/mcp-gateway-concepts/mcp-servers/managed), the gateway reaches it over HTTPS from a single **static IP address**. Allowlist that one IP on your firewall so the server accepts connections only from MCP Manager. Find your static IPs at [enterprise/ip-ranges](https://app.mcpmanager.ai/enterprise/ip-ranges).

Either way an internal-only server is fully governed without being published to the internet.

## What you keep in your own environment

You decide what leaves your environment and what the hosted service ever holds:

* **Your servers keep their data.** [Workstation](/mcp-gateway-concepts/mcp-servers/workstation) and [managed](/mcp-gateway-concepts/mcp-servers/managed) servers — and the systems behind them — stay in your infrastructure; MCP Manager brokers access from in front.
* **You control what's logged.** [Gateway rules](/features/gateway-rules/overview) redact, mask, or block sensitive values **before** anything is logged, and you can forward logs to your own [collector](/enterprise/export-to-siem/self-hosted-collector) in any region while keeping in-platform retention short.
* **You can lock the path.** Allowlist the gateway's [static egress IPs](/mcp-gateway-concepts/architecture-and-trust) so a sensitive upstream accepts connections only from MCP Manager.

## EU data residency

For European organizations this is often a real compliance concern. **A dedicated EU-hosted deployment is not available today.** There is no region selection, and the gateway processes traffic and stores configuration and logs in the United States, as described above.

What usually shapes a GDPR position is *which* personal data is processed and where it comes to rest, rather than the region of any single component in the path. Two levers help here, and both are in your hands:

* **Keep personal data out of the hosted store.** [Gateway rules](/features/gateway-rules/overview) redact or mask PII before it is logged — often little or none reaches the US store — and a [self-hosted collector](/enterprise/export-to-siem/self-hosted-collector) in an EU region holds the audit copy you keep.
* **Keep source data in the EU.** The systems behind [your own servers](#what-you-keep-in-your-own-environment) never leave your EU environment.

Given Usercentrics' European roots, EU residency is under active consideration, and we are actively working through how to deliver it. If it matters to you, tell your MCP Manager contact about your needs — and it helps us most if you can answer the two questions that shape the design:

* Does your requirement cover **data at rest only**, or **data in transit** as well, including the servers that process it?
* Is it acceptable for **US-based operational staff to access the systems for maintenance**, or must the **entire solution stay EU-only**?

Customer answers to these questions directly guide what we build.

## Further reading

<CardGroup cols={2}>
  <Card title="Workstation servers" icon="laptop" href="/mcp-gateway-concepts/mcp-servers/workstation">
    Reach a server inside your network through an outbound encrypted tunnel.
  </Card>

  <Card title="Managed servers" icon="server" href="/mcp-gateway-concepts/mcp-servers/managed">
    Run your own MCP servers and broker access through a gateway.
  </Card>

  <Card title="Self-hosted collector" icon="diagram-project" href="/enterprise/export-to-siem/self-hosted-collector">
    Keep a copy of your logs in an OpenTelemetry collector you run.
  </Card>

  <Card title="Architecture & Trust" icon="building-shield" href="/mcp-gateway-concepts/architecture-and-trust">
    How the gateway path is secured — encryption, isolation, egress IPs.
  </Card>
</CardGroup>
