Environment Variables & Files

## Why anything arrives from outside at all A container image is fixed once it is built: the same bytes, identified by the same content digest, run in every environment. So every value that must differ between one deployment and the next — a log level, a batch size, an endpoint, a large allowlist — has to arrive from outside the image, at the moment the workload starts. A container platform offers two shapes for that last hop. Almost every platform offers both, because they are not substitutes for one another. ## Shape one: a flat set of name-value pairs Every process on a general-purpose operating system is created with an **environment**: a block of `NAME=value` pairs handed to it by whatever created it. A container runtime assembles that block from the values baked into the image, the values declared in the workload spec, and anything the platform injects, and hands the merged block to the first process in the container. Four properties follow directly from that mechanism, and between them they are the whole case for and against this shape: - **It is flat and stringly-typed.** A value is one string. There is no nesting, no list type, no comment, and nothing validates it. - **It is inherited.** Every child process the workload starts — a helper, a migration step, anything it shells out to — receives a copy without asking for one. - **It is a snapshot.** The block is copied into the process at creation. Nothing outside the process can edit that copy afterwards. - **It is visible.** A platform's inspection view of a running workload normally shows the set it was handed, values included, to anyone allowed to look at the workload. ## Shape two: a directory of files mounted into the container In the second shape the platform materialises a declared value set as **files at a path inside the container's filesystem**, and the process opens that path and reads it like any other file. The mechanism is completely different, and so are its properties: - A file can hold **any document format the process can parse** — nested, ordered, commented, and checkable against a schema at start-up. - A file has an **owner and a mode**, so which identity inside the container may open it is a decision you get to make. - A file is **not handed to children**. A helper process must be told the path and must open it itself. - The file's **bytes live outside the process**, so the platform can replace them while the process is running. ## What the choice actually decides | | inherited name-value set | mounted file tree | |---|---|---| | shape of a value | one flat string | any document the process can parse | | size | small; the whole block has a ceiling | large documents are routine | | who gets it automatically | every child process | nothing; a reader must open a path | | in an inspection listing | the names and the values | the source, not the contents | | access control inside the container | none | an owner and a mode per file | | after the delivered value changes | the running process keeps its copy | the bytes can be replaced under it | | cost to read | already in memory | an open, a parse, and an error path | ## Choosing, for a workload with a dozen scalars and one document Take a device-telemetry ingester with a dozen tuning settings — batch size, flush interval, log level, retry ceiling — plus one large allowlist of device identifiers. The allocation almost writes itself: 1. **Scalars a person could type on one line go in the inherited set.** They are strings anyway, they are small, and having them in memory at start costs nothing. 2. **Anything with structure, comments, or more than a screenful of text becomes a file.** Encoding a nested document into a single string throws away everything that made it a document. 3. **Anything you do not want handed to every child process and shown in every inspection view becomes a file**, where a mode and an owner apply. 4. **The file's path goes back into the inherited set** as one more variable. That is the idiom: the set carries the pointer, the file carries the payload. ## Where this stops The two shapes are about *delivery* — how the bytes reach the process. What a process does after a delivered value changes, the extra rules that apply to credentials specifically, and the machinery underneath a mount are each their own subject. So is the older argument about whether configuration should live outside the artifact at all; here it already does, and the only question is which shape carries it.