Hospedagem de Servidores MCP: Onde Executar Seus Servidores MCP na Prática

What “hosting an MCP server” actually means

An MCP server is a process. That is the whole thing. Model Context Protocol defines how a client discovers and calls tools on that process, but says nothing about where it lives or who keeps it alive. That leaves a plain infrastructure question, and it splits on transport.

Stdio servers speak MCP over standard input and standard output. They are CLI-style programs, usually started by the client itself with npx or uvx. No port, no URL, no network listener — the client spawns a child process on the same machine and talks to it through pipes.

HTTP/SSE servers expose HTTP endpoints directly. They listen on a port and behave like any other web service you already know how to operate.

The TrueFoundry docs draw the same line with a consequence: HTTP servers deploy without additional wrappers, while stdio servers must be wrapped with mcp-proxy to convert stdio to HTTP. The docs are also blunt about which to write if you are starting fresh — HTTP-based servers are recommended as more secure and easier to deploy.

The three hosting options, honestly

Option 1 — Local stdio on a laptop

Where nearly everyone starts, and correct for one person. You paste a block into your Cursor or Claude config, the client spawns npx -y @some/mcp-server on demand, and the API key sits in an env map below.

It works well. It also does not survive contact with a team. There is no URL to share. Credentials are distributed by copy-paste. Every developer runs their own copy, so each is a separate install that can drift to a different version. And nothing centrally records which tool was called by whom, because the call never crossed a network boundary you control. Local stdio is a development mode, not a hosting strategy.

Option 2 — A vendor’s managed cloud

Some MCP servers are offered as hosted endpoints by their maintainers, and some gateway vendors run servers on your behalf in their own cloud. You get a URL and skip the infrastructure.

This is the fastest path, and for public, read-only, low-sensitivity servers usually the right one. The trade-off is where the process runs. A hosted server that queries your internal systems means either opening those systems to a vendor’s egress ranges, or pushing credentials to infrastructure you do not control. For anything reading a production database, that is often the end of the conversation.

Option 3 — Self-hosting on your own infrastructure

You run the process on your own Kubernetes cluster, in your own VPC, behind your own network policy. This is what teams reach for once the server touches anything internal.

Self-hosting is not hard in the way people expect. An MCP server is a small stateless HTTP service, and every platform team already knows how to run those. The work that shows up is the surrounding layer: a stable URL, deciding who can call it, injecting credentials without baking them into an image, and recording what happened.

What changes the moment it stops being local

Moving a server off a laptop is not a lift-and-shift. Four things appear that the laptop never needed, beyond the obvious stable URL.

Bind address. A stdio server never binds anything. An HTTP one must bind 0.0.0.0, not localhost, or it starts cleanly inside its container and is unreachable from the rest of the cluster. The docs carry a warning about this, which tells you how often it bites.

Auth in two directions. Locally there was one credential — your key, in your config. Remotely: how does a caller prove itself to the server, and how does the server prove itself to whatever it calls downstream? Separate problems, separate answers.

Concurrency and resources. One process served one client. Now it serves a team, and you are setting CPU and memory requests, limits, and replica counts like any other service.

Egress. The server now makes outbound calls from inside your network rather than a laptop on the office wifi. That is usually the point, but it makes the server’s network position a security decision rather than an accident.

Where teams get MCP server hosting wrong

Every developer still runs their own copy. The most common failure is not technical. The local config never gets retired, so half the team is on the gateway URL and half is still spawning npx locally with a personal token. That is not centralization; it is a second path.

Tokens in args instead of env. Moving a stdio command into a manifest, it is tempting to inline the token where it sat in the CLI invocation. The docs are explicit: never put tokens in args, because arguments are stored in plain text in the manifest and can appear in process listings. Credentials belong in environment variables backed by a secret store.

Unpinned packages. npx -y some-package resolves to whatever is latest at container start, so two replicas started a week apart can run different tool sets. Pin explicit versions in args.

Treating the URL as the finish line. A deployed server with no access control is a tool endpoint anyone inside the network can call. Hosting solved reachability, not who is allowed to reach it — the harder half.

Skip the plumbing.

Deploy an MCP server on your own cluster and put a governed URL in front of it in one sitting.

Get started free

How MCP server hosting works on TrueFoundry

TrueFoundry’s position is that hosting and governance should be one system rather than two. The server deploys as an ordinary service on your own Kubernetes cluster — same workspaces, secrets, autoscaling, and logs as every other workload — then registers behind the MCP Gateway, which owns the URL, the auth, and the access model. Three routes in, depending on where you start.

