Environment Variables

The Environment Variables page manages every variable the Console hands to the deployed services. Variables can be plain values, references to Kubernetes secrets, or references to ConfigMaps. They can be set globally and overridden per instance.

The page has three tabs.

Variables tab

The default. A flat list of every variable with per-instance overrides expandable per row.

Toolbar

A single token-aware filter field with these tokens:

• type:value, type:secretKeyRef, type:configMapKeyRef
• service:<name>
• instance:<name> — filters to variables that have an override on the given instance

Negation works: -type:value, -service:nodejs.

Free text matches variable keys and service names.

Count chip shows filtered vs. total. Add Variable button is top right.

Columns

Column	Notes
Key	Monospace, bold. Auto-uppercase on entry. Has an expand chevron.
Type	Badge — value, secretKeyRef, or configMapKeyRef.
Default	The value, or the name/key ref. Monospace, truncated.
Services	Up to two service chips; "+N more" popover for the rest.
Description	Short description, truncated.
Actions	Edit and delete icons.

Expanded row — per-instance overrides

Click the chevron to expand. A sub-table shows every instance with an override:

• Instance name and environment.
• Override value or ref.
• Last updated timestamp with the user who changed it.
• Edit / Delete icons.

You can also see which instances have no override ("Using default").

Inside the sub-table, the filter from the main toolbar still applies — instance:prod narrows the visible instances.

Editing inline

The Add / Edit row uses inline editing — the row background tints info-colour and the cells become form inputs:

• Key — auto-uppercase, locked when editing.
• Type dropdown.
• Default Value — plain text for value, name/key format for refs.
• Services — multi-select (services must already exist on the Release Configuration page).
• Description.

Click Save to persist, Cancel to discard. Errors appear inline below the row.

Setting an instance override

Inside an expanded row, click the + icon (or the pencil if an override already exists) next to an instance:

• A modal opens for the override value.
• The override can be a plain value or a name/key ref.
• Click Save.

To remove an override, click the trash icon — the instance reverts to the default.

Decommissioned instances are excluded from the override table.

By Service tab

The same variables, grouped by service.

• Service filter — search box at the top filters which services show.
• Each service is a collapsible card with the count of assigned variables.
• Inside an expanded service: a table of assigned variables with Remove buttons.
• Add Variable button opens a picker showing unassigned variables — pick one or many, then close.

This view is most useful when you need to see "what does this service see?" rather than "where is this variable used?"

Version History tab

Every change to environment variables is versioned globally.

Columns

Column	Notes
Version	v1, v2, v3… in monospace.
Changes	Multi-line — change action badge, key, scope.
Changed By	User avatar and name.
Date	Absolute timestamp.

Pagination

50 entries per page. Click Load More to fetch more.

The version history is global — releases that touch environment variables produce entries here, and per-instance override changes do too.

Notes

• The Console resolves a variable to a concrete value by consulting (1) instance override → (2) global default. If a service does not see the expected value, the most likely cause is an override at the instance level.
• Secret refs and ConfigMap refs are validated at deploy time by the agent, not at save time here. A typo in name/key will surface as a deployment failure.
• Decommissioned instances do not appear in override tables and do not receive variable changes.
• The version history is your friend for "who changed this and when".