MCP Server Hosting: Waar je je MCP Servers Daadwerkelijk Draait

Wat "het hosten van een MCP server" daadwerkelijk betekent

Een MCP server is een proces. Dat is alles. Het Model Context Protocol definieert hoe een client tools op dat proces ontdekt en aanroept, maar zegt niets over waar het zich bevindt of wie het actief houdt. Dat laat een eenvoudige infrastructuurvraag over, en die splitst zich op basis van transport.

Stdio-servers spreken MCP via standaardinvoer en standaarduitvoer. Het zijn CLI-achtige programma's, meestal gestart door de client zelf met npx of uvx. Geen poort, geen URL, geen netwerklistener — de client start een child-proces op dezelfde machine en communiceert ermee via pipes.

HTTP/SSE-servers stellen direct HTTP-endpoints beschikbaar. Ze luisteren op een poort en gedragen zich zoals elke andere webservice die je al weet te beheren.

De documentatie van TrueFoundry trekt dezelfde lijn met een duidelijke consequentie: HTTP-servers worden zonder extra wrappers geïmplementeerd, terwijl stdio-servers moeten worden omhuld met mcp-proxy om stdio naar HTTP te converteren. De documentatie is ook duidelijk over wat je moet schrijven als je opnieuw begint — HTTP-gebaseerde servers worden aanbevolen omdat ze veiliger zijn en eenvoudiger te deployen.

De drie hostingopties, eerlijk vergeleken

Optie 1 — Lokale stdio op een laptop

Waar bijna iedereen begint, en de juiste keuze voor één persoon. Je plakt een blok in je Cursor- of Claude-configuratie, de client start on-demand npx -y @some/mcp-server, en de API-key staat in een env-map eronder.

Het werkt goed. Het is alleen niet bestand tegen samenwerking in een team. Er is geen URL om te delen. Credentials worden verspreid via kopiëren en plakken. Elke ontwikkelaar draait zijn eigen instantie, dus elke installatie is afzonderlijk en kan afwijken naar een andere versie. En niets registreert centraal welke tool door wie is aangeroepen, omdat de aanroep nooit een netwerkgrens overschrijdt die je beheert. Lokale stdio is een ontwikkelmodus, geen hostingstrategie.

Optie 2 — De beheerde cloud van een vendor

Sommige MCP servers worden door hun beheerders aangeboden als gehoste endpoints, en sommige gateway-vendors draaien servers namens jou in hun eigen cloud. Je krijgt een URL en hoeft de infrastructuur niet te beheren.

Dit is de snelste route, en voor openbare, read-only servers met een lage gevoeligheid meestal de juiste. De afweging is waar het proces draait. Een gehoste server die query's uitvoert op je interne systemen betekent dat je die systemen moet openstellen voor het IP-bereik van de vendor, of dat je credentials moet sturen naar infrastructuur die je niet beheert. Voor alles wat een productiedatabase leest, is dat vaak het einde van het gesprek.

Optie 3 — Self-hosting op je eigen infrastructuur

Je draait het proces op je eigen Kubernetes-cluster, in je eigen VPC, achter je eigen netwerkbeleid. Dit is waar teams naar grijpen zodra de server in aanraking komt met interne systemen.

Self-hosting is niet zo ingewikkeld als men verwacht. Een MCP server is een kleine stateless HTTP-service, en elk platformteam weet al hoe ze die moeten beheren. Het werk zit in de omliggende laag: een stabiele URL, bepalen wie deze mag aanroepen, credentials injecteren zonder ze in een image op te nemen, en vastleggen wat er is gebeurd.

Wat er verandert zodra het niet meer lokaal draait

Het verplaatsen van een server vanaf een laptop is geen simpele lift-and-shift. Naast de voor de hand liggende stabiele URL verschijnen er vier zaken die op de laptop nooit nodig waren.

Bind-adres. Een stdio-server bindt nooit iets. Een HTTP-server moet binden aan 0.0.0.0, niet aan localhost, anders start hij weliswaar correct binnen zijn container, maar is hij onbereikbaar voor de rest van het cluster. De documentatie bevat hier een waarschuwing over, wat aangeeft hoe vaak dit fout gaat.

Authenticatie in twee richtingen. Lokaal was er één credential — jouw sleutel, in jouw configuratie. Op afstand: hoe bewijst een requester zich tegenover de server, en hoe bewijst de server zich tegenover de downstream-services die hij aanroept? Afzonderlijke problemen, afzonderlijke oplossingen.

