Open WebUI with Bifrost: One Gateway for Every Model

Open WebUI connects to any OpenAI-compatible API endpoint, which makes it a practical front end for a self-hosted, ChatGPT-style chat experience. The friction starts when a team needs more than one model: managing separate provider connections, API keys, and usage limits inside Open WebUI is repetitive and hard to govern. Bifrost, the open-source AI gateway built in Go by Maxim AI, removes that friction by sitting between Open WebUI and every provider as a single connection. Running Open WebUI with Bifrost gives the interface access to every model you configure through one OpenAI-compatible endpoint, with virtual keys, budgets, and observability managed centrally. This guide covers how to connect the two and what you gain from routing Open WebUI traffic through one gateway.

What Is Open WebUI and Why Pair It with an AI Gateway

Open WebUI is an open-source, self-hosted chat interface that talks to OpenAI-compatible APIs, Ollama, and other backends. An AI gateway is a unified entry point that routes, authenticates, observes, and governs traffic to multiple LLM providers from a single API. Pairing the two means Open WebUI sends one request format to one endpoint, and the gateway handles provider selection, key management, and logging behind it.

Without a gateway, every provider you want inside Open WebUI is a separate connection with its own URL, key, and model list. With Bifrost as the single connection, the chat interface stays simple while provider routing, governance, and monitoring move into one control plane. The Bifrost gateway exposes an OpenAI-compatible /v1 endpoint, so Open WebUI treats it like any other OpenAI connection and requires no custom adapter. Each request flows through a single pipeline that selects the provider, applies policy, and logs the call before forwarding it.

Why Connect Open WebUI to Bifrost

Routing Open WebUI through Bifrost, the AI gateway, turns a single-purpose chat front end into a governed, multi-provider workspace. The gain is not just more models; it is centralized control over cost, access, and reliability for every conversation that passes through the interface.

Key benefits of running Open WebUI with Bifrost:

• Any model through one connection: Bifrost unifies access to 1000+ models across 20+ supported providers, so a single Open WebUI connection reaches all of them.
• Governance with virtual keys: Virtual keys let you set budgets, rate limits, and provider access per user or team without touching the Open WebUI configuration.
• Built-in observability: Every request from Open WebUI is logged, so usage, latency, and cost are visible across the team without instrumenting the interface.
• Automatic failover: Provider failover reroutes requests when a provider returns errors, so a chat session continues instead of failing.
• Cost reduction with caching: Semantic caching returns stored responses for semantically similar prompts, cutting cost and latency for repeated queries.
• Low overhead at scale: Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks, so the gateway does not become a bottleneck.

For teams standardizing how staff access models, this combination centralizes spend and policy in one place. The governance resource page outlines how budgets and access rules map to individual keys.

How to Connect Open WebUI to Bifrost

Connecting Open WebUI to Bifrost takes four steps: run Open WebUI, add Bifrost as an OpenAI connection, confirm model discovery, and start chatting. Because Bifrost is a drop-in replacement for the OpenAI API, the only value Open WebUI needs is the gateway's base URL.

Step 1: Install Open WebUI

Install Open WebUI using the method that fits your environment. It runs via Docker, Docker Compose, or Kubernetes, and the Open WebUI installation guide covers each option. If Bifrost is not yet running, the gateway setup guide walks through starting it with zero configuration.

Step 2: Add Bifrost as a Connection

In Open WebUI, open Admin Settings, go to Connections, select OpenAI, and click Add Connection. Configure two fields:

• URL: http://localhost:8080/v1 (or your Bifrost host, for example https://bifrost.yourcompany.com/v1)
• API Key: your Bifrost virtual key if authentication is enabled; otherwise leave it empty or use dummy

Save the connection. Open WebUI now sends all chat traffic for this connection to the gateway.

Step 3: Confirm Model Discovery

Open WebUI fetches available models from Bifrost's /v1/models endpoint. If auto-detection does not return the models you expect, or you want to limit which appear, add model IDs to the Model IDs (Filter) allowlist in the connection settings. Use the Bifrost provider/model format, for example:

openai/gpt-5
anthropic/claude-sonnet-4-5-20250929
gemini/gemini-2.5-pro
groq/llama-3.3-70b-versatile

