Bifrost Enterprise vs OSS: Wat je daadwerkelijk krijgt

Bifrost Enterprise is het betaalde niveau van Bifrost, de open-source LLM-gateway van Maxim AI. Het gratis OSS-niveau is op zichzelf al een complete gateway, dus de nuttige vraag voor een inkoopteam is specifieker dan "welke functies hebben we nodig?" Het komt neer op twee dingen: op hoeveel replicas gaat dit draaien, och wie moet zijn goedkeuring geven voor de beveiliging? Die twee antwoorden bepalen of de Bifrost LLM-gateway gratis blijft of verandert in een verkoopgesprek.

We hebben Bifrost OSS v2.0.0 zelf gedraaid voor onze praktijkreview, die de prestaties behandelt. We konden geen Enterprise-licentie krijgen, dus alles wat we over Enterprise zeggen is afkomstig uit de eigen documentatie en prijzenpagina van Maxim. Waar iets uit onze eigen testen komt, vermelden we dat expliciet.

Als je alleen het kostenplaatje wilt zien, behandelt ons overzicht van Bifrost-prijzen de licentie, hosting en beheer. Dit bericht gaat over wat elk niveau daadwerkelijk doet, waarbij de meeste ruimte is ingeruimd voor identiteit en beveiliging, omdat het betaalde niveau daar zijn geld verdient.

Wat het gratis Bifrost OSS-niveau al biedt

Bifrost OSS is een echte open-source AI-gateway, geen demo-editie. Het is Apache-2.0, self-hosted, en heeft geen door de leverancier opgelegde limieten voor requests, tokens of seats. Maxim's eigen functiematrix plaatst deze in het gratis niveau (prijzen):

• Eén OpenAI-compatibele API voor 28 ingebouwde provider-adapters, plus provider-eigen passthrough-routes.
• Weighted routing, op CEL gebaseerde routingregels, geordende fallbacks en retries met backoff.
• Virtuele sleutels met budgetten, request- en tokenlimieten, en allowlists voor providers en modellen.
• Exact-match en semantische caching, een MCP-gateway, een prompt-repository en aangepaste Go-plugins.
• Prometheus-metrieken, OpenTelemetry-export en een ingebouwd dashboard.

Er is geen toeslag per token. Je brengt je eigen provider-sleutels mee en betaalt providers rechtstreeks.

Twee OSS-governance-gedragingen bleven overeind toen we ze testten. Een request via een virtuele sleutel voor een model buiten de allowlist van die sleutel werd geweigerd met een 403 model_blocked-fout, dus de allowlist wordt afgedwongen op het moment van het request en niet alleen getoond in de UI. Toen we een ongeldige provider-sleutel stuurden, maskeerde de error body deze als sk-inval***0000, en geen van onze testprompts lekte uit in foutmeldingen of logs.

Twee dingen die we tegenkwamen bij het draaien van OSS waar een security reviewer naar zal vragen

Een verse OSS-installatie staat wijd open. Het quickstart-pad begint zonder authenticatie, zonder vereiste voor virtuele sleutels en zonder CORS-beleid op de inference-API. De beheerderskant staat ook open. Totdat iemand het eerste beheerdersaccount aanmaakt, zeggen Bifrost's eigen docs dat het dashboard en de admin-API "bereikbaar zijn zonder wachtwoord voor iedereen die er naartoe kan routen" (security best practices). De oplossing is een setup_token in config.json of de BIFROST_SETUP_TOKEN-omgevingsvariabele, ingesteld voordat de instantie bereikbaar is. Dat is een redelijke standaard voor een laptop en een valstrik voor alles op een gedeeld netwerk.

Teams konden niet worden aangemaakt via het v2.0.0-dashboard. Klikken op "Create Team" resette het formulier zonder een request te versturen. We hebben dit gereproduceerd op drie instanties bij zowel NPX- als Docker-installaties. De API-call (POST /api/governance/teams) werkte wel, dus dit is een UI-bug en geen governance-gat, maar een nieuwe beheerder krijgt geen foutmelding die hiernaar wijst.

Waar OSS stopt, deel 1: meer dan één node draaien

