Self-hosted MCP gateway: When to run your own

TL;DR: Self-host if your organization has a data-residency rule that prohibits tool-call payloads from transiting a vendor-operated layer, a network-boundary constraint that bars third-party proxies from the request path, or an audit-control requirement that mandates logs write to a database you govern directly. If none of those apply, a vendor-managed cloud deployment is the faster path. Docker MCP Gateway, Microsoft mcp-gateway, and IBM ContextForge handle routing and lifecycle management credibly for contained workloads. What none of them ship is the execution layer: the system that connects credential resolution, policy enforcement, and audit logging into one governed path auditors can verify. Composio Enterprise delivers that layer already built and self-hostable inside your own VPC. When an agent calls a tool, you see who made the call, what it attempted, and why it succeeded or failed.

Running a Model Context Protocol gateway in a local Docker container is straightforward. Turning that container into a governed enterprise gateway requires building the execution layer that connects credentials, policy enforcement, and audit trails into a system auditors can verify. Platform engineers evaluating self-hosted MCP gateways consistently focus on the binary first and discover the real engineering commitment only after they have already started building.

This guide is for IT Leaders and platform engineers with a data-residency or network-boundary constraint deciding between running an open-source gateway themselves and deploying a self-hostable enterprise solution. This guide covers what each open-source option does well, what none of them document clearly (the auth and policy layer), and what Composio delivers when you need all of it running inside your own infrastructure.

Assessing your need for custom gateway control

Self-hosting is not always the right answer. It is right when specific constraints make a vendor-managed cloud unacceptable, and you need to be precise about which constraint applies before committing engineering capacity.

Enforcing local data residency rules

Financial services organizations operating under strict geographic data requirements often face explicit rules that customer data must remain within a defined boundary. For AI agents reading transaction records or processing case files, a self-hosted gateway inside your own VPC keeps tool-call payloads on your infrastructure rather than transiting a vendor-operated layer. On Cloud deployments, payload non-retention is available as a Zero Data Retention add-on; it is not enabled by default. For self-hosted and VPC deployments, your team controls the storage infrastructure directly, configuring where payloads are written, whether they are written at all, and how retention is enforced within your own boundary.

Controlling gateway data flow

The network boundary constraint is distinct from geographic residency. Some organizations prohibit any outbound API call from passing through a third-party proxy, even a SOC 2 certified one, because the vendor sits in the request path for sensitive data. A self-hosted gateway places the proxy on your own network, so credential resolution and request routing happen entirely within your perimeter before the call exits to the external SaaS API.

Implementing mandatory audit controls

Internal security teams at regulated organizations sometimes require that audit logs write to a database they control, not a vendor's centralized log store. A self-hosted deployment gives you exactly that: logs written to your own infrastructure, retained under your own policy, and queryable by your own SIEM without data leaving your environment.

When pure open-source is the right call

Pure open-source, meaning Docker MCP Gateway, Microsoft mcp-gateway, or IBM ContextForge, is the right starting point when your constraint is none of the above. If you are running a proof-of-concept, an internal research tool, or a single-agent deployment with one or two integrations and no compliance audit on the horizon, the overhead of building a credential vault, policy engine, and audit store is not justified. These binaries handle routing and lifecycle management well for contained workloads where a platform engineer owns the full stack and has the capacity to build the auth layer incrementally as requirements grow. The engineering cost only becomes the deciding factor when that workload expands to multiple agents, multiple integrations, and a first enterprise security review.

Infrastructure requirements for MCP gateways

Self-hosted Docker gateway requirements

The requirements below cover the infrastructure layer before you write a single line of gateway configuration.

VPC gateway deployment requirements

• Network isolation: Configure the subnet to deploy the MCP gateway in your VPC with appropriate network boundaries.

• Container runtime: Provision a container engine to execute the MCP gateway Docker image.

• Credential storage: Set up a key management service (KMS) for encryption key handling.

• Ingress routing: Configure routing to direct traffic from your agent runtimes to the gateway.

Architecting a custom MCP gateway

The MCP specification defines two primary transport mechanisms. In stdio transport, the client starts the MCP server as a child process and communicates through standard input and output via newline-delimited JSON-RPC messages. This works for local single-process agent deployments and is where most open-source documentation stops.

