Skill Wiki
Config In Environment
Strict separation of config from code. Config lives in the environment, not the repo.
$ prime install @backend-architecture/principle-config-in-environmentProjection
Always in _index.xml · the agent never has to ask for this.
ConfigInEnvironment [principle] v1.0.0
Configuration that varies between deploys (database URLs, credentials, feature flags, hostnames) is stored in environment variables, never in code. Code is identical across all deploys; only environment differs. The litmus test: could the codebase be open-sourced this minute without leaking a credential?
Strict separation of config from code. Config lives in the environment, not the repo.
Loaded when retrieval picks the atom as adjacent / supporting.
ConfigInEnvironment [principle] v1.0.0
Configuration that varies between deploys (database URLs, credentials, feature flags, hostnames) is stored in environment variables, never in code. Code is identical across all deploys; only environment differs. The litmus test: could the codebase be open-sourced this minute without leaking a credential?
Strict separation of config from code. Config lives in the environment, not the repo.
Applies To
- Database URLs, API keys, OAuth credentials — env vars, not constants.
- config.yaml that is committed to the repo is fine for code-level constants, but anything per-deploy goes in env.
- Feature flags read from env or a remote flag service, not hard-coded branches.
Loaded when retrieval picks the atom as a focal / direct hit.
ConfigInEnvironment [principle] v1.0.0
Configuration that varies between deploys (database URLs, credentials, feature flags, hostnames) is stored in environment variables, never in code. Code is identical across all deploys; only environment differs. The litmus test: could the codebase be open-sourced this minute without leaking a credential?
Strict separation of config from code. Config lives in the environment, not the repo.
Applies To
- Database URLs, API keys, OAuth credentials — env vars, not constants.
- config.yaml that is committed to the repo is fine for code-level constants, but anything per-deploy goes in env.
- Feature flags read from env or a remote flag service, not hard-coded branches.
Source
prime-system/examples/backend-architecture/primes/compiled/@backend-architecture/principle-config-in-environment/atom.yaml