Dit is de grens die Maxim het duidelijkst trekt, en het is van belang nog voordat er een beveiligingsvraag opkomt.

OSS-replicas communiceren niet met elkaar. Je kunt twee of drie OSS-replicas achter een load balancer draaien voor basis-failover, maar elke replica moet dezelfde statische config.json lezen met de database-gebaseerde configuratie-store uitgeschakeld. Elke wijziging betekent dat bestand bewerken en elke pod herstarten. Een gedeelde Postgres-configuratiestore over OSS-nodes wordt expliciet niet ondersteund (OSS multinode deployment).

De consequenties vloeien daaruit voort:

• Een virtuele sleutel die je op één replica intrekt, wordt nog steeds geaccepteerd door de andere totdat ze herstarten met de nieuwe configuratie.
• Budgetten en rate-limit-tellers worden per pod bijgehouden. Volgens onze lezing van de docs gedraagt een budget dat op drie onafhankelijke replicas wordt afgedwongen zich als drie afzonderlijke budgetten, tenzij je elke aanroeper aan één pod koppelt.
• Bewerkingen in de UI van de ene replica bereiken de andere nooit.

Enterprise voegt een echte cluster toe. Enterprise-pods ontdekken elkaar via een gossip-laag (poort 10101 TCP en UDP) en zenden statuswijzigingen uit via een toegewezen gRPC-kanaal (poort 10102). Het intrekken van een sleutel of een UI-bewerking op één node bereikt elke peer binnen enkele seconden, met eventual consistency in plaats van transactionele consistency (Enterprise clustering). Maxim raadt drie of meer replicas aan, een load balancer die de health controleert, en een hoogbeschikbare PostgreSQL 16+.

Multi-region is alleen voor Enterprise, met beperkingen. Replicas kunnen in meerdere regio's draaien en daartussen synchroniseren, maar duurzame schrijfopdrachten gaan nog steeds naar één PostgreSQL-primary, en je levert zelf de globale load balancer of DNS-failover (cross-region deployment). Eén cluster geeft je geen afzonderlijke data-at-rest-grens per regio.

Slimmere routing is ook Enterprise. Adaptive load balancing beoordeelt providers en sleutels op foutpercentage, latentie en bezetting, en verplaatst verkeer weg van gedegradeerde routes. De gewichten zijn lokaal voor elke node en de drempelwaarden zijn vooraf ingesteld in plaats van configureerbaar (adaptive load balancing). De configureerbare circuit breaker is ook Enterprise, en deze wordt geactiveerd op responsheaders, niet op een latentievenster of foutpercentagedrempel die je zelf definieert.

Wat een enkele OSS-node wel overleeft. We hebben de Postgres-configuratiestore 40 seconden stilgezet onder continu verkeer. De draaiende node bleef elk request afhandelen vanuit het geheugen met nul fouten, /health klapte binnen een halve seconde om naar 503 zodat een load balancer hierop kon reageren, en keerde terug naar 200 ongeveer 0,35 seconden nadat Postgres weer online was. Postgres is een opstart- en persistentie-afhankelijkheid voor één node, geen runtime-afhankelijkheid. Die bevinding geldt om de bovenstaande redenen niet voor multi-node OSS.

Waar OSS stopt, deel 2: de security review

Maxim's eigen matrix plaatst guardrails, SSO, RBAC, vault-ondersteuning, auditlogs, log-exports, in-VPC-deployment en gefedereerde MCP-authenticatie aan de Enterprise-kant (prijzen). De lijst is eenvoudig te lezen. Wat een reviewer nodig heeft, is het detail onder elke regel, inclusief de onderdelen die open blijven, zelfs nadat je hebt betaald.

Menselijke inlog: SSO, SCIM en MFA

OSS heeft alleen lokale beheerdersauthenticatie: een beheerdersgebruikersnaam en wachtwoord, plus virtuele sleutels voor aanroepers. Er is geen IdP-inlog.

Enterprise voegt OAuth 2.0 / OIDC-inlog toe met claim-mapping naar Bifrost-rollen, teams en business units, met handleidingen voor Entra ID en Google Workspace. Het voegt ook inkomende SCIM 2.0 toe op /scim/v2 voor gebruikers- en groepsprovisioning (user provisioning). MFA is geen Bifrost-functie; dat dwing je af in je IdP.

