Hoe te migreren van Portkey naar TrueFoundry

Portkey is een krachtige AI-gateway, en voor een team dat precies binnen de ingestelde niveaus past, werkt het uitstekend. Het probleem waar veel teams tegenaan lopen is niet de functionaliteit in abstracte zin, maar waar elke functionaliteit zich binnen de prijsstructuur bevindt. De functionaliteit die u als volgende nodig heeft — SSO, een langere bewaartermijn voor logs, een VPC-uitrol, PII-anonimisering — bevindt zich meestal één niveau hoger dan uw huidige pakket, en het hoogste niveau heeft ondoorzichtige maatwerkprijzen.

Deze niveau-indeling is wat een evaluatie van Portkey verandert in een migratiegesprek. Een team op het Pro-plan ontdekt dat SSO op hun niveau helemaal niet beschikbaar is, dat een bewaartermijn van 30 dagen voor logs onvoldoende is voor een incidentenonderzoek of een compliance-audit, en dat het draaien van de data plane binnen de eigen VPC de Enterprise-tier vereist. Op dat moment wordt de vraag of er onderhandeld moet worden over een ondoorzichtig enterprise-contract voor functies die eigenlijk standaard zouden moeten zijn, dan wel of er wordt overgestapt naar een gateway waar governance en flexibiliteit in uitrol niet achter de hoogste betaalmuur zitten.

Dit is een migratiehandleiding voor teams in die positie. Het beschrijft de realiteit van Portkey's niveaus op een eerlijke manier, benoemt de specifieke redenen waarom teams overstappen en biedt een stapsgewijze migratie naar TrueFoundry die weinig risico met zich meebrengt doordat beide gateways de OpenAI-compatibele API ondersteunen. In de meeste gevallen is de aanpassing aan de clientzijde beperkt tot een enkele base-URL.

Wilt u SSO, VPC en diepgaand kostenbeheer zonder strikte niveaugrenzen? Boek een demo.

De realiteit van Portkey's prijsniveaus

Om een migratie te plannen heeft u een realistisch overzicht nodig van wat Portkey op welk niveau biedt, aangezien de beslissing hier volledig op rust.

De open-source-kern verzorgt alleen routing. Portkey's OSS-gateway regelt routing, fallback en load balancing. Het bevat geen observability, caching, virtuele sleutels of RBAC. Als u Portkey OSS heeft geïmplementeerd in de verwachting het volledige product te krijgen, heeft u enkel de request-routinglaag gekregen en verder niets.

Het gehoste product voegt de operationele laag toe. Logs en traces, virtuele sleutels, caching en prompt management maken deel uit van het gehoste (beheerde) product, niet van de OSS-kern. Dit is de omgeving waar de meeste teams Portkey daadwerkelijk draaien.

Enterprise schermt de governance- en uitrolfuncties af. SSO, compliance-functies, VPC/privé-tenancy, PII-anonimisering en een BAA zijn alleen beschikbaar voor Enterprise, tegen maatwerkprijzen. De functionaliteiten die het meest relevant zijn voor een gereguleerde onderneming bevinden zich achter het niveau zonder openbare prijsstelling.

De specifieke limieten van het Pro-plan. De gepubliceerde niveaus maken het plafond concreet:

De stap van Pro naar Enterprise is niet incrementeel. Er is geen tussenliggend niveau waar u alleen SSO of alleen 90 dagen bewaartermijn kunt aanschaffen. Zodra u een functie nodig heeft die is afgeschermd achter Enterprise, belandt u in een maatwerk-prijsonderhandeling — precies de frictie die teams ertoe brengt alternatieven te evalueren.

Waarom teams migreren naar TrueFoundry

De redenen zijn specifiek en sluiten direct aan op de hierboven genoemde niveaustructuur.

• SSO, compliance en VPC zonder de ondoorzichtige stap omhoog. Teams hebben SSO via een identity provider, SCIM-provisioning, audits en de mogelijkheid nodig om de data plane in hun eigen netwerk te laten draaien. Ze willen niet dat deze essentiële governance-functies worden afgeschermd achter een maatwerk enterprise-contract.
• Diepgaander kostenbeheer. Naast limieten per sleutel willen teams budgetten en rate limits per gebruiker, team en model met een reële kostentoewijzing gelabeld per team, zodat FinOps uitgaven nauwkeurig kan toewijzen in plaats van een geaggregeerd logboek te moeten analyseren.
• Consolidatie in één control plane. In plaats van een losse gateway, aparte observability en een extern MCP-beheer, willen teams gateway + governance + observability + MCP in één enkel control plane, met mogelijkheden voor on-premise of air-gapped uitrol, en niet alleen VPC op het hoogste niveau.
• Bewaartermijnen die u zelf beheert. Een vast logboekvenster van 30 dagen is te beperkt voor incidentforensiek en audits. Teams willen de bewaartermijn afstemmen op hun compliance-vereisten, niet op hun abonnementsvorm.