Concurrency en resources. Eén proces bediende één client. Nu bedient het een heel team, en stel je CPU- en geheugenrequests, limits en replica-aantallen in, net zoals bij elke andere service.

Egress. De server doet nu uitgaande aanroepen vanuit je interne netwerk in plaats van vanaf een laptop op de kantoor-wifi. Dat is meestal de bedoeling, maar het maakt de netwerkpositie van de server een beveiligingsbeslissing in plaats van een bijkomstigheid.

Waar teams de fout ingaan bij MCP server hosting

Elke ontwikkelaar draait nog steeds zijn eigen instantie. De meest voorkomende fout is niet technisch. De lokale configuratie wordt nooit uitgefaseerd, waardoor de helft van het team de gateway-URL gebruikt en de andere helft nog steeds lokaal npx gebruikt met een persoonlijke token. Dat is geen centralisatie; het is een tweede parallelle route.

Tokens in args in plaats van env. Bij het omzetten van een stdio-commando naar een manifest is het verleidelijk om het token direct in tevoegen op de plek waar het in de CLI-aanroep stond. De documentatie is hier duidelijk over: zet tokens nooit in args, omdat argumenten als leesbare tekst in het manifest worden opgeslagen en in proceslijsten kunnen verschijnen. Credentials horen thuis in omgevingsvariabelen die gekoppeld zijn aan een secret store.

Niet-vastgepinde packages. npx -y some-package verwijst naar de meest recente versie op het moment dat de container start, waardoor twee replica's die met een week tussenpoos zijn gestart, verschillende toolsets kunnen draaien. Zet expliciete versies vast in de args.

De URL zien als het eindpunt. Een gedeployde server zonder toegangsbeheer is een tool-endpoint dat iedereen binnen het netwerk kan aanroepen. Hosting lost de bereikbaarheid op, maar niet wie er toegang tot hoort te krijgen — het moeilijkste gedeelte.

Sla het handmatige configuratiewerk over.

Deploy een MCP server op je eigen cluster en plaats er direct een beheerde URL voor.

Gratis aan de slag

Hoe MCP server hosting werkt op TrueFoundry

Het uitgangspunt van TrueFoundry is dat hosting en governance één systeem moeten vormen in plaats van twee. De server wordt geïmplementeerd als een normale service op je eigen Kubernetes-cluster — met dezelfde workspaces, secrets, autoscaling en logs als elke andere workload — en wordt vervolgens geregistreerd achter de MCP Gateway, die de URL, de authenticatie en het toegangsmodel beheert. Er zijn drie routes mogelijk, afhankelijk van je uitgangspunt.

Route 1 — Vanuit broncode

Gebruik dit wanneer je de server zelf hebt geschreven of deployt vanuit een repository die je kunt bouwen.

Het is een standaard service-deployment: Deployments → New Deployment → Service, kies je workspace en selecteer vervolgens Git Repo of Code From Laptop als bron. Voor een Python HTTP-server gebouwd met FastMCP en zonder Dockerfile, bestaat de configuratie uit een build context path, een requirements.txt-pad, een Python-versie, het commando (python server.py) en poort 8000.

Als je broncode een stdio-server is, moet je deze omhullen. De aanbevolen route is een Dockerfile die mcp-proxy installeert en een CMD instelt zoals mcp-proxy --port 8000 --host 0.0.0.0 --server stream python server.py. Om de Dockerfile over te slaan, gebruik je de Python Build-optie, declareer je mcp-proxy als dependency en stel je hetzelfde commando rechtstreeks in:

De poortconfiguratie is in beide gevallen hetzelfde: poort 8000, protocol TCP, app-protocol http, expose ingesteld op false als de service alleen binnen het cluster bereikbaar moet zijn. Gevoelige waarden gaan in TrueFoundry Secrets, waarnaar wordt verwezen als tfy-secret://your-workspace:your-secret-group:API_KEY.

Route 2 — Vanuit een npx- of uvx-package

Gebruik dit wanneer de server bestaat als een gepubliceerd package en je geen reden hebt om deze te wijzigen — de directe vertaling van het blok dat nu in je Cursor-configuratie staat. Beide varianten worden geïmplementeerd vanuit een Docker image, waarbij het commando het werk doet.

Voor npm-packages is de base image node:24 en het commando is:

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

De eerste npx -y mcp-proxy installeert en draait de proxy; de tweede draait je serverpackage. Dus een Notion-server wordt npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server.

