Open WebUI with Hivenet Router: a team chat guide

Open WebUI can give a team a browser-based chat interface for models reached through Hivenet Router. The useful separation is between the interface, the routing service, and the inference backend: Open WebUI manages the conversation, Router chooses an eligible destination, and the backend generates the answer.

Start with one approved chat model and a dedicated Router client key. Verify that simple connection before adding more models or optional features. This guide covers the server-managed connection, shared access, background requests, and the checks needed before inviting a team.

The instructions were checked against Open WebUI 0.13.3 source and current Router documentation on November 11, 2026. They have not been validated in a running Open WebUI-to-Router deployment. Treat the acceptance checks below as work to complete in your environment, not reported test results.

Decide where each part runs

A typical request travels from the browser to the Open WebUI server, through Router and its selected agent, then to an inference backend. Hivenet Router provides routing and policy controls; it does not load or execute model weights.

A CPU VM can host the interface and routing services when inference happens elsewhere. Size that VM for its actual services, concurrent sessions, storage, and optional processing. A GPU is not required merely to display remote model responses, but local embedding, speech, or model workloads change the requirements. Do not reuse an idle-memory figure as a production capacity estimate.

Before configuring the UI, have a reachable Router endpoint, a client key, an eligible agent with the llm capability, and a working Chat Completions backend. Use the Open WebUI installation guide for the application itself. Pin a release for your deployment and preserve its data directory. This article starts at the connection between services, rather than assuming an empty VM already contains them.

Check Router before adding the interface

Make the first checks from the network where the Open WebUI server will run. Successful access from your laptop does not prove that a container can resolve the same hostname, trust its certificate, or pass a firewall.

With the intended client key, request GET /v1/models and record the exact ID of an allowed chat model. Router's model catalog reference explains the capability information. A catalog can contain embedding and reranking models too; those are not interchangeable with an LLM at the chat endpoint.

Next, send a short text request to POST /v1/chat/completions using that ID. Repeat with streaming enabled and check that the answer arrives incrementally and finishes. The Chat Completions reference describes the request path and forwarding behavior. Passing model discovery alone does not prove that a backend can complete a request.

Use a harmless prompt, such as asking for three short color names. Record the status and request identifier without copying the credential into a ticket or screenshot. If these direct checks fail, resolve the Router, key, network, or backend issue before investigating the browser interface.

Add the server-managed connection

In Open WebUI, open Settings → Admin → Connections, then add an OpenAI-compatible connection. These are instance-wide settings. Personal direct connections are a different feature and are outside this guide; the settings reference explains the distinction.

The hostname above is a placeholder for your deployment, not a public Hivenet service address. Enter the raw client key in the key field; Open WebUI supplies the Bearer authorization header. Do not use a Router administrator credential.

The official Router integration guide specifies Chat Completions. Router does not currently expose the /v1/responses endpoint, so selecting the Responses API type changes the request to an unsupported route.

Use Open WebUI's Verify Connection control, then save and check the model selector. Its provider connection guide distinguishes verification from saving: verification calls the model endpoint; saving a connection does not test inference. Keep the initial configuration to one LLM so that a wrong model choice is easy to spot.

Use the address the server can reach

Inside a container, localhost refers to that container. If Router is a separate service on the same Compose network, use its actual service name and internal port. If it runs on the host, use a supported host address; Linux setups may require a host-gateway mapping. If Router is remote, use its reachable HTTPS hostname.

A base URL normally ends in /v1. Do not paste the full chat endpoint into it: the client appends the endpoint path. Likewise, a missing version prefix can send requests to the wrong route. When troubleshooting a 404, inspect the effective request path before changing credentials.

For a shared remote instance, provide HTTPS access to Open WebUI and protect its administration surface. Keep the initial account setup private, review signup and approval settings, and test with a regular user as well as an administrator. Limit access to the required people before sharing the URL.

Apply access rules at both layers

Open WebUI controls which users and groups can use its models. Router controls what the upstream credential may invoke. A model hidden in a dropdown is not a substitute for a restriction on the key.

Configure explicit Router access for the chat and task models you intend to allow. Router's model restriction documentation distinguishes static models, dynamic allowed_models, and strict per-model quotas. An empty allowlist is not a deny-all policy when no strict per-model quota is configured. Model IDs are case-sensitive.

For a shared server connection, users send requests with the same configured client credential. Their separate Open WebUI accounts do not automatically become separate Router tenants or independent Router quotas. Plan the key's request and token budget for the combined workload, following the API-key reference.

If departments need separate upstream budgets or model rights, design separate credentials and enforce who can use each connection. Separate deployments may be appropriate when the operator or data-storage boundary must also differ. Forwarding an Open WebUI user-information header does not by itself make Router authenticate that person or assign them a separate budget.

Account for requests the user does not type

A conversation can trigger title generation, tags, follow-up suggestions, or other background work. One message in the chat window therefore does not necessarily equal one inference request. Make the first test with optional features reduced, then enable them deliberately while checking traffic.

Open WebUI's configuration reference documents TASK_MODEL_EXTERNAL for tasks using OpenAI-compatible models, along with controls such as ENABLE_TITLE_GENERATION. If you choose a separate task model, verify its exact ID, access rights, availability, and quota. A working chat model does not guarantee that a title-generation request will succeed.

Check the effective saved settings after changing configuration. With persistent configuration enabled, stored values can take precedence over environment values on later starts. Turning persistence off changes whether UI edits survive restarts; it is not a harmless universal fix for an ignored setting.

Check streaming, errors, and retained data

Test a short answer and a longer streamed answer in the browser. Watch for tokens arriving throughout the response rather than all at once. If a direct stream works but the browser waits until the end, inspect buffering and timeouts along the proxy path. Compare the UI action with Router audit records to identify the selected model and extra requests.

Then use controlled negative checks in a test environment: an invalid key should fail, a disallowed model should be denied, and an unavailable backend should produce a recognizable failure. An HTTP 200 at the start of a stream is not evidence that the whole answer completed. Our inference metrics guide explains how to distinguish response timing from completed work.

Finally, recreate the application with its intended persistent storage and confirm that the approved connection and a harmless test chat remain. Back up the actual database, uploads, configuration, and required secrets using a consistent method. Test restoration separately before an upgrade; reverting an image does not undo a database migration.

Define what “private team chat” means

Document which model endpoints receive prompts and context, who operates the application and backups, and what chat or request data is retained. Self-hosting the interface does not make a configured external model private. Open WebUI's privacy guidance also distinguishes hiding chats from admins in the interface from preventing privileged operators from accessing stored data.

Keep tools, file uploads, web search, and direct connections outside the first rollout unless you have separately reviewed their data paths and permissions. Leave arbitrary OpenAI API passthrough disabled. Plain chat compatibility does not establish that retrieval, voice, tool calls, or every model-specific parameter will work; our OpenAI-compatible API guide provides a broader compatibility checklist.

Invite the team when discovery, completed streaming, denied access, shared usage, and recovery have each been checked. Keep the release versions, owner, allowed models, and evidence with the deployment. That record makes the next connection change or upgrade easier to assess than a single screenshot of a successful reply.