For remote deployments, HTTP Streamable is the modern recommended transport introduced in MCP specification version 2025-03-26, replacing SSE as the primary HTTP transport for external network routing. SSE splits traffic across two coordinated endpoints, a persistent event stream for server-to-client output and stateless HTTP POST requests for client input, which makes standard proxy routing and load balancing harder to apply cleanly. Streamable HTTP consolidates communication into a single endpoint, which is where L7 inspection, load balancing, and standard web tooling apply without coordination overhead.

IBM, Cloudflare, Docker, and Microsoft: Assessing the open-source options

Two options that surface frequently in enterprise evaluations deserve an honest assessment.

IBM's ContextForge MCP Gateway is an IBM-maintained open-source project that functions as an MCP registry and can convert REST endpoints into MCP servers, reaching General Availability on 1 May 2026 and currently at v1.0.4, released 23 June 2026. For teams that need built-in OAuth lifecycle management and a unified audit path that connects credential resolution, policy enforcement, and logging into one verifiable system, Composio Enterprise delivers those controls at the Enterprise tier with vendor support included.

Cloudflare's MCP offering provides strong edge-network routing and benefits from Cloudflare's global PoP infrastructure for latency-sensitive deployments, and when your constraint is data residency inside a private network rather than global edge performance, Composio's self-hosted VPC gateway handles complex multi-app OAuth lifecycles entirely within your network boundary without routing credential data through external infrastructure.

Docker's MCP Gateway is open source and generally available; its integration with Docker AI Governance, which adds centralized organization-wide policy, is invite-only. Docker's MCP Gateway combines container isolation with gateway-level access controls, running MCP servers in isolated containers with restricted privileges while managing configuration, credentials, and tool request approvals at the gateway. What it leaves to you is credential vaulting, cross-tool policy evaluation, and unified audit logging into one governed path auditors can verify without reconstructing events from multiple sources. Microsoft's mcp-gateway is a reverse proxy and management layer designed for scalable, session-aware routing and lifecycle management of MCP servers in Kubernetes environments, with enterprise-ready telemetry and observability integration points. Both are credible routing solutions. What they leave to you is building the execution layer: the system that connects credential resolution, policy evaluation, and audit logging into one governed path that auditors can verify without reconstructing events from multiple sources.

Security and governance features

Many open-source MCP gateways provide role-based access control for granular permission control over tools, actions, and agents, but this depth of policy enforcement is not universal. The execution layer that connects OAuth lifecycle management, policy enforcement, and audit trails into one verifiable system is what most open-source gateway binaries do not provide out of the box, and that absence has concrete compliance implications.

Audit log retention requirements vary by framework. SOC 2 Type II does not specify a minimum retention period; 12 months is the period most commonly applied in practice, consistent with your stated policy and the trust services criteria under review. ISO 27001 takes a risk-based approach and does not mandate a specific retention period; 12 months is the working baseline most commonly applied, though your own risk assessment may indicate a longer period. PCI DSS 4.0 Requirement 10.7 mandates at least 12 months of audit log history, with the most recent three months immediately available for analysis. Your self-hosted gateway needs to write to a store that satisfies whichever regime applies, and you need to build that store yourself if you are running open-source.

Building vs buying your security controls

Scaling OAuth logic for many tools

Every enterprise SaaS integration requires its own OAuth flow. Each service implements token expiration, refresh behavior, and credential rotation differently, and when AI agents run continuously across multiple integrations, token lifecycle management becomes part of the system's runtime infrastructure rather than a simple authentication detail.

Customer case studies document engineering time saved by using managed integration infrastructure rather than building OAuth plumbing in-house. Those figures reflect the real cost of building credential handling, managing refresh cycles, and maintaining scope permissions for tools that teams treat as routine.

Governing token refresh at scale

OAuth 2.0 leaves refresh behavior deliberately open, and every provider implements it differently. Everything past the minimal RFC definition, token lifetime, rotation policy, revocation on reuse, and per-account caps, is provider-specific. Access tokens typically expire within minutes, while refresh tokens can persist for days, months, or indefinitely depending on provider configuration.

Building this yourself means treating each provider-tenant connection as its own token lifecycle: checking expiry before each call, refreshing with a safety margin, retrying on 401, storing rotated tokens atomically, securing them at rest, and monitoring for provider changes. Implementing correct rotation policy across a dozen integrations is the maintenance burden that grows with every new tool you add.

Enforcing least privilege at scale

A prompt instruction telling an agent not to delete records is a sign on a door. Policy-as-code is the lock. When an admin disables the delete action for a GitHub integration, the agent cannot delete regardless of what the prompt contains, what the model reasons, or what a user tries to inject. That enforcement happens in the request path before the model is involved.

