Migreren van Bifrost: overstappen van een self-hosted AI Gateway naar een beheerde variant

Bifrost is een goede open source AI-gateway en veel teams beginnen er om de juiste redenen mee: het is gratis, snel en draait overal. De redenen waarom teams later afstappen van een self-hosted AI-gateway zijn meestal operationeel in plaats van functioneel. Iemand moet het cluster beheren, PostgreSQL hoog beschikbaar houden, upgraden via breaking releases en de beveiligingsreviews afhandelen. Wanneer dat werk de moeite niet meer waard is, wordt de vraag hoe je kunt overstappen zonder elke applicatie te breken die de gateway aanroept.

Deze gids is het plan dat wij zouden volgen. Het mapt de concepten van Bifrost naar een beheerde gateway (we gebruiken de TrueFoundry AI Gateway als bestemming), geeft een overzicht van de client-aanpassingen en legt een cutover uit met een rollback-pad. Het behandelt ook wat er niet meegaat, zodat je de omvang van het werk eerlijk kunt inschatten.

Waar we leunen op onze eigen ervaring, van het draaien van Bifrost OSS v2.0.0 en het installeren van een TrueFoundry gateway plane in ons eigen cluster in oktober 2026, vermelden we dat expliciet.

Wanneer een self-hosted AI-gateway de moeite niet meer waard is

De gratis tier van Bifrost is een volledige gateway, dus ontbrekende functionaliteiten zijn zelden de aanleiding. Dit zijn meestal de redenen:

• Je hebt meer dan één node nodig. OSS-replica's delen geen status (state). Ze lezen dezelfde statische config.json, vereisen een herstart voor elke wijziging en houden budgetten, rate-limit-tellers en sleutelherroepingen per pod bij. Live synchronisatie is alleen beschikbaar in Enterprise.
• Beveiligingsreview. SSO, RBAC, audit logs, secrets in een vault en guardrails zijn Enterprise-functies met prijzen op offertebasis. Service-identiteiten bestaan in geen van beide tiers; services maken gebruik van langdurig geldige virtuele sleutels.
• Upgrades. De v1.5.0-release bevatte 16 breaking changes en databasemigraties die niet ongedaan gemaakt kunnen worden. Iemand moet elke release note lezen en een back-up maken van PostgreSQL voor elke upgrade.
• On-call diensten. De gateway bevindt zich in het pad van elke modelaanroep. Als deze om 2 uur 's nachts uitvalt, word jij opgepiept.

Als twee of meer van deze punten waar zijn, kost een beheerde gateway meestal minder dan de benodigde engineeringtijd. Onze artikelen over Bifrost-prijzen en Bifrost Enterprise vs OSS behandelen de afweging tussen kopen en zelf beheren in meer detail.

Kies eerst het implementatiemodel

“Beheerd” omvat meer dan één vorm, en de keuze bepaalt hoeveel van de migratie uit infrastructuurwerk bestaat. TrueFoundry biedt drie implementatie-opties aan:

We hebben de middelste optie gebruikt voor onze eigen evaluatie. De gateway plane wordt geïnstalleerd via een Helm chart en authenticeert bij de control plane met een gateway-token; modellen, routing en toegangsregels worden geconfigureerd in de control plane en gesynchroniseerd met de gateway. De chart implementeert ook een Redis-pod naast de gateway. Vereisten zijn Kubernetes 1.27 of hoger, block-storage volumes, een domein en certificaat voor het gateway-eindpunt, een image pull secret van TrueFoundry en uitgaand netwerkverkeer (egress) van het cluster naar je control plane URL (deploy gateway plane). Het zelf hosten van de gateway plane valt onder de Enterprise tier van TrueFoundry.

Stap 1: inventariseer wat Bifrost vandaag de dag doet

De meeste verrassingen bij migraties komen voort uit configuraties waarvan niemand zich herinnert dat ze geschreven zijn. Maak een overzicht van de volgende punten voordat je iets aanmaakt in de nieuwe gateway:

• Providers en sleutels: elke provider, elke sleutel, sleutelgewichten en aangepaste eindpunten zoals vLLM of Ollama.
• Virtuele sleutels: eigenaar (team, klant of geen), toegestane providers en modellen, budgetten, rate limits, MCP-tool-toegang en vervaldatum.
• Routing: gewogen providerconfiguraties, fallback-ketens, retry-instellingen en elke CEL-routingregel, inclusief scope en prioriteit.
• MCP: verbonden MCP-servers, toolgroepen en hun authenticatiemodi.
• Observability: instellingen voor content-logging, OTel- en andere connectors, retentie, en alle dashboards of alerts die zijn gebouwd op bifrost_*-metrics.
• Plugins: aangepaste Go-plugins, semantic caching en de Maxim-plugin.
• Aanroepende toepassingen (callers): elke applicatie, welke SDK deze gebruikt, welke Bifrost-route deze aanroept (OpenAI-compatibel of een provider-native route) en welke x-bf-*-headers deze verstuurt.

