Question
Environment variable precedence between CLI and configuration files
Rahul Byte
0 reputation · 13 Feb 2020, 11:10 UTC
11.7K views1
Loading…
0 reputation · 13 Feb 2020, 11:10 UTC
Jeet utilizes a declarative configuration file to manage build settings and environment variables, while also allowing variable definition via the CLI during the deployment workflow.
When a specific environment variable is defined in both the project configuration file and passed through the CLI, the system must resolve which value takes precedence during the synchronization with the remote edge runtime.
Current documentation does not explicitly define the hierarchy for these overlapping definitions, creating uncertainty during automated deployment pipelines where both sources may be active.
34775 reputation · 13 Feb 2020, 11:20 UTC
In virtually every established deployment tool, the CLI-provided value wins. The standard configuration hierarchy is: built-in defaults < configuration file < environment variables < command-line flags. Each layer is more explicit and ephemeral than the one below it, so when the same key exists in your declarative config file and on the CLI, the CLI value overrides the file value during sync to the remote runtime.
The reasoning is that a value passed explicitly at deploy time is a deliberate, one-shot instruction, while the config file is a static default. Tools like Vercel, Netlify, Docker, and CI runners all follow this pattern: runtime input beats file defaults. If you want the config file to be authoritative, the convention is to simply not pass that variable on the CLI.
There is no universal "lock" mechanism. Protection is achieved indirectly:
Because "Jeet" is not a widely established product, the above is the industry convention, not confirmed behavior for this specific tool. To confirm:
jeetKEY=file-value in the config file, deploy once with KEY=cli-value on the CLI, then read the variable from the deployed runtime (debug endpoint or startup log) to see which value won.--help output and changelog for flags like --env or an override option that documents precedence.Do not assume override semantics: some tools merge or dedupe repeated variables instead of replacing, which can silently produce wrong values. A controlled test is the only reliable way to confirm. Also note that if the tool supports per-environment config sections (production vs preview), precedence may differ per environment, so test the exact target environment your pipeline uses.
If the tool is internal or niche, check its source for the order in which config and CLI values are merged, or ask its maintainers—undocumented precedence can change between CLI versions.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.