Many open-source gateway binaries handle routing, but building a policy engine that evaluates the full request context, which user, which agent, which tool, which action, which parameters, before forwarding to external APIs requires middleware you write, test, and maintain. Effective policy enforcement inspects the parameters of the tool call, not just the tool name, to block specific actions on specific resources.

Centralized logging for audit compliance

The JSON below shows what a complete, compliant audit record looks like for a denied tool invocation. Note that it records the denied call, not just successful ones. SOC 2 auditors assess completeness, including whether your logs capture enforcement actions, which means a log that records only successful calls is an activity summary, not audit evidence.

{
  "timestamp": "2025-08-28T14:32:01.892Z",
  "event_id": "evt_9f82b3c4d5e6f7g8",
  "actor": {
    "user_id": "usr_dev_platform_01",
    "role": "application_developer",
    "agent_id": "agt_support_copilot_v2"
  },
  "action": {
    "tool": "github",
    "method": "delete_repository",
    "parameters": {
      "owner": "example-org",
      "repo": "example-repo"
    }
  },
  "evaluation": {
    "policy_id": "pol_least_privilege_prod",
    "decision": "DENIED",
    "reason": "Action 'delete_repository' is restricted on this resource by policy-as-code infrastructure controls."
  },
  "network": {
    "source_ip": "10.0.4.12",
    "vpc_id": "vpc-0a1b2c3d4e5f6g7h8"
  }
}

Hidden operational costs of self-hosting

The table below shows the documented cost difference between building on an open-source gateway and deploying Composio Enterprise.

Build vs. buy TCO decision matrix

Failure mode analysis

Schema drift is an unplanned, uncoordinated change to a source system's data structure that downstream pipelines are not prepared for. For example, if a security data provider restructures finding metadata from flat fields to nested objects, integrations expecting finding.severity would receive finding.details.severity instead, resulting in unprocessed findings until the integration layer is updated. Each of those schema changes lands directly on your team's calendar when you own the integration layer.

Standardizing your self-hosted MCP gateway

Composio offers three deployment paths: managed SaaS for the fastest path to production, VPC deployment for organizations that need infrastructure inside their own network boundary, and fully self-hosted for complete data sovereignty. VPC and fully self-hosted options are Enterprise tier features, available through Composio's sales team to meet specific compliance and data-residency requirements. Composio's execution layer, the system that connects credential resolution, policy enforcement, and audit logging into one governed path, runs identically whether you deploy on Composio Cloud or inside a private network. The difference is where the binary runs and who manages the host infrastructure.

The credential vault, policy engine, and audit log are the authorization and verification stages of a four-stage execution model: plan, authorize, execute, verify. The self-hosted gateway is how you keep the authorize and verify stages inside your own network boundary when compliance requires it. What runs on top of that layer is Composio's action infrastructure for knowledge work agents: the system that takes a planned task, resolves the right tool and the right credential, executes the call with the correct permission scope, and logs a verifiable record of the outcome. Composio's self-learning layer distills skills from more than 300 million tool calls per month, making repeat tasks 30% more accurate on 2x fewer tokens. Tool Router routes each request to the correct toolkit based on your authenticated connections, removing conditional routing logic from agent code. That efficiency gain applies whether the binary runs on Composio Cloud or inside your own VPC: the governed execution path and the tool-call accuracy are the same in both deployments.

Implementing Composio under policy control

Composio's policy-as-code engine in the self-hosted gateway evaluates access restrictions before any model interaction. An admin sets permitted actions per user or role through the dashboard, and Composio evaluates those restrictions in the request path before the outbound API call is made.

Managing self-hosted gateway compliance

Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications for its managed platform architecture. Your compliance team should verify that the deployment configuration you implement meets your specific audit requirements, and Composio provides documentation to assist with that process.

Configuring policy-as-code in self-hosted gateways

Payload retention and the ZDR add-on

On Composio Cloud, payload non-retention is available as Zero Data Retention (ZDR), a Pro-tier and above add-on that stops Composio from retaining request and response payloads, billed at $0.0001 per tool call and $0.0005 per trigger event. It is not enabled by default. For self-hosted and VPC deployments, your team controls the storage infrastructure directly, which means you configure where payloads are written, whether they are written at all, and how retention is enforced, without depending on an add-on. In both cases, Composio resolves the encrypted credential inside an isolated runtime, injects it into the outbound HTTP request, and returns the response to the calling agent. The credential itself does not appear in application code, LLM context, or agent memory at any point in the request lifecycle.