Provider setup happens once in the gateway, not in Open WebUI, where you add provider keys and models when configuring Bifrost.

Step 4: Start Chatting

Select a Bifrost model from the chat model selector and start a conversation. Requests now flow from Open WebUI to the gateway, which routes each one to the correct provider based on the model name.

Docker Networking Notes

When Open WebUI and Bifrost run in different network contexts, the base URL changes:

• Open WebUI and Bifrost on the same host: http://localhost:8080/v1
• Open WebUI in Docker, Bifrost on the host: http://host.docker.internal:8080/v1
• Both in the same Docker network: http://bifrost-container-name:8080/v1

You can also set the connection through environment variables when launching Open WebUI:

OPENAI_API_BASE_URLS="<http://localhost:8080/v1>"
OPENAI_API_KEYS="your-bifrost-virtual-key"

Using Multiple Providers Through One Connection

Bifrost routes each request to the right provider based on the model name, so one Open WebUI connection reaches every provider you have configured. The provider/model-name format selects the destination through the single /v1 endpoint, with no per-provider setup inside Open WebUI.

This is the practical payoff of running Open WebUI with Bifrost: a user can switch from a high-capability model to a faster one mid-workflow without changing connections. Use openai/gpt-5 or anthropic/claude-sonnet-4-5-20250929 for complex conversations, then groq/llama-3.3-70b-versatile for quick responses, all from the same model selector. The supported providers matrix lists every provider available through the provider/model convention.

Multimodal workflows route through the same gateway. Open WebUI can use a Bifrost model as its image generation engine (set the image engine to OpenAI and point it at the gateway URL), and vision-capable models such as openai/gpt-4o work through the main connection for image understanding. Both paths reach providers through Bifrost without separate credentials in Open WebUI.

Governance and Observability for Team Deployments

For multi-user deployments, Bifrost is built to enforce policy and surface usage that a bare chat interface cannot. Governance and observability are where the gateway earns its place in front of Open WebUI.

Each connection can carry its own virtual key, and each key can have separate rate limits, budgets, and provider access rules. For a team, that means creating distinct keys per group so finance, engineering, and support each get their own limits and model permissions, all configured in the gateway rather than in Open WebUI. The governance overview explains how hierarchical budgets apply at the key, team, and customer level.

On the observability side, all Open WebUI traffic through Bifrost is logged and can be filtered by provider, model, or conversation content. This gives platform teams a single view of who is using which models and at what cost. Bifrost's observability features also export native Prometheus metrics and OpenTelemetry traces for existing monitoring stacks.

Regulated and large-scale deployments add further requirements. Bifrost Enterprise supports role-based access control, SSO through OpenID Connect, clustering for high availability, and immutable audit logs for SOC 2, GDPR, HIPAA, and ISO 27001 compliance. Bifrost also supports air-gapped and in-VPC deployment, so Open WebUI and the gateway can run entirely inside private infrastructure.

Common Questions About Open WebUI and Bifrost

Does Open WebUI work with any LLM provider through Bifrost?

Yes. Open WebUI connects to Bifrost as a single OpenAI-compatible endpoint, and the gateway routes to any configured provider based on the model name. Adding a new provider happens in Bifrost, so no change is needed in Open WebUI.

Do I need to change Open WebUI to switch models or providers?

No. Because routing is keyed to the provider/model name, users switch models from the standard chat selector. The same connection reaches every provider, so there is no per-provider configuration inside the interface.

Can I enforce per-user budgets and limits in Open WebUI?

Yes, through Bifrost virtual keys. Assign a separate key per user or team and set budgets, rate limits, and provider access on each key. Open WebUI passes the key with each request, and the gateway enforces the policy.

Is the integration suitable for production and enterprise use?

Yes. Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained performance benchmarks, and supports clustering, RBAC, SSO, audit logs, and in-VPC deployment for enterprise requirements.

Getting Started with Bifrost

Running Open WebUI with Bifrost turns a self-hosted chat interface into a governed, multi-provider workspace: one connection, every model, and centralized control over cost, access, and observability. The setup is a four-step connection, and everything beyond it (provider routing, virtual keys, logging, failover) is handled by the gateway. To see how the AI gateway fits into a team-wide Open WebUI deployment, book a demo with the Bifrost team.