TrueFoundry is precies hiervoor ontworpen: een geconsolideerde OpenAI-compatibele gateway met routing (latentie, gewicht, prioriteit), fallback met retries binnen de request, exacte en semantische caching, budgetten en rate limits per gebruiker/team/model, observability per request met kostentoewijzing, inline guardrails, plus RBAC, SSO, SCIM en audit, evenals een MCP-gateway — allemaal in één control plane die als SaaS, in-VPC, on-premise of air-gapped kan worden uitgerold waarbij de data plane binnen uw eigen netwerk blijft. De governance is geen prijsniveau; het is het kernproduct. Voor het algemene selectiekader, zie hoe u een AI-gateway kiest.

Ontdek hoe TrueFoundry gateway, governance en observability consolideert in één platform. Boek een demo.

Het migratiepad

De migratie verloopt stapsgewijs en is omkeerbaar. U hoeft niet alles in één keer om te zetten. Omdat beide gateways de OpenAI-compatibele API ondersteunen, is de aanpassing aan de clientzijde minimaal.

Stap 1: Inventarisatie

Breng in kaart wat Portkey momenteel voor u uitvoert:

• Elke configuratie (de routing-, fallback-, caching- en retry-definities).
• Elke virtuele sleutel en welke applicatie of welk team deze gebruikt, inclusief de bijbehorende limieten.
• Alle geconfigureerde guardrails en eventuele prompt management-onderdelen als u die functie gebruikt.
• Credentials van providers die in Portkey zijn opgeslagen.
• Uw bewaartermijn voor logs en eventuele compliance-eisen waaraan moet worden voldaan.
• Elke caller: de applicaties, services en jobs die naar het endpoint van Portkey verwijzen, inclusief de gebruikte base-URL's.

Leg de verwachtingen rondom bewaartermijnen en compliance expliciet vast. Een van de redenen voor uw migratie is waarschijnlijk dat 30 dagen onvoldoende is; stel het uiteindelijke doel (bijvoorbeeld 180 of 365 dagen) daarom direct vast als migratie-eis.

Stap 2: Vertaal de concepten

Vertaal Portkey-concepten naar hun equivalenten binnen TrueFoundry. De functionaliteiten komen grotendeels overeen, dus dit is een kwestie van herstructureren, niet van herbouwen.

Stap 3: Draai beide systemen parallel

Dit maakt de migratie veilig. Portkey en TrueFoundry bieden beiden een OpenAI-compatibele API, waardoor de enige benodigde aanpassing aan de clientzijde het wijzigen van de base-URL is. Geen SDK-wijzigingen, geen herschrijving van de request-structuur en geen aanpassingen in de verwerking van responsen.

Richt TrueFoundry in naast Portkey. Pas de base-URL van één service met een laag risico aan naar het nieuwe endpoint en controleer of de responsen overeenkomen, de observability het verkeer toont met de juiste kostentoewijzing, budgetten en guardrails werken zoals geconfigureerd en caching naar behoren functioneert. Omdat beide endpoints actief zijn, kunt u ze direct vergelijken en een service binnen enkele seconden terugzetten naar de base-URL van Portkey als er iets niet klopt.

Een concreet voorbeeld: als uw service zijn endpoint uitleest via OPENAI_API_BASE, houdt de migratie van die service in dat u één omgevingsvariabele aanpast en de service herstart. Terugdraaien is simpelweg de variabele weer herstellen. Dat is de gehele impact aan de clientzijde wanneer beide gateways dezelfde API gebruiken.

Stap 4: Migreer observability en bewaarverwachtingen

Deze stap is specifiek voor de migratie vanaf Portkey, omdat de bewaartermijn vaak de directe aanleiding voor de overstap is. Voordat u het productieverkeer overzet, dient u te controleren of de observability van TrueFoundry dezelfde gegevens vasthoudt als de logs van Portkey: tokens per request, latentie, model en kosten. Controleer ook of de bewaartermijn is ingesteld op uw gewenste periode in plaats van de door het prijsniveau opgelegde 30 dagen. Valideer of de kostentoewijzing per team wordt gelabeld zoals FinOps dat vereist; de overstap van geaggregeerde gehoste logs naar gelabelde observability per request is immers een van de concrete voordelen van deze migratie. Ons overzicht van LLM observability tools beschrijft wat hoogwaardige observability per request moet bevatten.

Stap 5: Cut-over per team

Migreer het verkeer stapsgewijs, opgesplitst per team of applicatie:

1. Kies een team. Maak hun TrueFoundry-toegang, RBAC-rol, budgetten en model-catalogusbereik aan, gebaseerd op hun eerdere virtuele sleutellimieten in Portkey.
2. Pas de base-URL van de callers van dit team aan naar TrueFoundry.
3. Monitort de observability gedurende een vastgestelde evaluatieperiode: kostentoewijzing, latentie, foutpercentages, cache-hitrates en het gedrag van guardrails.
4. Ga door naar het volgende team.

