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
Currently the configuration is handled through environment variables, it would be desirable to support docker secrets for Open WebUI in order to reduce the attack surface. For example any user with enough privileges to run docker inspect --format='{{.Config.Env}}' open-webui could read sensitive variables such as OPENAI_API_KEY and so on.
This feature was already requested for some specific variables, for example WEBUI_SECRET_KEY (#14754) and OAUTH_CLIENT_SECRET (#18515) but it was never addressed; I think the reason for that is the amount of environment variables would make hard to keep track of what variables should be updated.
Desired Solution you'd like
My proposal is to wrap the os.environ.get(...) function that is used inside backend/open_webui/env.py inside a more convenient one that checks whether there is a _FILE variable available that points to a path (ex. /run/secrets/whatever); this simple change would allow more secure deployments of owui and also comes with enhanced flexibility in the overall management of environment variables, it would look something like this:
defload_var(name:str,default:Optional[str]=None)->str:var=os.environ.get(name,default)# file secret takes precedence if both `SECRET` and `SECRET_FILE` are specifiediff'{name}_FILE'inos.environ:path=os.environ.get(f'{name}_FILE')withopen(path,'r')asfp:var=fp.read()returnvarmyvar=load_var('SECRET')print(myvar)
Applied to the codebase:
# basicWEBUI_SECRET_KEY=load_var('WEBUI_SECRET_KEY')# with defaultsDATABASE_URL=load_var("DATABASE_URL",default=f"sqlite:///{DATA_DIR}/webui.db")
Alternatives Considered
No response
Additional Context
No response
Originally created by @antoninoLorenzo on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21861
### 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
Currently the configuration is handled through environment variables, it would be desirable to support docker secrets for Open WebUI in order to reduce the attack surface. For example any user with enough privileges to run `docker inspect --format='{{.Config.Env}}' open-webui` could read sensitive variables such as `OPENAI_API_KEY` and so on.
This feature was already requested for some specific variables, for example `WEBUI_SECRET_KEY` (#14754) and `OAUTH_CLIENT_SECRET` (#18515) but it was never addressed; I think the reason for that is the amount of environment variables would make hard to keep track of what variables should be updated.
### Desired Solution you'd like
My proposal is to wrap the `os.environ.get(...)` function that is used inside [backend/open_webui/env.py](https://github.com/open-webui/open-webui/blob/main/backend/open_webui/env.py) inside a more convenient one that checks whether there is a `_FILE` variable available that points to a path (ex. `/run/secrets/whatever`); this simple change would allow more secure deployments of owui and also comes with enhanced flexibility in the overall management of environment variables, it would look something like this:
```python
def load_var(name: str, default: Optional[str] = None) -> str:
var = os.environ.get(name, default)
# file secret takes precedence if both `SECRET` and `SECRET_FILE` are specified
if f'{name}_FILE' in os.environ:
path = os.environ.get(f'{name}_FILE')
with open(path, 'r') as fp:
var = fp.read()
return var
myvar = load_var('SECRET')
print(myvar)
```
Applied to the codebase:
```python
# basic
WEBUI_SECRET_KEY = load_var('WEBUI_SECRET_KEY')
# with defaults
DATABASE_URL = load_var("DATABASE_URL", default=f"sqlite:///{DATA_DIR}/webui.db")
```
### Alternatives Considered
_No response_
### Additional Context
_No response_
It looks like #18657 attempted to address this but was closed as well.
Since there’s still interest in this feature, could you elaborate on the decision not to implement it? @tjbck
<!-- gh-comment-id:4063755088 -->
@kimberlyeet commented on GitHub (Mar 15, 2026):
It looks like #18657 attempted to address this but was closed as well.
Since there’s still interest in this feature, could you elaborate on the decision not to implement it? @tjbck
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @antoninoLorenzo on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21861
Check Existing Issues
Verify Feature Scope
Problem Description
Currently the configuration is handled through environment variables, it would be desirable to support docker secrets for Open WebUI in order to reduce the attack surface. For example any user with enough privileges to run
docker inspect --format='{{.Config.Env}}' open-webuicould read sensitive variables such asOPENAI_API_KEYand so on.This feature was already requested for some specific variables, for example
WEBUI_SECRET_KEY(#14754) andOAUTH_CLIENT_SECRET(#18515) but it was never addressed; I think the reason for that is the amount of environment variables would make hard to keep track of what variables should be updated.Desired Solution you'd like
My proposal is to wrap the
os.environ.get(...)function that is used inside backend/open_webui/env.py inside a more convenient one that checks whether there is a_FILEvariable available that points to a path (ex./run/secrets/whatever); this simple change would allow more secure deployments of owui and also comes with enhanced flexibility in the overall management of environment variables, it would look something like this:Applied to the codebase:
Alternatives Considered
No response
Additional Context
No response
@kimberlyeet commented on GitHub (Mar 15, 2026):
Hi, I would love to see this implemented too.
@kimberlyeet commented on GitHub (Mar 15, 2026):
It looks like #18657 attempted to address this but was closed as well.
Since there’s still interest in this feature, could you elaborate on the decision not to implement it? @tjbck