mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-15 21:19:39 -05:00
[GH-ISSUE #21093] feat: Native SSL/TLS support. #139106
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#139106
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @abcbarryn on GitHub (Feb 1, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21093
Check Existing Issues
Verify Feature Scope
Problem Description
It would be nice if there was a way to enable SSL/TLS for Open WebUI without using external solutions like stunnel, etc. Or am I missing something?
Desired Solution you'd like
I would like an option for Open WebUI to support https.
Alternatives Considered
I am currently running stunnel to supply https.
Additional Context
No response
@TomTheWise commented on GitHub (Feb 2, 2026):
It is VERY standard for Web Applications to always put them behind reverseproxies like apache2 or nginx which then handle the TLS termination and proxy their requests to the actual application.
For example tomcat / jetty based enterprise Java web apps are typically put behind reverse proxies - simply for example to strengthen the security and other reasons.
Also this allows for some of the SSO features. With Apache2 you can for example do Kerberos based SSO or other authentication types and then pass on and use the email header provided from the Apache2 in OpenWebUI for authentication.
So, as to me this is very standard practice for enterprise web applications, I doubt that native TLS would be a worthy addition.
@Classic298 commented on GitHub (Feb 2, 2026):
I dont think this will be implemented and I didn't close this issue yet because this, i don't want to decide, here tim should have the last word.
But if anyone is landing here from search or else: there are many and very good tutorials in the docs for how to set up various reverse proxies. It's simple, gives you full control over how the data is served, even improves loading speed through caching - and also implements TLS support if you need it.
And yeah, in enterprise scenario it is absolutely standard to put a reverse proxy in front of the application - for security reasons, but also for load balancing, caching and more.
Security definitely being a major point here
@TaylorTWBrown commented on GitHub (May 20, 2026):
TLS is still highly common and practical for communication between the reverse proxy and application.
@Classic298 commented on GitHub (May 21, 2026):
Actually "highly common" is a very far stretch. The standard reverse-proxy setup is TLS termination at the proxy and plaintext HTTP between the proxy and the application, almost always over a private docker network, loopback, or internal subnet where the traffic doesn't leave the trust boundary. This is how nginx, Caddy, Traefik, HAProxy, and Apache tutorials universally demonstrate the pattern, and it's how the vast majority of production deployments are configured.
Proxy↔app TLS is reserved for specific scenarios — zero-trust network architectures, regulated environments with end-to-end encryption-in-transit requirements, or geographically-distributed deployments where proxy and app are in totally different data centers. None of these describe the use case the original feature request was about, and adding native TLS to Open WebUI to address them would impose cert management, renewal, and operational complexity on every deployment for the benefit of a narrow subset.
For the rare deployments that genuinely need proxy↔app encryption, the standard solutions (stunnel, an envoy/linkerd sidecar, mTLS via a service mesh) handle it cleanly without requiring the application itself to terminate TLS. That's also the pattern recommended by basically every web framework itself, not just Open WebUI.