Een cut-over per team biedt een duidelijke grens voor eventuele rollbacks en stelt u in staat om budgetten en toegang per team direct correct in te stellen, in plaats van een kluwen aan gedeelde virtuele sleutels in één risicovolle stap te moeten overzetten.

Stap 6: Ontmanteling

Zodra elke caller naar TrueFoundry verwijst en lang genoeg stabiel heeft gedraaid, kan Portkey worden ontmanteld: stop de routing naar Portkey, verwijder provider-geheimen uit de configuraties en roteer die provider-credentials zodat de oude exemplaren onbruikbaar worden. Controleer of er geen enkele job, notebook of CI-stap meer naar het oude endpoint verwijst voordat u het definitief uitschakelt. De migratie is voltooid wanneer er één beheerd pad naar elk model is en er geen verweesde Portkey-configuraties met actieve sleutels meer bestaan.

Portkey versus een geconsolideerd control plane

Het structurele verschil — en de reden waarom de migratie de moeite waard is voor organisaties die hier tegenaan lopen — zit in de locatie waar het beheer plaatsvindt.

Het punt is niet dat Portkey deze functies mist — het Enterprise-niveau bevat er veel van. Het punt is dat voor een team dat SSO, VPC en een volwaardige bewaartermijn nodig heeft, deze functionaliteiten in een geconsolideerd control plane standaard zijn, in plaats van een reden om over maatwerkprijzen te moeten onderhandelen. Voor teams die ook toegang tot MCP-tools willen beheren, wordt het consolideren daarvan in hetzelfde platform behandeld in ons artikel over enterprise MCP governance.

Veelgemaakte fouten bij deze migratie

Migreren zonder vooraf het bewaartermijndoel vast te stellen. De hoofdreden waarom veel teams Portkey verlaten is de loglimiet van 30 dagen, maar toch migreren ze soms zonder de daadwerkelijk benodigde bewaartermijn op te schrijven. Stel de gewenste periode expliciet vast als migratie-eis, zodat u dit kunt valideren tijdens de parallelle fase en niet pas na de cut-over.

Gedeelde virtuele sleutels een-op-een overnemen. Omgevingen in Portkey verzamelen na verloop van tijd vaak gedeelde virtuele sleutels. Door deze exact zo te herstellen, bouwt u opnieuw onbeheerde toegang op in het nieuwe systeem. Gebruik de cut-over om RBAC per team in te richten via uw identity provider; dit is immers een van de belangrijkste redenen voor de overstap.

De wissel van de base-URL zien als de gehele migratie. De OpenAI-compatibele API maakt de technische aanpassing eenvoudig, maar de werkelijke waarde zit in de governance: SSO, RBAC, budgetten, audits en een bewaartermijn die u zelf beheert. Het enkel omzetten van URL's zonder de governance in te richten geeft u simpelweg een andere gateway met dezelfde tekortkomingen.

Vergeten geheimen te roteren bij de ontmanteling. Als u Portkey uitschakelt maar de daarin opgeslagen provider-sleutels niet roteert, blijven die credentials actief in een ontmanteld, onbewaakt systeem. Roteer alle credentials die de oude gateway bevatte als onderdeel van de ontmantelingsprocedure.

Een 'big-bang' cut-over uitvoeren. De gehele organisatie in één keer omzetten neemt de mogelijkheid weg om gecontroleerd terug te vallen. Door parallel te draaien en per team over te stappen, blijft eventuele frictie beperkt tot één team en is dit direct te herstellen door een enkele base-URL terug te zetten.

Conclusie

Migreren van Portkey draait zelden om het ontbreken van functionaliteit in abstracte zin; het gaat erom waar die functionaliteit zich bevindt binnen de prijsstructuur. Wanneer SSO, VPC, PII-verwerking en een volwaardige log-bewaartermijn allemaal in een Enterprise-niveau met maatwerkprijzen zitten, staat een team dat deze functies nodig heeft voor de keuze tussen een ondoorzichtige onderhandeling of een overstap naar een platform waar governance en flexibele uitrol standaard zijn.

De overstap zelf heeft een laag risicoprofiel. Beide gateways ondersteunen de OpenAI-compatibele API, waardoor de aanpassing aan de clientzijde meestal beperkt blijft tot één base-URL. Inventariseer uw configuraties en virtuele sleutels, vertaal ze naar RBAC, policy's en observability, controleer de bewaartermijn tijdens een parallelle fase, voer de cut-over team voor team uit en sluit af met een volledige rotatie van alle geheimen. Op deze manier consolideert u gateway, governance, observability en MCP in één control plane, uitgerold binnen uw eigen netwerk, zonder dat u code hoeft te herschrijven.

Stap over van Portkey naar een geconsolideerd control plane. Boek een demo.