TrueFoundry vs OpenRouter: Deployment en architectuur — Kun je het self-hosted draaien? (2026)

OpenRouter is een beheerde SaaS-router zonder self-hosted, VPC- of on-premise-editie op welk niveau dan ook, en elke prompt die je verstuurt verlaat je netwerk. Dat is geen kritiek op het product; het is de architectuur. Het is echter wel het feit dat de meeste enterprise-evaluaties van OpenRouter beëindigt voordat de functionaliteiten worden vergeleken, en het is de reden waarom platform- en securityteams het uiteindelijk vergelijken met een AI gateway die ze zelf kunnen draaien.

Dit artikel is voor degenen die antwoord moeten geven op de vraag "waar draait het en waar gaan de prompts naartoe": platform engineers die een productie-deployment dimensioneren, security leads met eisen rondom datagrenzen, en architecten die willen begrijpen wat een control plane en een gateway plane daadwerkelijk doen. We vergelijken het SaaS-only model van OpenRouter met de vier deploymentmodi van TrueFoundry AI Gateway (beheerde SaaS, SaaS met je eigen opslag, hybride en volledig self-hosted of air-gapped), doorlopen de architectuur die deze modi mogelijk maakt, and leggen helder uit wat je in elke modus moet beheren. Elke bewering is gebaseerd op de openbare documentatie van beide leveranciers.

Als je al weet dat je een gateway binnen je eigen grenzen nodig hebt, kun je een TrueFoundry-demo boeken en direct doorgaan naar de onderstaande vergelijkingstabel.

In één oogopslag

Waarom "OpenRouter self-hosted" geen antwoord heeft

OpenRouter draait zowel zijn control plane als zijn data plane op zijn eigen infrastructuur. Je beheert geen van beide, dus er valt niets te deployen, er is geen Kubernetes-integratie, er zijn geen stateful afhankelijkheden aan jouw kant en er hoeven geen updates te worden uitgevoerd. De architectuur voor klanten bestaat enkel uit een endpoint en een sleutel. In plaats van deploymentmodi verschilt alleen het endpoint: standaard het globale openrouter.ai/api/v1, en voor Enterprise-klanten regiospecifieke basis-URL's op eu.openrouter.ai en us.openrouter.ai, waar requests alleen binnen die regio worden ontsleuteld en verwerkt en alleen worden doorgestuurd naar providers die daar actief zijn. Met Private Models, eveneens Enterprise, kan OpenRouter verbinding maken met een model-endpoint dat jij host, handmatig geconfigureerd door hun team (Models).

Geen van al deze opties is self-hosting. Prompts, responsen en metadata verlopen allemaal via OpenRouter, en vervolgens via de provider die het request afhandelt. OpenRouter documenteert drie aanvullende instellingen, en het is belangrijk om precies te weten wat elke instelling doet: in-region routing beperkt de rechtspraak waarin data wordt ontsleuteld; routing zonder dataretentie beperkt requests tot providers die geen prompts of responsen opslaan; en provider.data_collection: "deny" stuurt alleen requests naar providers die geen gebruikersdata verzamelen. Alle drie bepalen ze waar de data naartoe gaat en wat er wordt bewaard. Geen van drieën verandert het feit dat de data je netwerk verlaat. Failover tussen de twee regionale endpoints is niet gedocumenteerd.

De keerzijde verdient evenveel aandacht. Nul infrastructuur op elke schaal is een echt voordeel, maar het operationele werk verdwijnt niet zozeer; het verplaatst zich naar je applicatie: retry- en timeout-afhandeling in de client, een gemonitord creditsaldo, en het besluit of je een directe route naar de provider aanhoudt als tweede optie, omdat een gehoste gateway een single point of failure kan vormen in het request-pad.

De vier deploymentmodi van TrueFoundry

Een self-hosted AI gateway is meestal een fork van het product van een leverancier: een andere binary, een andere set functionaliteiten, een ander supportcontract. TrueFoundry levert vier modi als één product op één control plane, wat het fundamentele verschil is op dit gebied (modes of deployment):

1. Volledig beheerde SaaS. Wij hosten alles; nul infrastructuurkosten; een wereldwijd gedistribueerde gateway.
2. SaaS met data-opslag van de klant. Dezelfde beheerde gateway, waarbij traces en logs terechtkomen in je eigen blob bucket in de door jou gekozen regio.
3. Hybride. Een self-hosted gateway plane in je VPC, zodat het datapad binnenboord blijft, gecombineerd met een door TrueFoundry gehoste control plane. Ongeveer $ 600/maand aan basisinfrastructuur.
4. Volledig self-hosted. Control plane en gateway plane beide in je VPC of on-premise, met ondersteuning voor air-gapped omgevingen. Ongeveer $ 800–1.000/maand aan basisinfrastructuur.