Als je Bifrost uitvoert met een op bestanden gebaseerde configuratie, bevat config.json het grootste deel van deze lijst. Als je de op een database gebaseerde configuratie-opslag gebruikt, lees deze dan uit via de management API in plaats van de UI, zodat er niets over het hoofd wordt gezien.

Stap 2: map de concepten van Bifrost naar de nieuwe gateway

De onderstaande mapping vormt de kern van de migratie. Het gedrag van Bifrost is afkomstig uit de documentatie van Bifrost; het gedrag van TrueFoundry is afkomstig uit de TrueFoundry-documentatie waarnaar in elke rij wordt verwezen.

CEL-routingregels herschrijven

CEL-regels zijn het deel van een Bifrost-configuratie dat niet mechanisch kan worden vertaald. Sorteer elke regel op basis van wat deze werkelijk doet:

• Verkeer splitsen of failover toepassen (gewogen doelen, fallbacks): wordt een virtueel model.
• Routen per team of omgeving (bijvoorbeeld een header zoals x-environment): wordt een afzonderlijk virtueel model per omgeving, met toegang verleend aan het juiste team, of op metadata afgestemd beleid.
• Reageren op budgetgebruik (verkeer verplaatsen naar een goedkoper model na het bereiken van een drempelwaarde): wordt een budgetregel plus een fallback, of een beslissing binnen de applicatie.
• Al het andere: schrijf het op en bepaal of het überhaupt in de gateway thuishoort.

Stap 3: pas de clients aan

Voor een applicatie die de OpenAI SDK gebruikt, bestaat de wijziging uit drie waarden: base URL, API-sleutel en modelnaam.

Een aantal dingen om per caller te controleren:

• Authenticatie wordt verplicht. In onze tests accepteerde een standaard Bifrost OSS-installatie verzoeken zonder authenticatiegegevens, waardoor sommige interne callers er mogelijk nooit een hebben verzonden. Elk TrueFoundry-verzoek bevat een bearer-token. Spoor die callers op vóór de cutover, niet tijdens.
• Provider-native routes. Als een caller de Anthropic-, Gemini- of Bedrock-compatibele routes van Bifrost gebruikt met de eigen SDK van de provider, controleer dan de ondersteuning voor de native SDK van de bestemming. TrueFoundry ondersteunt de OpenAI, Anthropic, Google Gen AI, Azure OpenAI en boto3 SDK's, waarbij routingconfiguratie voor sommige wel en voor andere niet wordt ondersteund (native SDK-ondersteuning).
• Response-vorm. Toen we de OpenAI Python SDK richtten op Bifrost v2.0.0, kwamen vier van de zes scenario's exact overeen met OpenAI; de streaming rol, logprobs en error-vorm weken af. Code die de error-bodies van Bifrost verwerkt of om de streaming-eigenaardigheden heen werkt, moet mogelijk worden aangepast wanneer deze met een andere gateway communiceert. Test de foutafhandeling, niet alleen het succesvolle pad (happy path).
• Verschillen tussen providers verdwijnen niet. In onze Bifrost-tests leidde dezelfde request-vorm tot verschillende striktheden in tool-schema's, reasoning-parameters en fouten rondom buitengebruikstelling van modellen bij verschillende providers. Dat geldt achter elke gateway, dus behoud contracttests per provider in je CI.

Stap 4: voer de cutover geleidelijk uit, met een mogelijkheid tot terugdraaien

1. Zet de nieuwe gateway op naast Bifrost. Maak providers, modellen, virtuele accounts, budgetten in auditmodus, rate limits, guardrails en loggingconfiguraties opnieuw aan. Laat Bifrost ongemoeid.
2. Voer contracttests uit tegen beide gateways: non-streaming en streaming chat, tool-calls, gestructureerde uitvoer, embeddings, foutgevallen en elke provider-native route die je gebruikt.
3. Migreer eerst één service met een laag risico. Wijzig de base URL, het token en de modelnamen via de configuratie of een feature flag, zodat terugschakelen een kwestie is van een deployment in plaats van een codewijziging.
4. Vergelijk gedurende een week. Het aantal tokens en de berekende kosten per service moeten overeenkomen tussen de logs van Bifrost en het dashboard van de nieuwe gateway. Een verschil betekent meestal dat een prijs- of modelnaam-mapping onjuist is.
5. Migreer de rest in groepen, met de services met het hoogste volume als laatste. Zet budgetten om van audit naar enforce zodra de cijfers overeenstemmen.
6. Houd Bifrost read-only actief gedurende een rollback-periode en int vervolgens de virtuele sleutels. Op een multi-replica OSS-installatie wordt het intrekken van een sleutel niet gepropageerd tussen pods, dus herstart elke replica na het intrekken, of schakel Bifrost gewoon uit.

Wat niet meegaat