Een hiaat om vroegtijdig aan te kaarten: de prijzenpagina vermeldt SAML, maar we vonden geen SAML-configuratiehandleiding in de docs. Als het beleid van je IdP SAML-only is, vraag Maxim dan om een werkende SAML-opstelling te tonen voordat je er van uitgaat dat het er is. (Als je nog twijfelt tussen de twee protocollen, behandelt onze SAML vs OIDC-gids de overwegingen.)

Machine-identiteit: geen service accounts in beide niveaus

Dit is het identiteitsgat dat teams het laatst opmerken en het meest voelen. Productieverkeer is afkomstig van services, batchjobs, CI-pipelines en agents, niet van mensen, en Bifrost heeft voor hen geen eersteklas identiteit.

In OSS behoort een virtuele sleutel "toe aan één team OF één klant OF geen van beide" (virtual keys). Dat is de volledige lijst met scopes. Er is geen service-account of application principal om een sleutel aan te koppelen, dus een backend-service eindigt met de sleutel van een team of een losstaande sleutel zonder eigenaar. Onder Enterprise datatoegangsbeheer gedraagt een sleutel zonder eigenaar zich workspace-breed (data access control), wat het tegenovergestelde is van least privilege voor een enkele service.

Enterprise voegt door gebruikers beheerde sleutels toe: Access Profiles geven een door beleid beheerde virtuele sleutel uit aan elke in aanmerking komende gebruiker en blokkeren bewerkingen die het beleid zouden verzwakken (Access Profiles). Dat helpt voor mensen. Het geeft je nog steeds geen service account, en geen kortstondige, automatisch geroteerde workload-identiteit van het type SPIFFE. Een virtuele sleutel van Bifrost is in beide niveaus een langstellig bearer secret, en degene die deze bezit is de aanroeper.

De nieuwere Projects-functie van Enterprise verandert hier niets aan. Bifrost's docs omschrijven een project als "een toegangspoort per request en boekhoudkundige scope" die "nooit iets authenticeert", dus een service heeft nog steeds een virtuele sleutel nodig die toebehoort aan een team, een klant of niets (Projects).

Sleutel-levenscyclus: verlopen, rotatie en intrekking

• Verlopen is optioneel. Een sleutel die is aangemaakt zonder expires_at verloopt nooit, en er is geen standaard TTL (create virtual key API).
• Rotatie is handmatig in beide niveaus: geef een nieuwe sleutel uit, zet clients over en schakel vervolgens de oude uit of verwijder deze. Er is geen geplande rotatie, gratieperiode of secret-store-synchronisatie voor virtuele sleutels.
• Intrekking is waar de niveaus scheiden. Op een enkele node is het onmiddellijk. Op multi-replica OSS is er helemaal geen propagatie tot de herstart. Op Enterprise zendt de cluster de wijziging binnen enkele seconden uit. Maxim publiceert geen gemeten propagatietijd, dus als intrekkingssnelheid een controlepunt is in je beveiligingsbeleid, koppel er dan een meting aan tijdens de 14-daagse proefperiode.

Wie wat kan wijzigen: RBAC, datatoegangsbeheer en goedkeuringen

Enterprise RBAC past aanmaak-, lees-, bijwerk- en verwijderrechten (CRUD) toe op beheerdersbronnen: providers, virtuele sleutels, gebruikers, logs, guardrails, clusterinstellingen en MCP-configuratie (RBAC). Datatoegangsbeheer filtert vervolgens wat elke persoon ziet tot hun eigen data, de data van hun team of alles. OSS heeft helemaal geen beheerdersrolmodel; de allowlists voor virtuele sleutels zijn de enige toegangscontrole die het biedt.

Wat ontbreekt in beide niveaus is belangrijk voor wijzigingsbeheer:

