Variables

Variables configure your services at runtime. Every variable is a name and a value, encrypted at rest, injected into your service's environment when it deploys. A variable can be:

• a literal value you set — an API key, a feature flag, a URL;
• a reference that draws its value from somewhere else — a database you attached, or another variable; or
• a shared value defined once for a whole project or environment and used by many services.

Where variables live

A variable is scoped to a service, an environment, or a project, and a service sees all three — its own, its environment's, and its project's. When the same name is defined at more than one scope, the nearest one wins (service over environment over project), so you can set a project-wide default and override it in a single environment or service.

Manage a service's own variables from its Variables tab; manage shared ones from the project's Variables page. Changing a variable needs the editor role or higher — see Teams & roles.

Sensitive variables

Mark a variable sensitive when its value should not be shown casually — a credential, a signing key.

• Ordinary variables show their value in the console behind a show/hide toggle; anyone who can view the service can read them.
• Sensitive variables are withheld from every read. To see one you reveal it explicitly, and every reveal is recorded in the audit log — the value is not hidden from your teammates, but looking at it always leaves a trace.

Every value — sensitive or not — is encrypted at rest: Koo stores ciphertext, never plaintext, in its database.

A sensitive value never leaves the environment it was set in. Clone an environment and the sensitive names come across, but their values don't — you re-enter each one on the copy before its services can run.

Reference variables

A reference variable draws its value from somewhere else. You name it once and Koo resolves the live value each time the service deploys, so you never copy a credential or a connection string between services. There are two kinds.

From a database

Attach a Postgres or Redis and reference it instead of pasting a connection string. Choose the variable name — for example DATABASE_URL or REDIS_URL — and Koo injects the database's published detail (the connection URL by default, or a single field like the host). It stays current if the database is ever re-provisioned, and the host it points at only resolves inside your app.

A reference to a credential — the connection URL, the password — is sensitive automatically. Its sensitivity comes from the field it points at, so you don't set it yourself.

psql "$DATABASE_URL"

From another variable

Point a variable at another variable by name, and it resolves to whatever that name resolves to — through the same scope precedence, nearest wins. Use it to expose one value under a second name that a library expects, without defining the value twice.

A reference to another variable inherits the target's sensitivity: point at a sensitive variable and the reference is sensitive too. Reading the value — including revealing it — always happens on the variable that actually holds it, never on the reference.

When a change takes effect

Variables are live configuration, applied on their own — not part of a deployment.

1. You add, change, or remove a variable.
2. Koo redeploys the services that use it, so their running containers pick up the new value.
3. Because a shared variable can reach many services, the console tells you how many will redeploy before you save.

Unlike the service's image and settings, variables are not restored by a rollback: rolling back a deployment leaves your current variable values in place.