Step 8 — Environment variables, and where they come from¶
About 20 minutes. Branch: step-8.
The one new idea: several things can set a variable, they do not rank
equally, and mecca var set wins.
This step breaks something on purpose, near the end
Deliberately, recoverably, and with one command to undo it.
Two moments, one page¶
Tally's footer carries a build marker, fixed when the bundle was compiled. Its tagline now comes from the server:
Deploy, then change the line, and deploy again. The tagline changes — without recompiling the frontend, because it is read at request time from an API the platform handed a variable to.
That distinction runs through everything:
| Decided at | Changing it needs | Example |
|---|---|---|
| Build time | a rebuild | the footer marker; anything import.meta.env in Vite |
| Deploy time | a redeploy | TALLY_TAGLINE, DATABASE_URL |
| Request time | nothing | whatever your code reads per call |
Get something into the wrong column and you will be rebuilding to change a string, or wondering why a rebuilt value did not move.
Where a variable can come from¶
Highest wins:
- What the platform provisions —
DATABASE_URL,REDIS_URL, bucket credentials. Yours to read, never to set. mecca var set— an operational override, stored on the platform.environment:inappmecca.yaml— checked in and reviewed.- What is baked into your image — an
ENVin the Dockerfile. - Your code's own default.
The one that surprises people¶
mecca var set tally TALLY_TAGLINE="Set from the CLI" -b tutorial
mecca app redeploy tally -b tutorial
The tagline changes. Now edit appmecca.yaml, change the line, commit, push,
deploy — and it does not change.
That is not a bug. mecca var set outranks the file and keeps outranking it
on every subsequent deploy. The file has not stopped being read; it has stopped
being the winner.
mecca var list tally -b tutorial # what is actually set, and from where
mecca var unset tally TALLY_TAGLINE -b tutorial
unset is what hands control back to the repository.
mecca var set without -b writes to every branch
That is the default. Harmless today, with one branch. At step 12 you will have two, and a variable meant for a test branch will land on the live one as well.
Get in the habit of -b now.
Break it on purpose¶
mecca var set tally DATABASE_URL="postgresql://nope:nope@nowhere:5432/nope" -b tutorial
mecca app redeploy tally -b tutorial
The deploy fails. entrypoint.sh waits for a database that is not there, gives
up, and the container never becomes healthy — so the previous version keeps
serving.
You will see the wait loop counting down and saying exactly what it could not reach. Then:
Note what you just did: overrode a variable the platform provisions, and put it back. That is the shape of most bad afternoons, and you have now had it on purpose while nothing was at stake.
If it didn't work¶
| Symptom | Try | Usually |
|---|---|---|
| The YAML change does nothing | mecca var list tally -b tutorial |
An override is winning. mecca var unset |
| A variable is missing | mecca debug tally -b tutorial |
Typo in the key — step 4 |
| A variable arrived on the wrong branch | mecca var list -b <other> |
var set without -b |