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.
I have inherited a repo with .env, .env.local, .env.staging and .env.staging.local at the root and two more inside the project folder. Nobody remembers why.
Before I delete any of them: what is the full list of names that are read, and is there a way to see which ones a given run actually picked up?
Four names, two roots, eight possible files. For -e staging from a repo root with a project at projects/demo-shop:
<root>/.env
<root>/.env.staging
<root>/.env.local
<root>/.env.staging.local
<root>/projects/demo-shop/.env
<root>/projects/demo-shop/.env.staging
<root>/projects/demo-shop/.env.local
<root>/projects/demo-shop/.env.staging.localRead in that order, each merged over the last, missing ones skipped. So the bottom of the list wins, and the whole stack still loses to an exported variable.
To see which ones a run actually read:
sdods config show -p demo-shop -e stagingThe second line is the list of dotenv files, or (none).
Before deleting, diff them — the usual reason for six files is that two people solved the same problem in different places and both work, so neither noticed.
Convention that has held up for us: .env.<env> is committed to nothing but documented in .env.example and shared with the team; .env.local is personal and never mentioned to anyone. If a file does not fit one of those two descriptions it can go.
Late addition for anyone finding this: the same eight paths are checked whether or not the project folder differs from the repo root. In a single-project repo where the two are the same directory, only the four names are read once — you do not get duplicates.
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.