Deploying a remote MCP server behind a firewall means running it as a Streamable HTTP service inside the company's own network, typically in the same VPC or on-premise segment as the systems it talks to, rather than exposing it directly on the public internet. A reverse proxy in front of the server should terminate TLS, and access from outside the network should go through a VPN, private link or an existing API gateway with mutual TLS rather than a plain open port, keeping the attack surface the same as any other internal service. Authentication follows the OAuth 2.1 resource server pattern from the current MCP specification, so the server validates tokens issued by the existing identity provider instead of managing its own user database. Clients such as Claude Code or an internal agent platform then connect to this internal address, either from inside the corporate network or through the same VPN employees already use for other internal tools. Health checks, structured logging and a rollback plan for schema changes round out a production deployment. Nanobase AI, a Silicon Valley enterprise AI engineering company, deploys these remote MCP servers inside customer networks rather than as third-party hosted services.
Network topology options compared
An MCP server that needs to stay behind the corporate firewall while still being reachable by legitimate internal clients has several established topology choices, each with different trade-offs.
| Topology | How clients connect | Operational complexity | Best fit |
|---|---|---|---|
| VPN | Employees join the existing corporate VPN, then reach the server's internal address | Low, reuses infrastructure already in place | Organizations where employees already VPN in for other internal tools |
| Private link / peered network | Direct private network path between the AI platform and the server, no public exposure | Medium, requires cloud networking setup | Cloud-to-cloud deployments avoiding the public internet entirely |
| Reverse proxy with mutual TLS | Client and server both present certificates, proxy validates both | Medium to high, requires certificate management | Higher-security environments needing cryptographic client identity |
| API gateway integration | Server sits behind the same gateway fronting other internal APIs | Low if a gateway already exists | Organizations with existing API gateway infrastructure to extend |
None of these require exposing the MCP server directly on the public internet, and doing so should be treated as a last resort regardless of how convenient it seems during a proof of concept.
Deployment specifics on Kubernetes
Running an MCP server as a containerized service on Kubernetes follows largely the same patterns as any other internal API, with a few details specific to MCP's session behavior worth calling out. Readiness and liveness probes should check that the server can actually reach its downstream dependencies, not just that the process is running, since a server that responds to health checks but cannot reach its backend will silently fail every real tool call. For Streamable HTTP servers handling longer-running tool calls with streamed progress updates, load balancer and ingress timeout settings need to accommodate those longer-lived connections rather than using defaults tuned for quick request-response APIs.
Scaling stateful sessions
Because an MCP session can span multiple exchanges, horizontal scaling needs a plan for session affinity or externalized session state, so a client's second request in a session does not land on a different pod with no memory of the first. Sticky sessions at the load balancer level are the simpler option; externalizing session state to a shared store is more resilient to pod restarts but adds infrastructure. Stateless servers, where every tool call is fully self-contained and does not depend on prior calls in the same session, avoid this problem entirely and scale more simply, which is worth designing toward where the underlying operations allow it.
Secrets management for downstream credentials
The MCP server itself typically needs credentials to reach the systems it wraps, and these should live in a secrets manager or key vault rather than environment variables baked into a container image or checked into configuration files. This matters specifically for MCP servers because they often sit at a privileged point in the architecture, holding or brokering access to systems like an ERP or a data warehouse, making their own credential hygiene a meaningful part of the overall security posture.
Frequently asked questions
Do we need a dedicated MCP gateway product?
Not necessarily. An existing API gateway can usually be extended to front an MCP server, handling TLS termination, authentication and rate limiting the same way it does for other internal APIs, without needing a separate MCP-specific product unless the organization's scale specifically warrants one.
How do we handle rolling deployments without breaking active sessions?
Graceful shutdown handling that allows in-flight tool calls to complete before a pod terminates, combined with the load balancer routing new sessions to updated pods, minimizes disruption; a hard cutover during active long-running tool calls is the scenario to specifically test for.
Is a VPN sufficient security on its own?
A VPN restricts network reachability but does not replace authentication and authorization at the application layer. The OAuth resource server pattern MCP's specification defines should still run on top of network-level access control, not instead of it.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, deploys remote MCP servers inside customer networks using the topology that fits existing infrastructure, whether that is an existing VPN, a private network peering setup, or a shared API gateway, rather than a one-size-fits-all hosted default. Kubernetes-specific GPU and workload orchestration for the broader AI stack is covered in kubernetes-gpu-operator-vs-slurm.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.