How does a Pulumi program read its per-stack configuration values in code, and what is the difference between the require and get families of methods on pulumi.Config?

## Config is the program's parameters A Pulumi program is code, but it should not be edited to move between environments. Configuration is the parameterisation layer: the same program, different values, one set per stack. This entry is about the *program* side — how code reads those values. ```typescript import * as pulumi from "@pulumi/pulumi"; const config = new pulumi.Config(); const dbName = config.require("dbName"); const nodeCount = config.getNumber("nodeCount") ?? 3; ``` Python is the same shape: `config = pulumi.Config()`, `config.require("db_name")`, `config.get_int("node_count")`. Go uses `config.New(ctx, "")` with `cfg.Require` and `cfg.GetInt`. ## require vs get The distinction is about what happens when the key is absent. - **`require(key)`** throws a `ConfigMissingError` naming the key and the stack. The deployment stops before anything is created. Use it for every value that has no defensible default — the database name, the domain, the account you are targeting. - **`get(key)`** returns `undefined` (`None` in Python). Use it when the program has a real default and you want that default expressed in code, where it is reviewable, rather than duplicated into every stack's config. Failing loudly on a missing required value is worth more than it sounds: the alternative is a program that silently deploys with an empty string in a name, and you find out from the cloud's error message ten resources later. ## The typed variants Config values are stored as strings. Every method therefore has typed siblings that parse: - `requireNumber` / `getNumber` - `requireBoolean` / `getBoolean` - `requireObject<T>` / `getObject<T>` — for structured values, parsed from JSON or from structured config - `requireSecret` / `getSecret` — returns the value as a secret `Output<string>` rather than a plain string, so it stays marked secret through everything you derive from it Use the typed form rather than `parseInt(config.require("nodeCount"))`. The typed form gives you a clear error naming the key when the value is not a number; hand-rolled coercion gives you `NaN` and a confusing failure three resources downstream. Note that the secret variants are the one family that returns an `Output`, not a plain value — because the secret marker has to travel with the value, and Output is what carries that marker. ## Namespaces A bare `new pulumi.Config()` is namespaced to the current project's name, so it reads `myproject:dbName`. Constructing it with an explicit namespace reads someone else's: ```typescript const region = new pulumi.Config("aws").require("region"); ``` The `aws:` namespace is how the AWS provider's own settings are exposed, and the same pattern applies to other providers. The namespace also means two projects sharing a stack config file cannot collide on a key like `region`. ## Why plain values matter here Config values are known before any resource is registered. That makes them the correct thing to drive program structure with: ```typescript const env = config.require("environment"); if (env === "prod") { // extra replica, stricter retention, whatever prod needs } ``` This is legal and idiomatic precisely because `env` is a string, not an Output. The same `if` over a deployed resource's attribute would be a bug — the condition would be evaluating an Output object rather than its value. "Branch on config, never on Output" is one of the load-bearing rules of writing Pulumi programs, and it works because config lands on the plain-value side of the line. ## Validation There is no declarative constraint syntax on config the way there is on typed variable blocks in some other tools. You validate in code — which, since it is a real language, means a check and a thrown error, or a schema library if you want more: ```typescript const size = config.requireNumber("nodeCount"); if (size < 1 || size > 20) { throw new Error(`nodeCount must be between 1 and 20, got ${size}`); } ``` Throwing at the top of the program stops the deployment before a single resource is registered, which is exactly the behaviour you want from validation.