• Geen maker-checker of vier-ogen-goedkeuring voor routingregels, guardrails of sleutels. Teams die dit nodig hebben, beoordelen config.json of Helm-waarden in Git.
• Geen algemene ABAC-policy-engine en geen rechten op parameterniveau.
• Geen gedocumenteerde versiehistorie of rollback voor routing- of guardrailregels. Access Profiles zijn de uitzondering.
• Geen gedocumenteerde privacy-waarborgende beheerdersrol of break-glass-procedure voor het lezen van prompt- en responsinhoud. De ingebouwde Admin-rol heeft standaard zichtbaarheid op alle data, en de belangrijkste knop is het uitschakelen van inhoudslogging.

Audit trail

OSS heeft geen auditlog van administratieve wijzigingen. Request-logs leggen verkeer vast, niet wie welke instelling heeft gewijzigd.

Enterprise-auditlogs leggen het tijdstempel, de actie, het resultaat, de actor (gebruiker, API-sleutel of systeem), het doelobject, het requestpad, het IP-adres en de duur vast. Gebeurtenissen kunnen HMAC-gesigneerd worden, geëxporteerd worden als JSON, JSON Lines of RFC 5424 Syslog, en gespiegeld worden naar S3- of GCS-compatibele opslag (audit logs). Twee kanttekeningen voor een auditor: audit-logging kan worden uitgeschakeld, en het later inschakelen van archivering vult eerdere gebeurtenissen niet met terugwerkende kracht aan.

Secrets en versleuteling at rest

OSS slaat provider-sleutels en virtuele sleutelwaarden op in zijn configuratiedatabase. Versleuteling at rest is opt-in: je levert een versleutelingssleutel aan, die Bifrost omzet in een AES-256-sleutel met Argon2id. Laat je deze weg, dan worden die waarden in platte tekst opgeslagen. De sleutel kan ook niet worden gewijzigd nadat de database data bevat zonder de database te wissen (client configuration). env.VAR-referenties houden secrets buiten config.json.

Enterprise voegt AWS Secrets Manager, GCP Secret Manager en HashiCorp Vault toe. Bifrost slaat een referentie op, ververst deze elk uur, en biedt een cache-flush-eindpunt voor onmiddellijke rotatie (secret management). De prijzenpagina vermeldt ook Azure, maar we vonden geen Azure Key Vault-gids in de docs, dus controleer dit als je op Azure zit.

PII, guardrails en wat je netwerk verlaat

Guardrails zijn alleen voor Enterprise. De guardrails-pagina vermeldt 14 detectie-providers: drie beheerd door Bifrost (Prompt Guardrails, Custom Regex en Secrets Detection) en 11 diensten van derden, waaronder Presidio, Azure AI Language PII, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor en CrowdStrike AIDR (guardrails). Regels gebruiken CEL om verkeer te richten op gebruiker, team, klant, sleutel, provider, model of header, op invoer, uitvoer of beide. Custom Regex en Secrets Detection draaien lokaal zonder netwerkafhankelijkheid.

De details die een reviewer zal willen weten:

• Anonimisering (redaction) is niet de standaard. Custom Regex en Secrets Detection staan standaard op block; Presidio en Azure PII staan standaard op detect_only. Je moet action: redact zelf instellen (redaction modes).
• Anonimisering omvat alleen tekst. Afbeeldingen, audio en andere binaire inhoud worden niet geïnspecteerd.
• Prompt Guardrails, de LLM-as-judge-optie, staat standaard alles toe (fails open) als de judge een timeout heeft, een fout geeft of iets retourneert dat hij niet kan parsen.
• Een gehoste detector ziet de ruwe inhoud, zelfs wanneer het uiteindelijke model alleen de geanonimiseerde prompt krijgt.

Self-hosting betekent ook niet dat er niets uit je netwerk weglekt. Prompts gaan naar de modelproviders die je configureert, en inhoud kan naar externe guardrail-diensten en observabiliteitsconnectoren gaan. Eén instelling om te controleren bij elke deployment: het uitschakelen van inhoudslogging op clientniveau geldt niet voor connectoren. BigQuery, Kafka, Pub/Sub, OpenTelemetry en Datadog hebben elk hun eigen vlag, en die sturen standaard de inhoud mee.

Netwerkbeveiliging: TLS, mTLS en FIPS