De modi lossen verschillende problemen op, en het door elkaar halen ervan is de meest gemaakte fout die we zien bij evaluaties. Modus 2 lost dataresidentie op zonder de uitgaande datastroom te veranderen: prompts verlopen nog steeds via onze gateway. Modus 3 lost het probleem van de uitgaande datastroom op, omdat prompts je VPC nooit verlaten, terwijl het beheer vrijwel nul blijft doordat de gateway plane geen status (state) bewaart. Modus 4 lost alles op, afgezien van één openbaar gemaakte callback: inloggen en licentiecontrole verlopen via onze globale auth-server, die e-mailadressen van gebruikers en het aantal requests ontvangt, maar niets uit het inhoudelijke request-pad. Als je al modellen in je eigen omgeving draait, legt onze gids voor on-premise LLM deployment uit hoe de gateway daarlangs wordt geplaatst.

Twee eerlijke kanttekeningen. Er is geen open-source self-hosted editie; het $ 0 Developer-niveau is een SaaS-niveau, geen self-hostable binary, en self-hosting is een Enterprise-functionaliteit. Daarnaast is het overstappen tussen modi (beginnen op SaaS, doorgroeien naar hybride) logisch door de gedeelde control plane, maar dit is nog niet gedocumenteerd als een officieel ondersteunde migratieprocedure.

LLM gateway-architectuur: wat een stateless gateway plane je oplevert

De reden dat de vier modi één product kunnen vormen, is de scheiding tussen de control plane en de gateway plane. En de reden dat de hybride modus goedkoop is in het beheer, is wat de gateway plane níét doet.

De gateway plane is volledig stateless. Configuratie (modellen, sleutels, policies, RBAC) wordt vanaf de control plane gesynchroniseerd via een NATS-queue en in het geheugen bewaard. Elke controle in het request-pad (authenticatie, RBAC, rate limits, budgetten) wordt in het geheugen uitgevoerd, zonder database-call in het kritieke pad. Logs en metrics stromen na de respons asynchroon terug, zodat het wegschrijven van een log een request nooit vertraagt. De control plane bevat alle status: Postgres voor configuratie en gebruikers, NATS voor synchronisatie, ClickHouse ondersteund door blob storage voor logs en analytics (gateway plane architecture, control plane architecture). Dat zorgt ervoor dat de gateway slechts zo'n 3–4 ms aan extra latency toevoegt en 350+ requests per seconde verwerkt op een enkele vCPU, terwijl hij toegang biedt tot meer dan 2.500 LLM's via één OpenAI-compatibel endpoint. Dit is ook de reden waarom meerdere gateway planes aan één control plane gekoppeld kunnen worden voor deployments over meerdere VPC's en regio's.

Twee nuanceringen houden deze claim over de AI-gatewayarchitectuur zuiver. "Geen externe call in het request-pad" kent gedocumenteerde uitzonderingen: Redis bij routes waar caching is ingeschakeld, en elke door TrueFoundry beheerde guardrail die aan een route is gekoppeld voegt een netwerk-hop toe. En de scheiding is geen specifieke functionaliteit voor hybride omgevingen; de volledige SaaS-versie draait op dezelfde architectuur, wat betekent dat hybride hetzelfde product is waarbij één plane is verplaatst, in plaats van een afzonderlijke fork.

De scheiding geeft ook antwoord op de vraag die elk platformteam stelt: wat gebeurt er als de control plane onbereikbaar is? De gateway blijft verzoeken afhandelen op basis van de laatst gesynchroniseerde configuratie. Wat wel achteruitgaat, is hoe recent de configuratie is, de nauwkeurigheid van gecumuleerde budgetten en de mogelijkheid om nieuwe pods te starten. Het ergste scenario is wanneer zowel NATS als de control-plane backend uitvallen: op dat moment stopt de realtime synchronisatie, valt de log-pipeline stil, bevriezen de gecumuleerde tellers en mislukken pod-restarts. Als NATS wel werkt en alleen de backend uitvalt, gaan synchronisatie, aggregatie en logging gewoon door en worden alleen de UI en API beïnvloed (deployment FAQ). Het alternatief bij OpenRouter is simpeler en harder: control plane en data plane vormen één gehost systeem zonder een door de klant beheerde fallback, waardoor een storing daar alle providers tegelijk onbereikbaar maakt — precies het risico dat je wilt vermijden met een multi-provider router.