Voor Python-packages is de base image public.ecr.aws/docker/library/python:3.11-slim en het commando installeert eerst de tooling:

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

Formulier voor Deploy from Docker Image met python:3.11-slim base image en mcp-proxy die een uvx MCP-package omhult

Omgevingsvariabelen worden ongewijzigd overgenomen uit je lokale configuratie — NOTION_API_KEY, GITHUB_TOKEN — waarbij gevoelige variabelen worden verplaatst naar Secrets. Houd rekening met het volgende: de eerste opstart is traag omdat npx of uvx het package moet downloaden. Als cold starts een rol spelen, installeer het package dan vooraf in een custom image.

Route 3 — Gehoste stdio, uitgevoerd door de gateway

Een derde route slaat de service-deployment volledig over: in plaats van dat jij een stdio-server omhult en deployt, draait de gateway het proces en stelt het beschikbaar op dezelfde URL die het gebruikt voor remote servers. Kies via MCP Servers → Add Server voor Hosted Stdio-based MCP Server:

Je geeft een command, arguments en environment variables op, of plakt editor-style JSON — dezelfde structuur als mcpServers uit Cursor of VS Code — waarna het formulier zichzelf invult. De reference server voor het bestandssysteem gebruikt bijvoorbeeld command: npx met args -y, @modelcontextprotocol/server-filesystem, /tmp.

De gateway voert dit uit via de mcp-proxy-bibliotheek in een geisoleerde omgeving in stateless mode, en clients maken verbinding via streamable HTTP POST. Omgevingsvariabelen kunnen global zijn (iedereen deelt dezelfde downstream-credential) of per-user, waarbij een waarde precies één sjabloon-placeholder bevat die wordt opgelost via de Auth Overrides van die specifieke requester. Eén kanttekening: de documentatie raadt deze route aan voor lokale ontwikkeling in IDE's — het is de snelste manier om een gedeelde, beheerde URL boven een CLI-achtige server te krijgen, maar niet het patroon voor een hoog-volume productie-workload.

Vervolgens registreren achter de gateway

Hoe de server ook is geïmplementeerd, de laatste stap is hetzelfde. Neem de URL van het service-endpoint, ga naar Add Server → Connect any Remote MCP Server, en vul een naam, beschrijving, URL, collaborators en authenticatiegegevens in.

Inkomend toegangsbeheer wordt hier ingesteld. Collaborators zijn gebruikers of teams, met de rol MCP Server Manager voor volledige configuratierechten en MCP Server User voor het aanroepen van tools zonder de instellingen te kunnen wijzigen:

Uitgaande authenticatie — hoe de gateway zich authenticeert bij de door jou gedeployde server — kan worden ingesteld via API Key, OAuth2, AWS SigV4 of Token Passthrough. API Key is onderverdeeld in Shared Credentials, waarbij één sleutel voor iedereen geldt, en Individual Credentials, waarbij de header-waarde een placeholder bevat zoals Bearer {{API_KEY}} en elke gebruiker zijn eigen sleutel opgeeft via Auth Overrides:

Voor een server die je zelf host, zijn shared credentials vaak voldoende — de beslissing over toegang is immers al genomen bij de gateway. Voor alles wat toegang geeft tot persoonsgebonden gegevens is OAuth2 de officieel aanbevolen productiestandaard: het ondersteunt scopes, gebruikers kunnen hun eigen autorisatie intrekken en de toegang blijft beperkt tot wat elke specifieke gebruiker mag zien.

OAuth2-configuratie voor een MCP server met het Authorization Code- en Client Credentials-granttype

Zodra de registratie is voltooid, verschijnen de tools en kunnen ze worden aangeroepen vanuit de Playground:

Een praktijkvoorbeeld: de lokale instanties uitfaseren

Acht ontwikkelaars hebben allemaal het Notion npx-blok in hun Cursor-configuratie staan, elk met een persoonlijke Notion-sleutel. Je wilt overstappen naar één gehoste instantie.

Stap 1 — Deploy het. New Deployment → Service → Deploy from Docker Image, base image node:24, commando npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server, poort 8000, protocol TCP, app-protocol http. Zet de packageversie vast. Plaats NOTION_API_KEY in Secrets, niet als platte tekst in het env-veld.