• Bifrost serveert platte HTTP. TLS-terminatie is de taak van je ingress of load balancer in beide niveaus (security best practices).
• Er is geen native mTLS gedocumenteerd, noch van client naar gateway, noch tussen Enterprise-nodes. Of de clusterpoorten 10101 en 10102 versleuteld en wederzijds geauthenticeerd zijn wordt niet vermeld, dus vraag dit nagevraagd.
• Maxim's beveiligingspagina beweert dat productie-images zijn gebouwd op een FIPS 140-2 gevalideerde basis. Welke image dat betreft, en of dat alleen voor Enterprise geldt, is niet duidelijk (security posture).

Compliance-documentatie: geclaimd vs verifieerbaar

Maxim's marketing claimt SOC 2 Type II, ISO 27001 en een HIPAA BAA, terwijl de productdocs Enterprise-auditcontroles voorzichtiger omschrijven als "SOC 2-vriendelijk". Maxim's trust center was niet bereikbaar tijdens onze review, dus we konden de scope, uitgevende instantie of geldigheidsdatums niet controleren. FedRAMP wordt niet geclaimd. Er is geen openbare DPA of lijst van subverwerkers gevonden. Niets hiervan is bewijs tegen Maxim. Het betekent dat de documentatie een stap in het inkoopproces is, niet iets dat je vanaf de website kunt verifiëren.

De praktische samenvatting: OSS is zelf te hosten, maar een Bifrost-deployment van compliance-kwaliteit is effectief een Enterprise-deployment, en zelfs dan worden service-identiteit, goedkeuringen en gegevensverwijdering op individueel niveau aan jou overgelaten.

Bifrost OSS vs Bifrost Enterprise vs TrueFoundry in één oogopslag

Bifrost-kolommen weerspiegelen Maxim's openbare documentatie en onze OSS v2.0.0-testen. TrueFoundry-mogelijkheden komen uit de TrueFoundry docs.

Kleine lettertjes om te controleren voordat je tekent

• Geen gepubliceerde prijs. Elk Enterprise-pad is "Talk to Us" of "Request License", en er is geen openbare eenheid (per node, per seat of vast tarief). Vraag vroegtijdig een offerte aan; ons prijzenbericht behandelt wat je daarnaast moet modelleren.
• Twee uptime-getallen. De in-VPC-docs vermelden 99,95% per maand. Een Enterprise-marketingpagina zegt 99,999%. Dat is ongeveer 22 minuten tegenover 26 seconden downtime per maand. Zorg dat je het contractuele getal, de credits en de uitzonderingen op schrift krijgt.
• SAML en Azure Key Vault verschijnen op de prijzenpagina zonder bijbehorende installatie-docs.
• Datadog- en BigQuery-connectoren zijn gedocumenteerd zonder labellabel, maar staan op de prijzenpagina vermeld als Enterprise. Generieke OTLP-export is OSS.
• Clustering wordt op twee manieren omschreven. De ene pagina zegt "een gewijzigde versie van RAFT", een andere beschrijft gossip plus gRPC met eventual consistency. Vraag welke consistency-garanties je koopt.
• Upgrades vereisen aandacht. v2.0.0 werd uitgebracht op 26-08-2026. De v1.5.0-release bevatte 16 breaking changes, en databasemigraties kunnen niet worden teruggedraaid, dus maak voor elke upgrade een back-up van Postgres. Enterprise wordt afzonderlijk van OSS van een versie voorzien en is gekoppeld aan een OSS-basis, dus een OSS-fix bereikt Enterprise op het schema van Maxim.
• Ondersteuning is alleen via de community bij OSS. SLA-ondersteuning, private Slack- of Teams-kanalen en 24/7 kritieke ondersteuning zijn Enterprise.

Welk niveau heb je daadwerkelijk nodig?

Blijf op Bifrost OSS als je één node draait, je team klein is, niemand SSO, auditlogs of PII-anonimisering vereist, en je het geen probleem vindt om te herstarten om de configuratie te wijzigen. Stel op dag één een setup-token in en verplicht virtuele sleutels.