Route 1 — From source code

Use this when you wrote the server yourself or are deploying from a repository you can build.

It is a standard service deployment: Deployments → New Deployment → Service, pick your workspace, then choose Git Repo or Code From Laptop as the source. For a Python HTTP server built with FastMCP and no Dockerfile, the config is a build context path, a requirements.txt path, a Python version, the command (python server.py), and port 8000.

If your source is a stdio server, wrap it. The recommended path is a Dockerfile that installs mcp-proxy and sets a CMD like mcp-proxy --port 8000 --host 0.0.0.0 --server stream python server.py. To skip the Dockerfile, use the Python Build option, declare mcp-proxy as a dependency, and set the same command directly:

Port config is the same either way: port 8000, protocol TCP, app protocol http, expose set to false if the service should only be reachable inside the cluster. Sensitive values go in TrueFoundry Secrets, referenced as tfy-secret://your-workspace:your-secret-group:API_KEY.

Route 2 — From an npx or uvx package

Use this when the server exists as a published package and you have no reason to modify it — the direct translation of the block sitting in your Cursor config today. Both variants deploy from a Docker image, with the command doing the work.

For npm packages, the base image is node:24 and the command is:

npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y <package-name>

The first npx -y mcp-proxy installs and runs the proxy; the second runs your server package. So a Notion server becomes npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server.

For Python packages, the base image is public.ecr.aws/docker/library/python:3.11-slim and the command installs the tooling first:

sh -c "pip install uv mcp-proxy && mcp-proxy --host=0.0.0.0 --port=8000 uvx <package-name>"

Deploy from Docker Image form with python:3.11-slim base image and mcp-proxy wrapping a uvx MCP package

Environment variables carry over unchanged from your local config — NOTION_API_KEY, GITHUB_TOKEN — with sensitive ones moved into Secrets. One expectation to set: the first startup is slow while npx or uvx downloads the package. If cold starts matter, pre-install it in a custom image.

Route 3 — Hosted stdio, run by the gateway

A third path skips the service deployment entirely: rather than you wrapping a stdio server and deploying it, the gateway runs the process and exposes it at the same URL it uses for remote servers. From MCP Servers → Add Server, pick Hosted Stdio-based MCP Server:

You supply a command, arguments, and environment variables, or paste editor-style JSON — the same single-entry mcpServers shape from Cursor or VS Code — and the form fills itself in. The filesystem reference server is command: npx with args -y, @modelcontextprotocol/server-filesystem, /tmp.

The gateway runs it through the mcp-proxy library in a sandboxed environment in stateless mode, and clients connect over streamable HTTP POST. Environment variables can be global (everyone shares the downstream credential) or per-user, where a value carries exactly one templatized placeholder resolved from that caller’s Auth Overrides. One caveat: the docs recommend this path for local development in IDEs — the fastest way to get a shared, governed URL over a CLI-style server, not the pattern for a high-volume production workload.

Then register it behind the gateway

However the server got deployed, the last step is the same. Take the service endpoint URL, go to Add Server → Connect any Remote MCP Server, and provide a name, description, URL, collaborators, and auth data.

Inbound access control attaches here. Collaborators are users or teams, with MCP Server Manager for full configuration rights and MCP Server User for invoking tools without changing settings:

Outbound auth — how the gateway proves itself to the server you deployed — is one of API Key, OAuth2, AWS SigV4, or Token Passthrough. API Key splits into Shared Credentials, onde uma chave serve a todos, e Credenciais Individuais, onde o valor do cabeçalho contém um placeholder como Bearer {{API_KEY}} e cada usuário fornece o seu próprio por meio de Substituições de Autenticação (Auth Overrides):

Para um servidor que você mesmo hospeda, credenciais compartilhadas geralmente são adequadas — a decisão de acesso já ocorreu no gateway. Para qualquer coisa que exponha dados por usuário, o OAuth2 é a recomendação documentada para produção: ele suporta escopos, os usuários podem revogar sua própria autorização e o acesso é limitado ao que cada usuário tem permissão para ver.

Configuração de OAuth2 para um servidor MCP com tipos de concessão Authorization Code e Client Credentials

Uma vez registrado, as ferramentas aparecem e podem ser invocadas a partir do Playground:

Um exemplo prático: aposentando as cópias locais

Oito desenvolvedores têm o bloco npx do Notion na configuração do Cursor, cada um com uma chave pessoal do Notion. Você quer uma cópia hospedada.

Passo 1 — Implante-o. Nova Implantação → Serviço → Implantar a partir de Imagem Docker, imagem base node:24, comando npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server, porta 8000, protocolo TCP, protocolo de aplicativo http. Fixe a versão do pacote. Coloque NOTION_API_KEY em Segredos, não no campo de ambiente como texto simples.

Passo 2 — Verifique-o. Aguarde por DEPLOY_SUCCESS, anote a URL do endpoint do serviço e faça um curl nela. Ela deve responder com mensagens do protocolo MCP via HTTP. Fazer isso antes de registrar qualquer coisa separa "o contêiner não inicia" de "o gateway não consegue alcançá-lo", que são tardes muito diferentes.

Passo 3 — Registre-o. Adicionar Servidor → Conectar qualquer Servidor MCP Remoto, cole a URL do endpoint, dê um nome a ele, adicione a equipe de engenharia como Usuário do Servidor MCP e você mesmo como MCP Server Manager, então configure os dados de autenticação.

Passo 4 — Distribua a URL do gateway.OComo Usar a aba possui snippets de conexão específicos para o tenant para Cursor, VS Code, Claude Code, Windsurf, Codex e os SDKs de Python e TypeScript, além de um Adicionar MCP ao Cursor botão que escreve a configuração para o desenvolvedor.

Passo 5 — Exclua os blocos locais. O passo que as equipes ignoram, e o único que faz os outros quatro valerem a pena. Enquanto as entradas npx não forem removidas da configuração de todos, você estará executando nove cópias, não uma.

O que você ganha: uma versão do servidor, credenciais em um cofre de segredos em vez de oito laptops, visibilidade por ferramenta e a capacidade de desativar ferramentas centralmente, em vez de ter que pedir gentilmente para as pessoas.

Ready to host your first one?

Deploy from a repo, an npx package, or a stdio command, and put it behind a governed URL.

Start free on TrueFoundry

Pontos de atenção importantes

Uma instalação travada parece um servidor travado. Para servidores stdio hospedados, uma falha na instalação do pacote não aparece como um erro — o servidor fica em mcp_server_starting indefinidamente, porque o gerenciador de pacotes nunca passa o controle para o processo MCP. Causas comuns: uma URL git sem uma referência fixa, credenciais incorporadas em uma URL de pacote npm (o npm as normaliza e remove) ou um download parcial que corrompe o cache do npx após uma primeira execução interrompida. Alterar algo nos args redefine o sandbox e inicia do zero.

Notificações fora de um fluxo de resposta são descartadas. O gateway executa servidores stdio em modo stateless, portanto, notificações iniciadas pelo servidor fora do fluxo de resposta de uma solicitação não são entregues. Verifique a matriz de suporte do protocolo antes de portar um servidor que envia mensagens não solicitadas.

O endereço de bind vai te pegar uma vez. Vincular ao localhost cria um contêiner que inicia, passa em seu próprio teste de integridade, mas fica invisível para o cluster. Cada comando de wrap stdio na documentação inclui --host 0.0.0.0 exatamente por esse motivo.

Cold starts são reais no npx/uvx. O pacote é baixado na inicialização do contêiner — tudo bem para um servidor voltado ao desenvolvimento, irritante para qualquer coisa sensível à latência.

Leituras relacionadas

• O que é um Gateway MCP — a camada à frente de qualquer coisa que você hospede
• Servidor MCP do Slack — um servidor de terceiros e como ele é governado
• Servidor MCP do Datadog — o padrão aplicado a ferramentas de observabilidade
• Servidor MCP do Snowflake — onde dados privados tornam a auto-hospedagem o padrão
• Servidor MCP virtual explicado — agrupando ferramentas de vários servidores hospedados em um único endpoint

Conclusão

A hospedagem de servidores MCP não é um problema exótico. É o desafio familiar de pegar um processo que funciona em um laptop e transformá-lo em um serviço no qual uma equipe possa confiar — com uma URL, uma identidade, limites de recursos, segredos e um registro do que aconteceu.

O que torna esse trabalho cuidadoso algo que vale a pena é que um servidor MCP é um endpoint de ferramenta. A acessibilidade sem controle de acesso não é uma conquista; é uma exposição. Implantar em seu próprio Kubernetes e registrar atrás de um gateway na mesma plataforma unifica as duas metades em uma única tarefa: o processo é executado onde sua política de rede já se aplica, e a URL que o precede já sabe quem está chamando.

Deploy and govern your first MCP server on TrueFoundry

Free to start