[GH-ISSUE #21094] feat: Better support for integration with an existing web site #34909

New Issue

GiteaMirror · 2026-04-25T09:05:13-05:00

GiteaMirror commented

2026-04-25 09:05:13 -05:00

Originally created by @abcbarryn on GitHub (Feb 1, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21094

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

I have noticed that Open WebUI has hard coded absolute URL paths like /static.

Desired Solution you'd like

Static resources should be loaded from a relative path so that the app can be proxied to a sub URL like /webai without causing links to resources to break.

Alternatives Considered

No response

Additional Context

No response

Originally created by @abcbarryn on GitHub (Feb 1, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21094 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description I have noticed that Open WebUI has hard coded absolute URL paths like /static. ### Desired Solution you'd like Static resources should be loaded from a relative path so that the app can be proxied to a sub URL like /webai without causing links to resources to break. ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-25 09:05:13 -05:00

GiteaMirror commented

2026-04-25 09:05:14 -05:00

@abcbarryn commented on GitHub (Feb 5, 2026):

Not even a comment why this is not planned before closing it?

@abcbarryn commented on GitHub (Feb 5, 2026): Not even a comment why this is not planned before closing it?

GiteaMirror commented

2026-04-25 09:05:14 -05:00

@Classic298 commented on GitHub (Feb 5, 2026):

duplicate request. use the search, i am sure the reason was shared in the past already

@Classic298 commented on GitHub (Feb 5, 2026): duplicate request. use the search, i am sure the reason was shared in the past already

GiteaMirror commented

2026-04-25 09:05:15 -05:00

@abcbarryn commented on GitHub (Feb 6, 2026):

I found the discussion, the comments and lack of response from the developers are disappointing to say the least. :(

bedroesb
on Sep 2, 2025
open-webui has until now not acknowledged that this is an important feature (the request in this discussion) and a real blocker for many of us. Hopefully this will change one day and I can move to OpenWebUI. The fact that it is not even put on a backlog and PRs related to this feature just get closed is baffles to me.

@abcbarryn commented on GitHub (Feb 6, 2026): I found the discussion, the comments and lack of response from the developers are disappointing to say the least. :( [bedroesb](https://github.com/bedroesb) [on Sep 2, 2025](https://github.com/open-webui/open-webui/issues/21094#discussioncomment-14285466) open-webui has until now not acknowledged that this is an important feature (the request in this discussion) and a real blocker for many of us. Hopefully this will change one day and I can move to OpenWebUI. The fact that it is not even put on a backlog and PRs related to this feature just get closed is baffles to me.

GiteaMirror commented

2026-04-25 09:05:15 -05:00

@abcbarryn commented on GitHub (Feb 6, 2026):

MEMORANDUM

TO: Development Team
FROM: Daneel – Operational Intelligence & Feature Justification
DATE: February 5, 2026
SUBJECT: Justification for Configurable Base URL Feature – Open WebUI

Executive Summary:

This memo details the critical need for a configurable Base URL feature within Open WebUI. The current lack of support severely hinders secure deployment options, specifically SSL/TLS implementation via reverse proxy, and represents a significant blocker for potential users. Addressing this limitation is crucial for expanding Open WebUI’s adoption and providing a secure, robust experience.

Problem Statement:

Open WebUI currently lacks the ability to operate under a configurable Base URL (e.g., http://localhost:8080/MY_CUSTOM_BASE). This limitation presents several key issues:

SSL/TLS Implementation Difficulty: Without a configurable Base URL, implementing SSL/TLS requires complex and often unreliable workarounds. The standard method of securing web applications – proxying through a web server with SSL/TLS configured – becomes exceptionally difficult, if not impossible, when the application is hardcoded to serve at the root path.
Security Concerns: The inability to easily implement SSL/TLS poses a significant security risk, particularly for deployments accessible over public networks.
User Adoption Blockage: As evidenced by user feedback (see attached excerpt), this limitation is a primary obstacle preventing potential users from adopting Open WebUI. The lack of acknowledgment and prioritization of this feature is actively driving users to alternative solutions.
Lack of Flexibility: A configurable Base URL enhances deployment flexibility, allowing integration into existing infrastructure and web application ecosystems more seamlessly.

Proposed Solution:

Implement a configurable Base URL feature, ideally through an environment variable (e.g., BASE_URL). This would allow administrators to specify the desired base path for Open WebUI, enabling standard reverse proxy configurations for SSL/TLS termination and simplifying deployment.

Justification & Benefits:

Enhanced Security: Enables easy implementation of SSL/TLS, protecting user data and ensuring secure communication.
Increased User Adoption: Addresses a critical blocker for potential users, driving adoption and expanding the Open WebUI community.
Improved Deployment Flexibility: Simplifies integration with existing infrastructure and web application ecosystems.
Reduced Support Burden: Streamlines deployment and configuration, reducing the number of support requests related to SSL/TLS and deployment issues.
Positive Community Engagement: Demonstrates responsiveness to user feedback and a commitment to improving the Open WebUI experience.

User Feedback:

The attached excerpt from a user forum clearly articulates the frustration and disappointment surrounding this missing feature. The user explicitly states that this limitation is a “blocker” and is actively considering alternative solutions. Ignoring this feedback risks losing potential users and damaging the reputation of Open WebUI.

Conclusion:

Implementing a configurable Base URL feature is not merely a “nice-to-have” – it is a critical requirement for enhancing the security, usability, and adoption of Open WebUI. Addressing this limitation will demonstrate a commitment to user needs and position Open WebUI as a robust and secure solution for its target audience.

I strongly recommend prioritizing this feature in the next development cycle.

@abcbarryn commented on GitHub (Feb 6, 2026): ## MEMORANDUM **TO:** Development Team **FROM:** Daneel – Operational Intelligence & Feature Justification **DATE:** February 5, 2026 **SUBJECT:** Justification for Configurable Base URL Feature – Open WebUI **Executive Summary:** This memo details the critical need for a configurable Base URL feature within Open WebUI. The current lack of support severely hinders secure deployment options, specifically SSL/TLS implementation via reverse proxy, and represents a significant blocker for potential users. Addressing this limitation is crucial for expanding Open WebUI’s adoption and providing a secure, robust experience. **Problem Statement:** Open WebUI currently lacks the ability to operate under a configurable Base URL (e.g., `http://localhost:8080/MY_CUSTOM_BASE`). This limitation presents several key issues: * **SSL/TLS Implementation Difficulty:** Without a configurable Base URL, implementing SSL/TLS requires complex and often unreliable workarounds. The standard method of securing web applications – proxying through a web server with SSL/TLS configured – becomes exceptionally difficult, if not impossible, when the application is hardcoded to serve at the root path. * **Security Concerns:** The inability to easily implement SSL/TLS poses a significant security risk, particularly for deployments accessible over public networks. * **User Adoption Blockage:** As evidenced by user feedback (see attached excerpt), this limitation is a *primary* obstacle preventing potential users from adopting Open WebUI. The lack of acknowledgment and prioritization of this feature is actively driving users to alternative solutions. * **Lack of Flexibility:** A configurable Base URL enhances deployment flexibility, allowing integration into existing infrastructure and web application ecosystems more seamlessly. **Proposed Solution:** Implement a configurable Base URL feature, ideally through an environment variable (e.g., `BASE_URL`). This would allow administrators to specify the desired base path for Open WebUI, enabling standard reverse proxy configurations for SSL/TLS termination and simplifying deployment. **Justification & Benefits:** * **Enhanced Security:** Enables easy implementation of SSL/TLS, protecting user data and ensuring secure communication. * **Increased User Adoption:** Addresses a critical blocker for potential users, driving adoption and expanding the Open WebUI community. * **Improved Deployment Flexibility:** Simplifies integration with existing infrastructure and web application ecosystems. * **Reduced Support Burden:** Streamlines deployment and configuration, reducing the number of support requests related to SSL/TLS and deployment issues. * **Positive Community Engagement:** Demonstrates responsiveness to user feedback and a commitment to improving the Open WebUI experience. **User Feedback:** The attached excerpt from a user forum clearly articulates the frustration and disappointment surrounding this missing feature. The user explicitly states that this limitation is a “blocker” and is actively considering alternative solutions. Ignoring this feedback risks losing potential users and damaging the reputation of Open WebUI. **Conclusion:** Implementing a configurable Base URL feature is not merely a “nice-to-have” – it is a *critical* requirement for enhancing the security, usability, and adoption of Open WebUI. Addressing this limitation will demonstrate a commitment to user needs and position Open WebUI as a robust and secure solution for its target audience. I strongly recommend prioritizing this feature in the next development cycle.

GiteaMirror commented

2026-04-25 09:05:16 -05:00

@Classic298 commented on GitHub (Feb 6, 2026):

This has absolutely nothing to do with security or usability or adoption. This is simply a different deployment style.

"it is a critical requirement for enhancing the security"

Claiming this is a "critical requirement" to improving security is absolutely crazy to me because it is false.

"Enhanced Security: Enables easy implementation of SSL/TLS, protecting user data and ensuring secure communication."

How does this make it easier to deploy TLS? You will still have to put it behind a reverse proxy - same as right now.
It changes NOTHING in that regard.

"SSL/TLS Implementation Difficulty: Without a configurable Base URL, implementing SSL/TLS requires complex and often unreliable workarounds."

There is not one piece of truth in this sentence. Fabricated lie. You use NGINX and the rest is history. We have vast guides for that on the docs.

"Security Concerns: The inability to easily implement SSL/TLS poses a significant security risk, particularly for deployments accessible over public networks."

Putting it on a custom /path doesnt make this easier. You will have to configure it via NGINX regardless. No matter what path it is on.

"Lack of Flexibility: A configurable Base URL enhances deployment flexibility, allowing integration into existing infrastructure and web application ecosystems more seamlessly."

This is the only valid reason

"enabling standard reverse proxy configurations for SSL/TLS termination and simplifying deployment."

You can already do that, once again to remind you: there are many reverse proxy guides on the docs - and adding an additional /path to access Open WebUI does not simplify deployment, if anything - makes it more difficult since you will have to reference that path everywhere, especially if you have a very long NGINX config file (typical for very large production environments).

"The current lack of support severely hinders secure deployment options specifically SSL/TLS implementation via reverse proxy"

How?

I AM NOT SAYING a configurable base url wouldn't be nice-to-have, but you are not helping the cause of prioritizing this feature, by commenting this under all the related issues and discussions.

Flooding discussions and issues with AI generated nonsense claiming it to be "absolutely critical to security", is just as hurtful to the discussion as the AI generated slop reports that come in regularily via the responsible disclosure system here on GitHub.

@Classic298 commented on GitHub (Feb 6, 2026): This has absolutely nothing to do with security or usability or adoption. This is simply a different deployment style. > "it is a critical requirement for enhancing the security" Claiming this is a "critical requirement" to improving security is absolutely crazy to me because it is false. > "Enhanced Security: Enables easy implementation of SSL/TLS, protecting user data and ensuring secure communication." How does this make it easier to deploy TLS? You will still have to put it behind a reverse proxy - same as right now. It changes NOTHING in that regard. > "SSL/TLS Implementation Difficulty: Without a configurable Base URL, implementing SSL/TLS requires complex and often unreliable workarounds." There is not one piece of truth in this sentence. Fabricated lie. You use NGINX and the rest is history. We have vast guides for that on the docs. > "Security Concerns: The inability to easily implement SSL/TLS poses a significant security risk, particularly for deployments accessible over public networks." Putting it on a custom /path doesnt make this easier. You will have to configure it via NGINX regardless. No matter what path it is on. > "Lack of Flexibility: A configurable Base URL enhances deployment flexibility, allowing integration into existing infrastructure and web application ecosystems more seamlessly." This is the only valid reason > "enabling standard reverse proxy configurations for SSL/TLS termination and simplifying deployment." You can already do that, once again to remind you: there are many reverse proxy guides on the docs - and adding an additional /path to access Open WebUI does not simplify deployment, if anything - makes it more difficult since you will have to reference that path everywhere, especially if you have a very long NGINX config file (typical for very large production environments). > "The current lack of support severely hinders secure deployment options specifically SSL/TLS implementation via reverse proxy" How? <ins>**I AM NOT SAYING a configurable base url wouldn't be nice-to-have**</ins>, but you are not helping the cause of prioritizing this feature, by commenting this under all the related issues and discussions. Flooding discussions and issues with AI generated nonsense claiming it to be "absolutely critical to security", is just as hurtful to the discussion as the AI generated slop reports that come in regularily via the responsible disclosure system here on GitHub.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#34909