config file secrets configuration #50

New issue

Open

opened 2026-10-18 21:10:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:10:54 +00:00

Owner

Originally created by @zacharyweiss on GitHub (May 1, 2025).
Original GitHub issue: https://github.com/open-webui/mcpo/issues/111

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

The current configuration approach, passing the API key as a CLI argument, makes it tricky to avoid leaking one's secret — through shell history, or through any declarative deployment approach.

Desired Solution you'd like

Allowing the API key to be set by an environment variable or a configuration file would fix this, and make MCPO more flexibly / easily deployed.

The environment, and optional environment file(s) are already loaded in:
github.com/open-webui/mcpo@e37d0ebd27/src/mcpo/init.py#L88-L104

One would simply need to add some quick logic to check the environment for the appropriate var(s) and set them before running:
github.com/open-webui/mcpo@e37d0ebd27/src/mcpo/init.py#L117-L135

Alternatives Considered

A dedicated argument could be added for providing a path to a password file just for the API key, or for setting all the other CLI args declaratively. To me, this seems to add unnecessary complexity when you already load the environment, and setting such secrets via the environment is a commonplace practice.

Additional Context

While the fix itself simple, it begs a few design and generalization questions first (else I would simply PR rather than opening an issue).

What should the precedence be? If defined both in the environment and as an argument, which is preferred?
Should this be extended to allow setting any of the CLI args via environment variables? This would help with scenarios like https://github.com/open-webui/mcpo/issues/66#issuecomment-2797191169 where one needs to pass additional secrets in, and keep things uniform.
Naming scheme: if folks are running MCPO unsandboxed, an environment variable like "API_KEY" that directly shadows the CLI argument is rather generically named (as would be the other arguments, if extending to all args), and could easily collide with preexisting vars. Prefix the shadowed name(s) with "MCPO_"?

Originally created by @zacharyweiss on GitHub (May 1, 2025). Original GitHub issue: https://github.com/open-webui/mcpo/issues/111 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description The current configuration approach, passing the API key as a CLI argument, makes it tricky to avoid leaking one's secret — through shell history, or through any declarative deployment approach. ### Desired Solution you'd like Allowing the API key to be set by an environment variable or a configuration file would fix this, and make MCPO more flexibly / easily deployed. The environment, and optional environment file(s) are already loaded in: https://github.com/open-webui/mcpo/blob/e37d0ebd27934378364f534bd8ee6ae82a370536/src/mcpo/__init__.py#L88-L104 One would simply need to add some quick logic to check the environment for the appropriate var(s) and set them before running: https://github.com/open-webui/mcpo/blob/e37d0ebd27934378364f534bd8ee6ae82a370536/src/mcpo/__init__.py#L117-L135 ### Alternatives Considered A dedicated argument could be added for providing a path to a password file just for the API key, or for setting all the other CLI args declaratively. To me, this seems to add unnecessary complexity when you already load the environment, and setting such secrets via the environment is a commonplace practice. ### Additional Context While the fix itself simple, it begs a few design and generalization questions first (else I would simply PR rather than opening an issue). 1. What should the precedence be? If defined both in the environment and as an argument, which is preferred? 2. Should this be extended to allow setting any of the CLI args via environment variables? This would help with scenarios like https://github.com/open-webui/mcpo/issues/66#issuecomment-2797191169 where one needs to pass additional secrets in, and keep things uniform. 3. Naming scheme: if folks are running MCPO unsandboxed, an environment variable like "API_KEY" that directly shadows the CLI argument is rather generically named (as would be the other arguments, if extending to all args), and could easily collide with preexisting vars. Prefix the shadowed name(s) with "MCPO_"?