De gateway plane is geschreven in Hono op Node.js en wordt geleverd als de tfy-llm-gateway Helm chart voor Kubernetes 1.27+ (EKS, GKE, AKS, OpenShift en on-premise zijn gedocumenteerd). Er zijn geen CRD's en geen operator: gateway-objecten bevinden zich in de control plane en synchroniseren via NATS, waardoor kubectl nooit aan de gateway-configuratie komt. Eén centraal brein, geen afwijkingen per cluster, met één duidelijke consequentie: gateway-policy's kunnen niet via GitOps met Kubernetes-manifesten worden beheerd; GitOps/IaC is een Enterprise-functionaliteit (deploy gateway plane).

Air-gapped en dataresidentie: de exacte claims

Claims over "air-gapped" in deze markt bestaan in drie niveaus, en een koper moet weten welke variant wordt aangeboden. Marketing air-gapped is SaaS met een afgeschermd privénetwerk. Data-path air-gapped betekent dat er nooit inhoudelijke verzoekdata naar buiten gaat, met een gedocumenteerde uitzondering voor het beheerkanaal. Volledig geïsoleerd (literally disconnected) betekent dat er op geen enkele wijze uitgaand verkeer is, met een offline licentiecontrole.

TrueFoundry valt duidelijk in het tweede niveau. Volledig self-hosted installaties in afgeschermde omgevingen zijn gedocumenteerd, inclusief het spiegelen van images en charts naar private registries, zonder dat er openbaar internet nodig is om verkeer af te handelen. De licentie is een sleutel die is opgeslagen als een Kubernetes Secret en wordt gecontroleerd bij het opstarten en synchroniseren, niet per individueel request. Actieve pods blijven onbeperkt draaien zonder verbinding met de licentieserver; alleen bij het starten van nieuwe pods zijn de control plane en NATS nodig. Er is geen op bestanden gebaseerde offline licentie, wat het verschil vormt met het derde niveau. Eén belangrijk aandachtspunt moet altijd worden genoemd bij de claim over air-gapped LLM's: onze ingebouwde PII-guardrail maakt gebruik van Azure AI Language en draait op door TrueFoundry beheerde infrastructuur. Als je deze inschakelt in een self-hosted deployment, verlaat de inhoud van verzoeken dus alsnog de eigen omgeving. Air-gapped configuraties moeten daarom gebruikmaken van self-hosted of aangepaste guardrails (PII guardrail).

OpenRouter valt niet binnen dit spectrum. Wat betreft de dataresidentie van OpenRouter is het belangrijkste feit uit de documentatie dat Input & Output Logging niet geldt voor requests die via de EU- of VS-endpoints worden gestuurd; die requests worden normaal verwerkt, maar logging wordt overgeslagen. Verwerking binnen de regio en het opslaan van prompt-inhoud sluiten elkaar daardoor uit. Een enterprise-koper die EU-residentie wil, kan dus geen gebruikmaken van debugging of audits op prompt-niveau via het platform. Waar de door OpenRouter bewaarde metadata van requests wordt opgeslagen en in welke regio, is niet gedocumenteerd.

Wat betreft multi-region: TrueFoundry SaaS schakelt automatisch over naar de dichtstbijzijnde beschikbare gateway (globally distributed SaaS); self-hosted multi-region bestaat uit meerdere gateway planes onder één control plane (Enterprise), waarbij je verkeersrouting en disaster recovery voor de control plane zelf moet ontwerpen.

TrueFoundry vs OpenRouter: deployment en architectuur direct vergeleken

De functionaliteiten van TrueFoundry zijn afkomstig uit onze documentatie; de functionaliteiten van OpenRouter weerspiegelen de openbaar gedocumenteerde mogelijkheden op het moment van schrijven.

Wat je beheert, en wat het kost

