Application configuration
The configuration your application reads comes from two different objects, and the difference between them is not one of degree — it is one of nature.
| Object | What it is | Can the value be read later? |
|---|---|---|
| Variable | Configuration — LOG_LEVEL, FEATURE_X, a service URL | Yes, and it appears on screen |
| Secret | A sensitive value — a password, an API key, a token | No, never, not even for administrators |
Hiding a LOG_LEVEL protects nothing and gets in everyone's way. Showing a password protects less than any written policy. That is why there are two screens.
Three scopes, one chain
The same name can be declared at three levels:
Organization → Project → Environment
most general most specific
The value the application reads is the most specific among those that exist. The screen shows the whole chain: without it, you would change the value in the wrong place and conclude the platform ignored your change.
| Scope | Use when |
|---|---|
| Organization | The value is the same for every project — an internal service's address, a region |
| Project | The value belongs to that application |
| Environment | The value differs between Production and the other environments |
When the change takes effect
Declaring a variable or a secret does not change the application already running. The value takes effect on the next deployment — and the screens say so explicitly when there is a pending change.
To apply it now, deploy the service. No code change is needed: the new version uses the same image with the new configuration.
The effective configuration
The Variables page shows, beyond what was declared at each level, the configuration the workload actually receives. That is the answer to "where does this value come from?".
In this section
Declaring, changing, and removing readable configuration.
Open →SecretsSensitive values: they go in once and do not come out.
Open →Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.