Proposal: migrate the chat frontend from Open WebUI to LibreChat (test instance live) #23
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: co-op/support#23
Reference in new issue
Block a user
Proposal: migrate the chat frontend from Open WebUI to LibreChat
Background
Open WebUI has served us well since launch, but its license now constrains us
in ways that conflict with who we are. Since v0.6.6 (April 2025), Open WebUI
ships under a custom license with a branding-protection clause: the "Open
WebUI" name, logo, and interface identifiers may not be altered or replaced
except under three exemptions — deployments with ≤50 users (rolling 30 days),
written permission from Open WebUI Inc., or a paid enterprise license.
We recently crossed the point where this matters:
member-facing infrastructure. Under the OWUI license, our own PWA name and
icon on members' phones are, strictly, Open WebUI branding that we may not
change. We asked Open WebUI for written permission; an enterprise license
is not something our budget can carry.
the last 30 days). Crossing 50 members puts us formally out of compliance
for the branding we want — and per Open WebUI's own published guidance,
even recoloring the interface toward our identity is restricted without
their enterprise tier.
over branding. But a member-governed co-op should be able to put its own
name on its own service.
The test instance
We've stood up a fully configured LibreChat sandbox:
https://librechat-test.inference.coop — log in with your co-op account
(Cloudron SSO works natively). LibreChat is MIT-licensed: no branding
clause, no co-branding restrictions, our name and mark on everything, at any
scale, forever.
What's already wired up and verified on the sandbox (against our actual
gateway, not a demo):
search_docs)Please poke at it — especially the parts you use daily on the current chat.
Comparison
General features
Our co-op's specific needs and values
Migration costs (the honest column)
stay readable on the current chat (we'd keep it up as a read-only archive
during a transition window), but starting fresh on LibreChat means new
conversations start there. We can export OWUI history to JSON for personal
import; a polished automatic migration is not guaranteed.
endpoints work; the UI wiring is configured but member-tested).
opt-in docs MCP tool. Members who liked ambient doc lookup will need to
enable the tool (once, then it persists per conversation type).
settings layout differ from OWUI. Members will need a short adjustment
period (the test instance is the place to form an opinion).
What we'd propose
their daily workflows, and report in this thread.
the co-op chat at chat.inference.coop.
transition window, migrate member keys (automatic at first SSO login on
the new frontend), and sunset the old frontend after an agreed period.
Open questions for members
your documents? Voice? Multi-model comparison? MCP tools?)
archive-and-read enough?
This proposal was prepared by the stewarding bot at the general manager's
request. The comparison reflects hands-on testing against the co-op's
production gateway (2026-10-18), not vendor documentation. The test instance
runs LibreChat 0.8.8 (MIT) with the co-op's SSO, gateway, and billing
integration.
Assessment of the three concerns
Good catches — here's what we verified against the actual 0.8.8 build on the
test instance (not the docs, which lag behind this version).
1. Generic system prompt (custom instructions)
Partially correct. LibreChat ships per-user Custom Instructions (the
ChatGPT-style global system-prompt suffix that applies to every conversation)
— it's present in the build and doesn't require agents. That covers the
"generic extension" use case.
What you can't do in 0.8.8 is set a deployment-wide system prompt from
the admin config the way Open WebUI's model "system prompt" field works per
model. Workarounds, in order of preference:
preset.promptPrefix— we can bake co-opdefaults (e.g. "You are the Inference Cooperative assistant...") into the
model specs so every model carries a base prompt without agents.
2. SVG / HTML rendering
Mermaid renders inline ✓. For SVG and HTML you're right that the good
experience is the artifact panel — but it is not agents-only. The
"Open as artifact" action is present in this build and triggers client-side
whenever a response contains an SVG/HTML/React code block, regardless of
endpoint. The nuance vs Open WebUI: OWUI renders SVG/HTML inline in the chat
flow; LibreChat opens them in a side panel (artifacts). Same capability,
slightly different presentation.
3. Image generation
Mostly correct for the UI today, but the path exists. Verified directly
against our gateway:
regolo/qwen-imageworks through the OpenAIimages-generations endpoint (returns images, 200). LibreChat 0.8.8's native
image-generation surface is the agent image-gen tool (which can call that
same endpoint), and the older standalone DALL-E-style integration for
non-agent endpoints still exists in the codebase but is thinly documented in
this version. Realistic outcome: image generation on LibreChat is a
one-click tool inside a conversation with an agent, rather than picking
"qwen-image" from the model picker like on Open WebUI. We'll test exactly
how that feels with the Regolo model and report here.
Summary
None of these are blockers, but #3 is a real UX difference from Open WebUI —
please weigh in if image generation is central to your workflow, and we'll
make sure the agent setup makes it frictionless before any decision.
We now have a working system that hacks LibreChat's MCP system to enable easy access to image generation in ordinary chats. Just choose
inference-imagefrom the MCP Servers drop-down.Still doing some tweaking, but the basic flow seems to be working, which is really exciting.