Is your feature request related to a problem? Please describe
Answer's installation flow generates /data/conf/config.yaml, and the Helm chart notes that persistence is required so config.yaml survives restarts. AUTO_INSTALL accepts environment variables for initial setup, but those variables are not used as the runtime configuration afterward.
This makes configuration-stateless container deployments difficult. A pod with a disposable filesystem cannot restart or scale from an already initialized external database using environment variables and secrets alone. Operators must persist or mount the generated config.yaml, or rerun the one-time installer, which is not appropriate once the database has already been initialized.
Describe the solution you'd like
Please allow the install flow to export the effective post-install configuration as a complete, documented set of environment variables, and allow normal Answer startup to consume those variables without requiring config.yaml.
Expected behavior could include:
- An explicit install option or endpoint that exports the effective runtime configuration in a machine-readable environment-variable format, such as dotenv or shell output.
- An environment-variable equivalent for every
config.yaml value required at runtime, with documented precedence when both sources are present.
- A fresh Answer instance can connect to an already initialized external database and start using only the exported environment variables, without a local
config.yaml.
- Secrets are never printed to ordinary logs; exporting secret-bearing values requires an explicit action and can be directed to a secret manager.
- Existing
config.yaml-based deployments remain backward compatible.
This would make Answer easier to run with immutable images, disposable pods, Kubernetes Secrets, and externally managed databases.
Describe alternatives you've considered
- Persist
/data/conf on a volume.
- Generate and mount
config.yaml from a ConfigMap or Secret.
- Use an init container or entrypoint template to recreate
config.yaml on every start.
- Keep using
AUTO_INSTALL, although it is a one-time initialization path and fails or becomes inappropriate after the database has already been initialized.
Is your feature request related to a problem? Please describe
Answer's installation flow generates
/data/conf/config.yaml, and the Helm chart notes that persistence is required soconfig.yamlsurvives restarts.AUTO_INSTALLaccepts environment variables for initial setup, but those variables are not used as the runtime configuration afterward.This makes configuration-stateless container deployments difficult. A pod with a disposable filesystem cannot restart or scale from an already initialized external database using environment variables and secrets alone. Operators must persist or mount the generated
config.yaml, or rerun the one-time installer, which is not appropriate once the database has already been initialized.Describe the solution you'd like
Please allow the install flow to export the effective post-install configuration as a complete, documented set of environment variables, and allow normal Answer startup to consume those variables without requiring
config.yaml.Expected behavior could include:
config.yamlvalue required at runtime, with documented precedence when both sources are present.config.yaml.config.yaml-based deployments remain backward compatible.This would make Answer easier to run with immutable images, disposable pods, Kubernetes Secrets, and externally managed databases.
Describe alternatives you've considered
/data/confon a volume.config.yamlfrom a ConfigMap or Secret.config.yamlon every start.AUTO_INSTALL, although it is a one-time initialization path and fails or becomes inappropriate after the database has already been initialized.