Bifrost Enterprise vs OSS: What You Actually Get

Bifrost Enterprise is the paid tier of Bifrost, the open-source LLM gateway from Maxim AI. The free OSS tier is already a complete gateway, so the useful question for a buying team is narrower than “which features do we need?” It comes down to two things: how many replicas will this run on, and who has to sign off on security? Those two answers decide whether the Bifrost LLM gateway stays free or turns into a sales conversation.

We ran Bifrost OSS v2.0.0 ourselves for our hands-on review ([USER TO FILL: link to the Bifrost review post when live]), which covers performance. We could not get an Enterprise license, so everything we say about Enterprise comes from Maxim’s own documentation and pricing page. Where something comes from our own testing, we say so.

If you only want the cost picture, our Bifrost pricing breakdown covers license, hosting and ops. This post is about what each tier actually does, with most of the space given to identity and security, because that is where the paid tier earns its money.

What the free Bifrost OSS tier already covers

Bifrost OSS is a real open source AI gateway, not a demo edition. It is Apache-2.0, self-hosted, and has no vendor-imposed request, token or seat limits. Maxim’s own feature matrix puts these in the free tier (pricing):

• One OpenAI-compatible API in front of 28 built-in provider adapters, plus provider-native passthrough routes.
• Weighted routing, CEL-based routing rules, ordered fallbacks and retries with backoff.
• Virtual keys with budgets, request and token limits, and provider and model allowlists.
• Exact-match and semantic caching, an MCP gateway, a prompt repository and custom Go plugins.
• Prometheus metrics, OpenTelemetry export and a built-in dashboard.

There is no per-token markup. You bring your own provider keys and pay providers directly.

Two OSS governance behaviors held up when we tested them. A request through a virtual key for a model outside that key’s allowlist was rejected with a 403 model_blocked error, so the allowlist is enforced at request time and not only shown in the UI. When we sent a bad provider key, the error body masked it as sk-inval***0000, and none of our test prompts leaked into error messages or logs.

Two things we hit running OSS that a security reviewer will ask about

A fresh OSS install is open. The quickstart path starts with no authentication, no virtual-key requirement and no CORS policy on the inference API. The admin side is open too. Until someone creates the first admin account, Bifrost’s own docs say the dashboard and admin API are “reachable without a password from anyone who can route to it” (security best practices). The fix is a setup_token in config.json or the BIFROST_SETUP_TOKEN environment variable, set before the instance is reachable. That is a reasonable default for a laptop and a trap for anything on a shared network.

Teams could not be created from the v2.0.0 dashboard. Clicking “Create Team” reset the form without sending a request. We reproduced it on three instances across both the NPX and Docker installs. The API call (POST /api/governance/teams) worked, so this is a UI bug and not a governance gap, but a first-time admin gets no error message pointing at it.

Where OSS stops, part 1: running more than one node

This is the line Maxim draws most clearly, and it matters before any security question does.

OSS replicas do not talk to each other. You can run two or three OSS replicas behind a load balancer for basic failover, but each one must read the same static config.json with the database-backed config store switched off. Any change means editing that file and restarting every pod. A shared Postgres config store across OSS nodes is explicitly not supported (OSS multinode deployment).

The consequences follow from that:

• A virtual key you revoke on one replica is still honored by the others until they restart with the new config.
• Budgets and rate-limit counters are kept per pod. By our reading of the docs, a budget enforced on three independent replicas behaves like three separate budgets unless you pin each caller to one pod.
• Edits made in one replica’s UI never reach the others.

Enterprise adds a real cluster. Enterprise pods discover each other over a gossip layer (port 10101 TCP and UDP) and broadcast state changes over a dedicated gRPC channel (port 10102). A key revocation or UI edit on one node reaches every peer within seconds, with eventual rather than transactional consistency (Enterprise clustering). Maxim recommends three or more replicas, a load balancer that checks health, and a highly available PostgreSQL 16+.

Multi-region is Enterprise only, with limits. Replicas can run in several regions and sync across them, but durable writes still go to one PostgreSQL primary, and you supply the global load balancer or DNS failover yourself (cross-region deployment). One cluster does not give you a separate data-at-rest boundary per region.

Smarter routing is also Enterprise. Adaptive load balancing scores providers and keys on error rate, latency and utilization and shifts traffic away from degraded routes. Its weights are local to each node and its thresholds are pre-tuned rather than configurable (adaptive load balancing). The configurable circuit breaker is Enterprise too, and it triggers on response headers, not on a latency window or error-rate threshold you define.

What a single OSS node does survive. We stopped the Postgres config store for 40 seconds under steady traffic. The running node kept serving every request from memory with zero errors, /health flipped to 503 within half a second so a load balancer could act on it, and it returned to 200 about 0.35 seconds after Postgres came back. Postgres is a startup and persistence dependency for one node, not a runtime one. That finding does not carry over to multi-node OSS, for the reasons above.

Where OSS stops, part 2: the security review

Maxim’s own matrix puts guardrails, SSO, RBAC, vault support, audit logs, log exports, in-VPC deployment and federated MCP auth on the Enterprise side (pricing). The list is easy to read. What a reviewer needs is the detail under each line, including the parts that stay open even after you pay.

Human sign-in: SSO, SCIM and MFA

OSS has local admin authentication only: an admin username and password, plus virtual keys for callers. There is no IdP login.

Enterprise adds OAuth 2.0 / OIDC login with claim mapping into Bifrost roles, teams and business units, with setup guides for Entra ID and Google Workspace. It also adds inbound SCIM 2.0 at /scim/v2 for user and group provisioning (user provisioning). MFA is not a Bifrost feature; you enforce it in your IdP.

One gap to raise early: the pricing page lists SAML, but we found no SAML configuration guide in the docs. If your IdP policy is SAML-only, ask Maxim to show you a working SAML setup before you assume it is there. (If you are still deciding between the two protocols, our SAML vs OIDC guide covers the trade-offs.)

Machine identity: no service accounts in either tier

This is the identity gap teams notice last and feel most. Production traffic comes from services, batch jobs, CI pipelines and agents, not people, and Bifrost has no first-class identity for them.

In OSS, a virtual key “belongs to either one team OR one customer OR neither” (virtual keys). That is the full list of scopes. There is no service-account or application principal to attach a key to, so a backend service ends up holding either a team’s key or an unowned standalone key. Under Enterprise data access control, an unowned key behaves workspace-wide (data access control), which is the opposite of least privilege for a single service.

Enterprise adds user-owned keys: Access Profiles issue a policy-managed virtual key to each eligible user and block edits that would weaken the policy (Access Profiles). That helps for people. It still gives you no service account, and no short-lived, automatically rotated workload identity of the SPIFFE kind. A Bifrost virtual key is a long-lived bearer secret in both tiers, and whoever holds it is the caller.

Enterprise’s newer Projects feature does not change this. Bifrost’s docs describe a project as “a per-request access gate and accounting scope” that “never authenticates anything,” so a service still needs a virtual key that belongs to a team, a customer or nothing (Projects).

Key lifecycle: expiry, rotation and revocation

• Expiry is optional. A key created without expires_at never expires, and there is no default TTL (create virtual key API).
• Rotation is manual in both tiers: issue a new key, move clients to it, then disable or delete the old one. There is no scheduled rotation, grace period or secret-store sync for virtual keys.
• Revocation is where the tiers split. On a single node it is immediate. On multi-replica OSS there is no propagation at all until restart. On Enterprise the cluster broadcasts the change within seconds. Maxim does not publish a measured propagation time, so if revocation speed is a control in your security policy, time it during the 14-day trial.

Who can change what: RBAC, data access control and approvals

Enterprise RBAC applies create, read, update and delete permissions to admin resources: providers, virtual keys, users, logs, guardrails, cluster settings and MCP configuration (RBAC). Data access control then filters what each person sees to their own data, their team’s data or everything. OSS has no admin role model at all; the virtual-key allowlists are the only access control it offers.

What is missing in both tiers matters for change control:

• No maker-checker or four-eyes approval for routing rules, guardrails or keys. Teams that need one review config.json or Helm values in Git.
• No general ABAC policy engine and no parameter-level permissions.
• No documented version history or rollback for routing or guardrail rules. Access Profiles are the exception.
• No documented privacy-preserving admin role or break-glass flow for reading prompt and response content. The built-in Admin role defaults to all-data visibility, and the main lever is turning content logging off.

Audit trail

OSS has no audit log of administrative changes. Request logs record traffic, not who changed which setting.

Enterprise audit logs record the timestamp, action, outcome, actor (user, API key or system), target resource, request path, IP and duration. Events can be HMAC-signed, exported as JSON, JSON Lines or RFC 5424 Syslog, and mirrored to S3 or GCS-compatible storage (audit logs). Two caveats for an auditor: audit logging can be switched off, and enabling archival later does not backfill earlier events.

Secrets and encryption at rest

OSS stores provider keys and virtual-key values in its config database. Encryption at rest is opt-in: you supply an encryption key, which Bifrost turns into an AES-256 key with Argon2id. Leave it out and those values are stored in plaintext. The key also cannot be changed after the database has data in it without clearing the database (client configuration). env.VAR references keep secrets out of config.json.

Enterprise adds AWS Secrets Manager, GCP Secret Manager and HashiCorp Vault. Bifrost stores a reference, refreshes it hourly, and exposes a cache-flush endpoint for immediate rotation (secret management). The pricing page also lists Azure, but we found no Azure Key Vault guide in the docs, so confirm it if you are on Azure.

PII, guardrails and what leaves your network

Guardrails are Enterprise only. The guardrails page lists 14 detection providers: three managed by Bifrost (Prompt Guardrails, Custom Regex and Secrets Detection) and 11 third-party services including Presidio, Azure AI Language PII, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor and CrowdStrike AIDR (guardrails). Rules use CEL to target traffic by user, team, customer, key, provider, model or header, on input, output or both. Custom Regex and Secrets Detection run locally with no network dependency.

The details a reviewer will want:

• Redaction is not the default. Custom Regex and Secrets Detection default to block; Presidio and Azure PII default to detect_only. You must set action: redact yourself (redaction modes).
• Redaction covers text only. Images, audio and other binary content are not inspected.
• Prompt Guardrails, the LLM-as-judge option, fails open if the judge times out, errors or returns something it cannot parse.
• A hosted detector sees the raw content, even when the final model only gets the redacted prompt.

Self-hosting also does not mean nothing leaves your network. Prompts go to whichever model providers you configure, and content can go to external guardrail services and to observability connectors. One setting to check on every deployment: turning off content logging at the client level does not apply to connectors. BigQuery, Kafka, Pub/Sub, OpenTelemetry and Datadog each have their own flag, and those default to sending content.

Network posture: TLS, mTLS and FIPS

• Bifrost serves plain HTTP. TLS termination is your ingress or load balancer’s job in both tiers (security best practices).
• No native mTLS is documented, either client to gateway or between Enterprise nodes. Whether the cluster ports 10101 and 10102 are encrypted and mutually authenticated is not stated, so ask.
• Maxim’s security page claims production images are built on a FIPS 140-2 validated base. Which image that covers, and whether it is Enterprise only, is not clear (security posture).

Compliance paperwork: claimed vs checkable

Maxim’s marketing claims SOC 2 Type II, ISO 27001 and a HIPAA BAA, while the product docs describe Enterprise audit controls more cautiously as “SOC 2 friendly.” Maxim’s trust center was not reachable during our review, so we could not check scope, issuing body or validity dates. FedRAMP is not claimed. No public DPA or subprocessor list turned up. None of this is evidence against Maxim. It means the paperwork is a procurement step, not something you can verify from the website.

The practical summary: OSS is self-hostable, but a compliance-grade Bifrost deployment is effectively an Enterprise deployment, and even then service identity, approvals and subject-level data deletion are left to you.

Bifrost OSS vs Bifrost Enterprise vs TrueFoundry at a glance

Bifrost columns reflect Maxim’s public documentation and our OSS v2.0.0 testing. TrueFoundry capabilities are from the TrueFoundry docs.

Fine print to check before you sign

