Skip to content

Support secure credential management (e.g., environment variables) instead of static config.yaml #9

Description

@glenn-sq

Is your feature request related to a problem? Please describe.
Right now, the project requires credentials to be stored in a config.yaml file. This approach creates multiple problems:

  • Static credentials are left on disk, increasing the risk of exposure.
  • Secure storage and rotation become difficult, especially for CI/CD pipelines, headless automation, or containerized environments.
  • Accidental commits of the file could expose secrets. Adding it to .gitignore doesn’t always solve the problem, since some AI agents rely on .gitignore rules and may be unable to access the file, leading to authentication issues.

Describe the solution you'd like
I would like the project to support more secure and flexible methods of credential management, such as:

  • Allowing authentication credentials to be set via environment variables (common amongst MCP servers and low effort to implement)
  • Supporting runtime injection of credentials via CLI arguments or other dynamic means.
  • Supporting integration with common secret managers (e.g., AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault).

This would allow credentials to be managed securely outside of source code, rotated more easily, and injected at runtime in CI/CD pipelines.

Describe alternatives you've considered

  • Continuing to use the config.yaml : Not ideal, limits automation and doesn’t address the security risks.
  • Encrypting the config.yaml file: Adds operational overhead, and still results in decrypted credentials sitting on disk.

Additional context
Supporting environment variables and secret manager integrations is a common best practice across many open-source projects. It would make the MCP server easier to use in modern automated environments while reducing the risk of credential exposure.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions