Environment Variables

Environment variables store non-secret configuration for your provider organisation. Use them in cloud-init templates with Jinja references like {{ env.APP_ENV }}.

Manage variables at /configuration/env-vars under Orchestration → Environment Variables.

What they are for

Use case	Example key	Example value
Deployment tier	`APP_ENV`	`production`
Internal service URL	`METRICS_ENDPOINT`	`https://metrics.internal`
Feature flag	`ENABLE_DEBUG`	`false`

Values are stored in the NodeRings database (not Vault). They appear in API list responses: do not put passwords or API tokens here; use Secrets instead.

Create and update

Open Environment Variables

Navigate to /configuration/env-vars.

Add a key and value

Choose a descriptive key (lowercase with underscores is typical).

Reference in cloud-init

In a template user-data field:

#cloud-config
write_files:
  - path: /etc/nrings/app.env
    content: APP_ENV={{ env.APP_ENV | tojson }}

Reserved key names

Keys must not collide with built-in Jinja namespaces used at provision time:

Exact names such as password, hostname, gateway
Prefixes vm, vm_network, env, secret

If create or update is rejected with a reserved-key error, rename the key.

Bulk import

When migrating many keys from another system:

Prepare a CSV or script with key, value, and optional description columns.
Import via API: use EnvironmentVariableService/CreateEnvironmentVariable for each row.
Validate templates: open affected cloud-init templates and confirm every {{ env.KEY }} reference matches an existing key.
No re-sync step: NodeRings loads current values when each VM is created; there is no separate org-context secret to refresh.

Import in a staging org first. Undefined env.* references produce validation warnings on template save and at client profile validation time.

Secrets: Vault-backed sensitive values
Cloud-init templates: env.* and built-in variables