Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Rotated a credential. projects/demo-shop/.env.staging has the new one:
DEMO_SHOP_PASSWORD=<new>Runs still authenticate with the old value. --explain --show-secrets confirms the old one is in there. Deleting the line from the file changes nothing, which is how I worked out the file is not the source at all.
Is the dotenv layer cached somewhere?
Accepted answer
Not cached — outranked. You have DEMO_SHOP_PASSWORD exported in that shell.
env | grep DEMO_SHOP
unset DEMO_SHOP_PASSWORDThe .env files are parsed into a private map and deliberately never injected into process.env. If they were injected, the file would silently become indistinguishable from the process layer and would then outrank it — a value you exported on purpose, for one command, would lose to a file you forgot about. So the map is built first and process.env is merged over the top of it: shell beats file, always.
That is the whole of the difference between layer 4 and layer 5.
The other half of this that bit us in CI: the agent image had the variable baked in, so nobody could reproduce it locally after an unset. sdods config show -p demo-shop -e staging prints the dotenv files it actually read on the second line, which is a fast way to see whether a file is even being picked up before you go hunting in the environment.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.