• Request-historie. Het SQLite- of PostgreSQL-schema van Bifrost is geen stabiel uitwisselingsformaat. Als je de historie nodig hebt voor audits of evaluaties, exporteer deze dan via de logs-API of je bestaande connectors vóór de buitenbedrijfstelling en bewaar deze buiten de gateway.
• Aangepaste Go-plugins. Deze zijn gecompileerd tegen een specifieke Bifrost-core en Go-versie, dus migratie vereist het herschrijven ervan.
• CEL-expressies, zoals hierboven beschreven.
• Cache-inhoud. Caches voor semantic en exact-match beginnen leeg op de nieuwe gateway.
• Dashboards en alerts die zijn gebouwd op bifrost_* metric-namen en -labels.
• Bifrost-specifieke headers zoals x-bf-vk, x-bf-dim-*, x-bf-lh-* en de overschrijving van de logging per verzoek.
• MCP OAuth-toestemmingen voor verbindingen per gebruiker; gebruikers moeten opnieuw autoriseren.

Valkuilen uit onze eigen installatie

Deze zijn voortgekomen uit het installeren van een TrueFoundry gateway plane in ons cluster en het sturen van testverkeer daarnaartoe.

• Tenant-brede guardrailregels zijn direct van toepassing op nieuwe callers. Onze tenant had al een PII-guardrailregel; onze eerste testverzoeken werden geweigerd met HTTP 400 totdat we het virtuele testaccount daarvan uitsloten. Controleer bestaande guardrailregels en voer nieuwe regels uit in auditmodus voordat je productieverkeer omleidt.
• Request-logging staat standaard aan. Bij een gehoste control plane stuurt de gateway verzoeklogs daar naartoe. Je kunt de verzoek- en responsgegevens in plaats daarvan in een bucket in je eigen cloud bewaren, en loggingconfiguraties kunnen body-logging uitschakelen of per team, model of metadata redacteren/anonimiseren. Bepaal dit samen met je beveiligingsteam vóór het eerste productieverzoek, niet erna.
• Self-hosted modellen registreren net als elke andere provider. We hebben een OpenAI-compatibel eindpunt dat in ons cluster draait geregistreerd als een self-hosted model en aangeroepen als <account>/<model>. Interne vLLM- of soortgelijke eindpunten die je nu via Bifrost bereikt, worden op dezelfde manier gemigreerd.
• Houd rekening met de capaciteit voor de extra pod. De gateway-plane chart draait Redis naast de gateway. Neem dit op in je capaciteits- en kostenplanning.

Is een beheerde gateway geschikt voor jou?

Blijf op self-hosted Bifrost als je één enkele node draait, de platform engineers hebt om het te beheren en geen SSO, audit of service-identiteiten nodig hebt.

Stap over op Bifrost Enterprise als je op Bifrost wilt blijven en de gateway zelf wilt blijven beheren, maar clustering en de beveiligingsfuncties nodig hebt. Je blijft nog steeds verantwoordelijk voor het cluster, HA PostgreSQL en de upgrades.

Stap over op een beheerde gateway als de operationele druk het probleem is. Kies voor SaaS als je databeleid dit toestaat, of een gateway plane in je eigen cluster als modelverkeer binnen je eigen netwerk moet blijven.

Waarom TrueFoundry als bestemming

• Jij kiest de mate van beheer. SaaS, een gateway plane in jouw cluster met een gehoste control plane, of volledig self-hosted, inclusief air-gapped.
• Configuratiesynchronisatie is de architectuur. Gateway-pods zijn stateless en ontvangen configuratie, gebruikers, virtuele accounts en autorisatieregels in real-time van de control plane; de volledige configuratie wordt elke 10 minuten opnieuw gepubliceerd zodat een gemiste update niet tot verschillen leidt, en gateways blijven functioneren op hun laatste configuratie als de control plane onbereikbaar is (gateway plane architectuur). Dat vervangt het herstart-elke-pod-model van Bifrost op OSS.
• Ingebouwde service-identiteit. Virtuele accounts geven elke applicatie een eigen token met geplande rotatie, een coulanceperiode en secret-store synchronisatie.
• Beleid als regels. Budgetten, rate limits, guardrails en logging zijn afzonderlijke regelsets die gematcht worden op wie, welk model en request-metadata, met auditmodi voor een veilige uitrol.

Als je een overstap vanaf een self-hosted AI-gateway plant, boek dan een demo en neem je Bifrost-configuratie mee; we kunnen de mapping samen met je doornemen. Om het product eerst te bekijken, begin je op de TrueFoundry AI Gateway-pagina.

Gerelateerde artikelen

• Bifrost-prijzen: OSS, Enterprise-kosten en wat teams moeten weten
• Bifrost vs LiteLLM
• Wat is een LLM-gateway?
• AI-gateway on-premise: alles wat je moet weten
• LiteLLM-alternatieven

Conclusie

Migreren vanaf een self-hosted AI-gateway draait minder om de client-aanpassing, die klein is, en meer om het nauwkeurig opnieuw aanmaken van sleutels, beleid en routing, om vervolgens service voor service over te stappen met een weg terug. Voer eerst de inventarisatie uit, map elke virtuele sleutel naar een echte identiteit, herschrijf CEL-regels bewust in plaats van via een directe vertaling en houd Bifrost actief totdat de cijfers overeenkomen. Als je een extra paar ogen wilt bij het mappen, boek dan een TrueFoundry-demo.