• No published price. Every Enterprise path is “Talk to Us” or “Request License,” and there is no public unit (per node, per seat or flat). Get a quote early; our pricing post covers what to model alongside it.
• Two uptime numbers. The in-VPC docs say 99.95% monthly. An Enterprise marketing page says 99.999%. That is roughly 22 minutes versus 26 seconds of downtime a month. Get the contractual number, credits and exclusions in writing.
• SAML and Azure Key Vault appear on the pricing page without matching setup docs.
• Datadog and BigQuery connectors are documented with no tier label but listed as Enterprise on the pricing page. Generic OTLP export is OSS.
• Clustering is described two ways. One page says “a modified version of RAFT,” another describes gossip plus gRPC with eventual consistency. Ask which consistency guarantees you are buying.
• Upgrades need care. v2.0.0 shipped on 2026-08-26. The v1.5.0 release carried 16 breaking changes, and database migrations cannot be rolled back, so back up Postgres before every upgrade. Enterprise is versioned separately from OSS and pins an OSS base, so an OSS fix reaches Enterprise on Maxim’s schedule.
• Support is community-only on OSS. SLA-backed support, private Slack or Teams channels and 24/7 critical support are Enterprise.

Which tier do you actually need?

Stay on Bifrost OSS if you run one node, your team is small, nobody requires SSO, audit logs or PII redaction, and you are comfortable restarting to change config. Set a setup token and require virtual keys on day one.

Move to Bifrost Enterprise if you need more than one replica with live config, fast key revocation or shared budgets, or if a security review requires SSO, RBAC, audit logs, vault-backed secrets or guardrails. Budget for a quote, not $0, and plan to own the cluster, the HA Postgres and the global load balancer.

Look at a platform gateway if your requirements include service-account identities with rotation, approval-friendly change control, or you would rather not run a self hosted AI gateway’s database and cluster yourself.

The TrueFoundry alternative

Bifrost Enterprise fixes sync and the security checklist, but it is still infrastructure you deploy, upgrade and operate yourself. The TrueFoundry AI Gateway takes a different shape, and a few of the gaps above are where that shape shows.

• Service identity is built in. Virtual accounts are non-user identities for applications, services and CI, each with its own token and permissions, separate from personal access tokens. Tokens can auto-rotate on a schedule with a grace period for the old token, send email or Slack notices on rotation, and sync into AWS Secrets Manager, AWS Parameter Store, Google Secret Manager, HashiCorp Vault or Azure Vault (virtual accounts).
• SSO covers both protocols. SAML 2.0 and OIDC work with Entra ID, Okta, Google Workspace, Keycloak, JumpCloud, OneLogin, Auth0, PingOne, AD FS and others, with SCIM provisioning for supported IdPs (SSO and SCIM). Regulated on-prem setups can connect the control plane straight to their IdP.
• Config and policy sync is the architecture, not an add-on. Gateway pods are stateless. They load config, users, virtual accounts and authorization rules from the control plane and receive updates over a NATS queue, and the control plane republishes the full config every 10 minutes so a missed update cannot drift. If the control plane goes down, gateways keep serving on the config they have (gateway plane architecture).
• Audit and guardrails ship with the product. Audit logs record who changed what, with a YAML diff for config changes, and are available through the API (audit logging). Mutating guardrails can redact PII before a prompt reaches the model (how our guardrails work).
• You choose who operates it. Use the managed SaaS gateway, run only the gateway plane in your cloud, or self-host the whole platform, including in air-gapped environments (deployment options). To be fair to the comparison: self-hosting the gateway plane is on our Enterprise tier too.

If your shortlist is down to Bifrost Enterprise and you are worried about service identity, change control or running the cluster yourself, see how the TrueFoundry AI Gateway handles it or book a demo and bring your security questionnaire.

Related reading

• 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

Conclusion

Bifrost Enterprise is worth paying for once you need more than one node or have to pass a security review, because OSS cannot sync replicas and has no SSO, RBAC, audit log or guardrails. Even on Enterprise, you still operate the cluster yourself, service workloads still run on long-lived bearer keys, and policy changes still have no approval step, so check those three against your own requirements. If they matter, book a TrueFoundry demo and compare them side by side.