Environment variables

Configure services with non-secret values that change between environments.

Environment variables carry configuration that differs between environments but is not sensitive: log levels, feature flags, external hostnames, tuning parameters. Anything sensitive belongs in secrets, which are stored and handled differently.

Setting variables

bash
guidal env set LOG_LEVEL=info --service api

Set several at once by repeating the flag, or import an existing file:

bash
guidal env import .env.production --service api

The import reads KEY=value lines and ignores comments and blank lines.

Reading and removing

bash
guidal env list --service api
guidal env delete LOG_LEVEL --service api

When changes take effect

Variables are applied at container start, so a change does not affect the running instance. The next deploy picks it up:

bash
guidal services deploy api

A set that never took effect

Setting a variable and then checking the running application without redeploying is the most common source of "my configuration is being ignored". guidal env list shows what is stored; the running process keeps whatever it started with.

Values injected for you

Some variables arrive without you setting them.

Linking a database or bucket to a service injects its connection details:

bash
guidal db link demo-db --service api
guidal storage link uploads --service api

This is preferable to copying credentials into a variable by hand — the value stays current if credentials rotate, and it never passes through your shell history.

In the dashboard

  1. In the navigation pane, choose Services.
  2. Choose the service name.
  3. Choose the Environment tab.
  4. Choose Edit, make your changes, and choose Save.

Naming

Variable names are case-sensitive and conventionally uppercase with underscores. Names beginning with GUIDAL_ are reserved for values the platform injects.