De minimale productie-inrichting van TrueFoundry wordt bepaald door de gekozen modus, niet door de schaal. In hybride modus gaat het om een Kubernetes-cluster verspreid over twee availability zones, twee of meer stateless gateway-replica's met autoscaling en anti-affinity, ingress met TLS, uitgaand verkeer naar de control plane en providers, en alleen Redis als je gebruikmaakt van caching of exacte budgetten over meerdere replica's nodig hebt. Hoge beschikbaarheid betekent hier simpelweg het draaien van meerdere replica's. Als je overstapt op volledig self-hosted, groeit het aantal vereiste stateful onderdelen van één optionele naar vier verplichte componenten: een beheerde multi-AZ Postgres, een NATS-cluster met drie nodes, gerepliceerde ClickHouse en duurzame blob storage — stuk voor stuk beheerde diensten of onderdelen die je eigen team moet onderhouden. Dat is de reden waarom de basiskosten uitkomen op ongeveer $ 600/maand voor hybride en $ 800–1.000/maand voor volledig self-hosted (exclusief schalen). Schatting van de benodigde capaciteit: circa 0,1–0,15 FTE voor hybride en 0,3–0,5 FTE voor een self-hosted control plane (dit zijn onze eigen schattingen, geen officiële cijfers).

Bij OpenRouter zijn de kosten $ 0 en vraag het ongeveer 0,02 FTE voor een klein team, wat een duidelijk voordeel is. De vergelijking die een koper moet maken is dan ook niet "gratis versus $ 800", maar of de eisen die leidden tot de zoektocht naar een enterprise LLM gateway überhaupt kunnen worden ingevuld door een gehost product. Als prompts binnen de eigen omgeving moeten blijven, zijn de infrastructuurkosten de prijs voor het voldoen aan die eise. Een breder overzicht van self-hosted opties vind je in onze gids over OpenRouter alternatieven.

Wanneer kies je welke

• Kies OpenRouter wanneer je helemaal geen infrastructuur wilt beheren en je prompts via een derde partij mogen verlopen. Richt je applicatie in op een SaaS-API met client-side resilience: retries, een gemonitord creditsaldo, en een directe fallback naar de provider voor kritieke processen.
• Kies TrueFoundry SaaS wanneer je nu geen infrastructuur wilt beheren, maar verwacht binnen een jaar een VPC- of hybride deployment nodig te hebben. Het maakt gebruik van hetzelfde product op dezelfde control plane, waardoor de overstap mogelijk is, ook al is de exacte migratieprocedure nog niet formeel gedocumenteerd.
• Kies TrueFoundry hybride wanneer prompts binnen je VPC moeten blijven, maar je geen stateful control plane wilt beheren. De footprint bestaat uit twee of meer stateless replica's en optioneel Redis. Dit is de modus waarin de architectuur zichzelf snel terugverdiend.
• Kies TrueFoundry volledig self-hosted wanneer de control plane zelf binnen je eigen grenzen moet staan: air-gapped, strikt gereguleerd of vanwege datasoevereiniteit. Houd rekening met de vier stateful componenten en een toegewezen node-group, gebruik self-hosted guardrails in plaats van de ingebouwde PII-guardrail, en stel je eigen disaster-recoveryplan op voor de control plane.

Gerelateerde artikelen

• On-Premise LLM Deployment — het draaien van modellen en de gateway binnen je eigen omgeving
• On-Premise AI Platform — hoe een volledig on-premise AI-platform eruitziet
• OpenRouter Alternatieven — het bredere aanbod aan self-hosted en enterprise-opties
• Wat is een LLM Gateway? — de architectonische basisgids
• OpenRouter vs AI Gateway — het verschil in categorie achter deze vergelijking

Conclusie

OpenRouter self-hosted bestaat niet als product, en geen enkele vorm van regionale routing of instelling zonder dataretentie verandert een gehoste marketplace in een self-hosted oplossing. OpenRouter wint op het gebied van deployment als het gaat om eenvoud, maar verliest op het gebied van keuzevrijheid: niets om te beheren, maar ook niets dat je binnen je eigen netwerk kunt houden. TrueFoundry wint op het gebied van keuzevrijheid, maar vraagt daarvoor een grotere footprint: vier modi op één control plane, een stateless gateway plane die blijft werken bij storingen in de control plane, en een self-hosted optie waarvan de kosten bestaan uit een stateful stack en beheertijd. Voor elke organisatie met striktee eisen rondom datagrenzen wordt de beslissing op basis van dit punt genomen.

Als je een AI gateway evalueert voor een VPC, hybride of air-gapped deployment, boek dan een demo om de gateway plane te zien draaien binnen je eigen cluster, of bekijk de TrueFoundry AI Gateway om te starten op beheerde SaaS en de plane later te verhuizen.