Stap 2 — Controleer het. Wacht op DEPLOY_SUCCESS, noteer de URL van het service-endpoint en voer een curl-commando uit. Het endpoint moet reageren met MCP-protocolberichten via HTTP. Door dit te doen voordat je iets registreert, scheid je "de container start niet" van "de gateway kan er niet bij", wat totaal verschillende problemen zijn.

Stap 3 — Registreer het. Add Server → Connect any Remote MCP Server, plak de URL van het endpoint, geef het een naam, voeg het engineeringteam toe als MCP Server User en jezelf als MCP Server Manager, en configureer vervolgens de authenticatiegegevens.

Stap 4 — Deel de gateway-URL. Het tabblad How To Use bevat tenant-specifieke verbindingssnippets voor Cursor, VS Code, Claude Code, Windsurf, Codex, en de Python- en TypeScript-SDK's, plus een knop Add MCP to Cursor die de configuratie direct voor de ontwikkelaar instelt.

Stap 5 — Verwijder de lokale blokken. Dit is de stap die teams vaak vergeten, maar die de voorgaande vier stappen pas echt waardevol maakt. Zolang de npx-vermeldingen niet uit ieders configuratie zijn verwijderd, draai je nog steeds negen instanties in plaats van één.

Het resultaat: één versie van de server, credentials in een secret store in plaats van op acht losse laptops, inzicht per tool, en de mogelijkheid om tools centraal uit te schakelen in plaats van dit aan iedereen los te moeten vragen.

Klaar om je eerste server te hosten?

Deploy vanuit een repo, een npx-package of een stdio-commando, en plaats het achter een beheerde URL.

Start gratis op TrueFoundry

Aandachtspunten die goed zijn om te weten

Een vastgelopen installatie lijkt op een vastgelopen server. Bij gehoste stdio-servers wordt een mislukte package-installatie niet getoond als een expliciete foutmelding — de server blijft onbeperkt op mcp_server_starting staan, omdat de package manager de overdracht naar het MCP-proces nooit voltooit. Veelvoorkomende oorzaken: een Git-URL zonder vastgepinde ref, credentials verwerkt in een npm-package-URL (npm verwijdert deze automatisch), of een gedeeltelijke download die de npx-cache verstoort na een onderbroken eerste run. Het aanpassen van argumenten reset de sandbox en zorgt voor een schone start.

Notificaties buiten een response stream worden niet verwerkt. De gateway draait stdio-servers in stateless mode, waardoor losstaande notificaties die door de server worden geïnitieerd buiten de response stream van een verzoek niet worden afgeleverd. Controleer de protocol-ondersteuningsmatrix voordat je een server migreert die ongevraagde berichten verstuurt.

Het bind-adres kan voor problemen zorgen. Binden aan localhost leidt tot een container die wel opstart en zijn eigen health check doorstaat, maar onzichtbaar blijft voor het cluster. Elk commando voor het omhullen van stdio in de documentatie bevat niet voor niets --host 0.0.0.0.

Cold starts zijn merkbaar bij npx/uvx. Het package wordt gedownload tijdens het opstarten van de container — wat acceptabel is voor een server die gebruikt wordt voor ontwikkeling, maar storend voor latency-gevoelige toepassingen.

Gerelateerde artikelen

• What Is an MCP Gateway — de laag die zich bevindt voor alles wat je host
• Slack MCP Server — een server van een derde partij en de manier waarop deze wordt beheerd
• Datadog MCP Server — het patroon toegepast op observability-tooling
• Snowflake MCP Server — situaties waarin besloten data self-hosting de standaard maakt
• Virtual MCP Server Explained — het combineren van tools uit meerdere gehoste servers tot één endpoint

Conclusie

Het hosten van een MCP server is geen uitzonderlijk complex probleem. Het is de bekende taak om een proces dat op een laptop werkt, te transformeren naar een betrouwbare service voor een heel team — met een URL, een identiteit, resource limits, secrets en een gedetailleerde historie van wat er is gebeurd.

Wat dit traject belangrijk maakt, is dat een MCP server fungeert als een functionaliteits-endpoint. Bereikbaarheid zonder toegangsbeheer is geen mijlpaal, maar een beveiligingsrisico. Door te deployen op je eigen Kubernetes en te registreren achter een gateway binnen hetzelfde platform, voeg je deze twee stappen samen tot één proces: de applicatie draait binnen de grenzen van je bestaande netwerkbeleid, en de URL die er voor staat herkent direct wie de aanroep doet.

Deploy en beheer je eerste MCP server op TrueFoundry

Gratis starten