Stap over op Bifrost Enterprise als je meer dan één replica met live configuratie, snelle sleutelintrekking of gedeelde budgetten nodig hebt, of als een security review SSO, RBAC, auditlogs, vault-backed secrets of guardrails vereist. Houd rekening met een offerte, niet $0, en plan het beheer van de cluster, de HA Postgres en de globale load balancer in.

Kijk naar een platform-gateway als je vereisten onder meer service-account-identiteiten met rotatie en goedkeuringsvriendelijk wijzigingsbeheer omvatten, of als je liever de database en de cluster van een zelfgehoste AI-gateway niet zelf beheert.

Het TrueFoundry-alternatief

Bifrost Enterprise lost de synchronisatie en de beveiligingschecklists op, maar het is nog steeds infrastructuur die je zelf implementeert, upgradet en beheert. De TrueFoundry AI Gateway heeft een andere vorm, en een paar van de bovenstaande gaten maken dat duidelijk.

• Service-identiteit is ingebouwd. Virtuele accounts zijn niet-menselijke identiteiten voor applicaties, services en CI, elk met hun eigen token en rechten, los van persoonlijke toegangstokens. Tokens kunnen automatisch roteren op een schema met een gratieperiode voor het oude token, e-mail- of Slack-meldingen sturen bij rotatie, en synchroniseren met AWS Secrets Manager, AWS Parameter Store, Google Secret Manager, HashiCorp Vault of Azure Vault (virtual accounts).
• SSO ondersteunt beide protocollen. SAML 2.0 en OIDC werken met Entra ID, Okta, Google Workspace, Keycloak, JumpCloud, OneLogin, Auth0, PingOne, AD FS en anderen, met SCIM-provisioning voor ondersteunde IdPs (SSO and SCIM). Gereguleerde on-premise opstellingen kunnen de control plane rechtstreeks op hun IdP aansluiten.
• Configuratie- en beleidssynchronisatie is de architectuur, geen add-on. Gateway-pods zijn stateless. Ze laden configuratie, gebruikers, virtuele accounts en autorisatieregels uit de control plane en ontvangen updates via een NATS-wachtrij, en de control plane publiceert de volledige configuratie elke 10 minuten opnieuw zodat een gemiste update niet kan leiden tot afwijkingen. Als de control plane uitvalt, blijven gateways doordraaien op de configuratie die ze hebben (gateway plane architecture).
• Audit en guardrails worden standaard meegeleverd. Auditlogs leggen vast wie wat heeft gewijzigd, met een YAML-diff voor configuratiewijzigingen, en zijn beschikbaar via de API (audit logging). Mutatieve guardrails kunnen PII anonimiseren voordat een prompt het model bereikt (how our guardrails work).
• Je kiest zelf wie het beheert. Gebruik de beheerde SaaS-gateway, draai alleen de gateway plane in je cloud, of host het hele platform zelf, inclusief in air-gapped omgevingen (deployment options). Eerlijk is eerlijk bij deze vergelijking: het zelf hosten van de gateway plane valt bij ons ook onder het Enterprise-niveau.

Als je shortlist is teruggebracht tot Bifrost Enterprise en je je zorgen maakt over service-identiteit, wijzigingsbeheer of het zelf draaien van de cluster, bekijk dan hoe de TrueFoundry AI Gateway dit aanpakt of boek een demo en neem je beveiligingsvragenlijst mee.

Gerelateerde artikelen

• Bifrost pricing: OSS, Enterprise costs, and what teams should know
• Bifrost vs LiteLLM
• SCIM provisioning: why deprovisioning is the part everyone gets wrong
• AI gateway on premise: all you need to know

Conclusie

Bifrost Enterprise is het betalen waard zodra je meer dan één node nodig hebt of een security review moet doorstaan, omdat OSS geen replicas kan synchroniseren en geen SSO, RBAC, auditlog of guardrails heeft. Zelfs op Enterprise beheer je de cluster nog steeds zelf, draaien service-workloads nog steeds op langdurige bearer-keys, en hebben beleidswijzigingen nog steeds geen goedkeuringsstap, dus controleer die drie punten ten opzichte van je eigen vereisten. Als ze van belang zijn, boek dan een TrueFoundry-demo en vergelijk ze naast elkaar.