Contributing
Help build the AI interface everyone deserves.
Open WebUI is an independent project built and maintained by a small, dedicated core team. The most useful ways to contribute are testing dev builds, filing clear bug reports, explaining use cases in Discussions, improving docs, and translating the UI. Maintainers evaluate and develop code changes internally; code pull requests require an explicit maintainer request, with an exception for changes limited to i18n/localization. This page explains how to get involved and what to expect.
Code of Conduct
All contributors and community participants must follow the Code of Conduct. We operate under a zero-tolerance policy: disrespectful, demanding, or hostile behavior results in immediate action without prior warning.
Open WebUI is led by a small core team and supported by contributors across the project. Treat every interaction with professionalism and respect.
Ways to Contribute
Test the development branch
One of the most valuable contributions requires no code at all. Run the dev branch, use it daily, and report what breaks.
docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:devThe dev branch moves fast, so pull updates regularly. If Docker is not your preference, follow the Developing Open WebUI instead.
Report issues on GitHub with clear reproduction steps. Community testing helps us deliver high-quality releases.
Submit code
We develop and refine solutions internally because external implementations usually require substantial reworking to fit the project. We accept code PRs only when we have explicitly requested them, or when the changes are limited to i18n/localization. This requirement covers bug fixes, features, refactors, dependency changes, UI changes, and test-only changes, regardless of patch size, passing checks, or whether the code was written by hand or with AI assistance. An acknowledged bug or a positive response to an idea is not a request for an implementation. PRs opened outside this process are generally closed without review.
We monitor and verify every issue, and often already have a working solution internally that has not been pushed while we evaluate and refine the approach. An issue remaining open, without a public response or linked PR, does not mean it has gone unnoticed or that implementation work is available to take on. A working fix still needs to fit the project's architecture, existing behavior, and ongoing work. That evaluation regularly changes the scope and location of the solution: a symptom in the interface might originate in shared state, an API contract, or provider-specific behavior, while a new setting might accommodate one workflow at the expense of others. Resolving the immediate symptom is only part of the work. Public repository activity does not show every investigation or implementation in progress, and unsolicited PRs often duplicate work already underway while introducing another approach to reconcile. Maintainers need room to complete that evaluation before publishing the result.
The explicit-request requirement establishes who decides what implementation work enters the project and when. An unsolicited PR arrives with a scope, design, and set of tradeoffs already embedded in code, before maintainers have agreed that those are the decisions the project should make. Reviewing it turns an open design question into a negotiation over an existing implementation. The author's investment then creates pressure to preserve that approach, even when the right outcome is a different design, a smaller change, or no addition at all. We need to make those decisions from the project's requirements. A maintainer request establishes that we have identified useful outside work and agreed on its purpose and scope before someone invests in it.
This is why the requirement applies even to excellent code. If every unsolicited PR qualified for review on the grounds that it might be useful, we would have to perform that review to decide whether the requirement applied. The submission rule would accomplish nothing. We do not operate a general review queue for independently chosen implementations. We select work according to the project's priorities and request contributions where they serve that work. A clean diff, passing checks, or an offer to make revisions cannot substitute for that decision. This remains our development process even when review capacity is available.
Reviewing an external implementation, explaining the required changes, and coordinating successive revisions usually takes more effort than developing the solution internally. Fragmented commit histories, branches that have not been rebased, unresolved conflicts, unrelated edits, and unverified AI-generated explanations add further work. Maintainers still have to reconstruct the assumptions, assess the wider effects, and understand the final implementation well enough to own it. That work draws on the same attention needed for regressions, security fixes, and releases. The requirement prevents unplanned implementation review from determining how that attention is spent.
Once code ships, the team owns its behavior across future releases. We must preserve compatibility where needed, diagnose failures, maintain documentation and regression coverage, and adapt the change as the surrounding system evolves. Each new dependency, setting, and abstraction adds to that responsibility, and users build workflows around the behavior we accept. Removing an unsuitable change later brings its own compatibility and migration costs. The people accountable for those consequences must decide which commitments the project takes on before implementation begins. Exceptional work is considered at the maintainers' initiative; contributors should not treat their own assessment of a patch as permission to bypass the process.
We also require an explicit request for new or rewritten automated tests, including fixtures, snapshots, and testing infrastructure. A request to implement a fix does not include a request to add a test suite. When code and tests are generated from the same assumptions, they can agree with each other while both being wrong about the intended behavior. Assertions derived from current output can preserve a mistake; mocks can remove the integration where the failure occurs; snapshots can record incorrect results. Tests tied to internal function calls can obstruct a sound refactor without detecting a user-facing regression. Passing such tests creates a false sense of safety, while more assertions and higher coverage say little about whether the right behavior was checked.
Those tests become another implementation to investigate, rewrite, and maintain. We must verify their expected results, assumptions, and ability to detect the original failure before relying on them. Maintainers choose durable regression coverage internally after establishing the intended behavior and request outside test work when it serves that plan. For a requested PR, provide reproducible evidence from the running application: setup, exact steps, expected behavior, and observed results before and after the change. Include relevant logs, screenshots, or recordings, run existing checks relevant to the change, and report failures and anything you could not verify. Do not remove, disable, or weaken existing tests to make a change pass. Neither manual verification nor a passing suite replaces review of the approach and its wider effects.
Public source code and contribution intake are separate project decisions. SQLite describes itself as “Open-Source, not Open-Contribution”: its restrictions preserve the public-domain status of its code, and its documentation explains that proof-of-concept patches can be rewritten from scratch. SQLite has a formal process for accepting contributed code. The parallel is that useful reports and reference implementations can inform a solution while maintainers retain control of what ships. Open WebUI's reasons concern development capacity, architectural consistency, and long-term ownership; SQLite's public-domain requirements are specific to SQLite.
tldraw's January 2026 policy announcement described closing external PRs and selectively reopening work under consideration, citing AI-generated submissions, incomplete context, and limited author follow-up. Its contribution guide directs people to issues and branch references while stating that it is not accepting contributions. Clojure's development policy accepts patches through its own process, but assigns direction to its core team and asks feature proposals to establish the problem and compare alternatives before moving to implementation. These are distinct policies with different governance and licensing arrangements. They illustrate how community input informs a project while maintainers determine its design and contribution process. Open WebUI retains a path for explicitly requested work and localization contributions.
If you genuinely want to help Open WebUI, make the project's needs and the maintainers' ability to act on your contribution the measure of its value. A precise reproduction, a carefully investigated report, or a useful explanation of a workflow can improve the project without producing a merged PR under your name. Be prepared for maintainers to solve the problem differently, implement the solution internally, or decide that a proposed change does not belong in the project. Helping means supporting that outcome even when your code is not used. Submit reproducible bugs through Issues and proposals through Discussions. Search existing reports, check the current release and dev, and provide the affected workflow, expected and actual results, and relevant evidence. Report security concerns through the private security reporting process. Share implementation notes, local diffs, patches, or branch references in the relevant report when they clarify the problem; do not open a PR to obtain attention for reference code. Follow up with useful evidence and respect the team's priorities. Reports do not guarantee a response, implementation, or timeline, and repeated bumps or duplicate submissions take time away from the work.
When we request a PR, the purpose is to complete work the project has agreed it needs. Keep that purpose ahead of personal preferences about the implementation, the size of your contribution, or securing a merge. Follow the pull request template, target dev, complete the Contributor License Agreement, and link the maintainer's request in the Maintainer Request section. Follow existing patterns, document verification, and stay within the agreed scope. Return to the discussion if the approach needs to change, and accept that review can result in a rewrite or a decision not to proceed. An invitation does not authorize unrelated changes or unsolicited tests, and it does not guarantee acceptance. For i18n/localization PRs, state that the work is limited to localization; this standing exception recognizes language knowledge that helps users within the existing translation system. It does not extend to unrelated behavior, refactors, or dependencies bundled with translations. Respecting these boundaries, including a decision to close a submission, is part of contributing. Reopening a declined PR or splitting it into smaller submissions to seek a different outcome works against that purpose.
Improve documentation
Help make Open WebUI more accessible by improving docs, writing tutorials, or creating setup guides. Documentation lives in the docs repository.
Translate the UI
PRs limited to i18n/localization do not require a maintainer request. Open WebUI uses JSON translation files in src/lib/i18n/locales. Each subdirectory is named with an ISO 639 language code (e.g., en-US, fr-FR).
To add a new language:
- Create a new directory under
src/lib/i18n/localesnamed with the appropriate language code - Copy the
en-UStranslation files into the new directory - Translate the string values in each JSON file while preserving the object structure
- Register the language in
src/lib/i18n/locales/languages.json
Improve accessibility
Accessibility is a core part of good design. Report accessibility problems with reproduction details through Issues. When implementing a maintainer-requested UI change:
| Principle | What to do |
|---|---|
| Semantic HTML | Use <button>, <label>, <nav>, and other semantic elements instead of generic <div> wrappers |
| Keyboard navigation | Ensure all interactive elements work without a mouse |
| ARIA labels | Add ARIA roles and labels where semantic HTML alone is insufficient |
| Color contrast | Verify contrast ratios with WebAIM Contrast Checker |
| Alt text | Provide descriptive alt for meaningful images; use alt="" for decorative ones |
Test your changes with Lighthouse or your browser's accessibility tools.
Reporting Issues
Check the Issues tab before opening a new one. When filing:
- Use the issue template. Issues that do not follow the template or lack requested information will be closed.
- Include reproduction steps. Describe what you did, what you expected, and what actually happened.
- Be specific. Vague reports ("it doesn't work") cannot be investigated effectively.
Open WebUI supports Docker deployment, but we assume familiarity with Docker fundamentals. Issues related to reverse proxy configuration, container networking, or host OS setup are outside the project's support scope. Refer to the official Docker documentation for those topics.
Get in Touch
| Channel | Link |
|---|---|
| Discord | discord.gg/5rJgQTnV4s |
| r/OpenWebUI | |
| GitHub Issues | open-webui/open-webui/issues |
| GitHub Discussions | open-webui/open-webui/discussions |