[GH-ISSUE #21861] feat: docker secrets _FILE variables #58262

New Issue

GiteaMirror · 2026-05-05T22:43:36-05:00

GiteaMirror commented

2026-05-05 22:43:36 -05:00

Originally created by @antoninoLorenzo on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21861

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

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:

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:

# 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

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_

GiteaMirror closed this issue

2026-05-05 22:43:38 -05:00

GiteaMirror commented

2026-05-05 22:43:40 -05:00

@kimberlyeet commented on GitHub (Mar 15, 2026):

Hi, I would love to see this implemented too.

@kimberlyeet commented on GitHub (Mar 15, 2026): Hi, I would love to see this implemented too.

GiteaMirror commented

2026-05-05 22:43:41 -05:00

@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

@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

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#58262

[GH-ISSUE #21861] feat: docker secrets _FILE variables #58262

Check Existing Issues

Verify Feature Scope

Problem Description

Desired Solution you'd like

Alternatives Considered

Additional Context

[GH-ISSUE #21861] feat: docker secrets `_FILE` variables #58262