Restricting audit logs to metadata

Audit records capture the actor, the tool, the action, the policy decision, and the outcome, as shown in the JSON sample above. Audit records capture the parameters that identify the specific resource and operation, as shown in the owner and repo fields in the JSON sample above. Request and response payload content is not retained in the audit record.

Defining custom data residency windows

Administrators configure the audit log retention window through the Enterprise dashboard. For self-hosted deployments, you configure where logs are written and how retention is enforced within your own infrastructure, allowing you to align the retention period directly with whichever compliance framework applies.

SOC 2 Type II and ISO/IEC 27001:2022

Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications. Composio's credential isolation uses AES-256 encryption. Tokens resolve inside the gateway's isolated runtime and do not appear in application code, LLM context, or agent memory.

Managing audit and auth in self-hosted environments

Licensing terms for self-hosted MCP

The self-hosted gateway and private VPC deployment options are available exclusively at the Enterprise tier. Free and Pro tiers run on Composio Cloud. If your constraint is data residency or network boundary, the Enterprise tier is the correct starting point.

Operational burden of self-hosting

Composio's managed connector layer absorbs upstream API schema changes, including additions or removals of tools and updated tool definitions, without requiring custom code changes on your end. For self-hosted deployments, your team manages the host infrastructure including OS and container runtime patching, network connectivity monitoring, scaling as tool-call volume grows, and maintaining encryption key storage.

Transitioning from self-hosted to managed

If your compliance requirements change, for example if a data-residency constraint is resolved through a DPA amendment, transitioning from a self-hosted deployment to Composio Cloud preserves your integration configuration. Tool definitions and policy configurations can migrate to the managed environment, though user authentication will need to be re-established during the transition.

The Assista AI case study shows Gmail, Calendar, GitHub, and Drive integrations shipped live in production within days using Composio, and the Zams case study covers Salesforce, HubSpot, Notion, and Slack on a B2B RevOps platform. Both teams avoided building the auth layer themselves, which is the variable that most directly determines time-to-production across deployment modes.

Your deployment choice depends on whether your constraint is geographic, network-boundary-based, or audit-driven. Book a technical architecture call to review your VPC deployment requirements before your next enterprise security review, or download pre-filled compliance documentation from the trust center to prepare your audit evidence library now.

FAQs

What compliance certifications does Composio hold?

Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications.

What is the standard audit log retention period for the self-hosted gateway?

Retention is configurable through the Enterprise dashboard. For self-hosted deployments, logs are written to your own database inside your VPC with metadata only, keeping tool-call payloads off disk, and your team controls the retention period and export format to match your specific compliance requirements.

Does the self-hosted gateway expose credentials to the LLM context?

No. Composio resolves credentials inside an isolated runtime within the gateway, injects them into the outbound HTTP request, and returns the response. The LLM context and application code never receive the raw credential at any point in the request lifecycle.

What happens when an upstream API changes its authentication method?

Composio's managed connector layer absorbs upstream API changes, including authentication method updates, schema changes, and tool definition modifications, without requiring you to rewrite custom integration code. When you own the integration layer yourself, each upstream provider change lands directly on your engineering team's calendar.

What does the 11x case study show about integration engineering costs?

The 11x case study documents approximately 380 engineering hours saved by using managed integration infrastructure rather than building OAuth and credential handling in-house. That figure represents the execution layer, the system connecting credentials, policies, and audit records, when built from scratch.

Key terms glossary

Least privilege: A security principle enforcing that an AI agent holds only the minimum API permissions required to complete its assigned task, preventing unauthorized actions regardless of what the agent prompt requests.

Policy-as-code: Access controls evaluated programmatically in the request path before the LLM is involved, ensuring security rules cannot be bypassed by prompt injection or model reasoning.

Credential isolation: An architectural design where API tokens are stored in an encrypted vault and resolved inside an isolated runtime, keeping them hidden from both the LLM context and application code throughout the request lifecycle.

Transport translation: The process where a gateway converts local stdio communication from an MCP server into SSE or HTTP Streamable protocols for external network routing, enabling remote deployment of MCP servers beyond a single local process.

Schema drift: An unplanned, uncoordinated change to a source system's data structure that downstream pipelines are not prepared for, commonly caused by upstream API versioning, field renaming, or authentication method deprecation.