Environment Variables

Runway provides an environment-variable inventory for Preview, Development, and Production on top of Databricks secret scopes. Both sensitive credentials and ordinary runtime configuration are handled as secret-backed values because Databricks does not provide a Vercel-style readable environment-variable store for Apps. Runway's secrets.sync action populates those scopes as a governed, audited action — while guaranteeing that a secret value never lands in an action parameter, an event, or a projection.

Scope naming

Runway owns the scope name so it is predictable and per-environment:

runway-<appId>-<environment>

The same variable is passed into the bundle as BUNDLE_VAR_secret_scope, so the Databricks App resolves its secrets from the scope Runway synced. Prod scope sync is allowed — it is a governed, audited action, not a deploy.

Values never enter the action

Instead of passing values, secrets.sync takes an opaque secretCommandId:

1. The operator (or console form) writes the secret values into a one-time secret command — encrypted at rest (AES-256-GCM), scope-bound, single-use (consumed_at), and expiring.
2. secrets.sync carries only { appId, environment, secretCommandId }. The runtime redacts any other parameter before the durable invocation is recorded.
3. The resulting event and the secrets projection record only key names and the scope — never a value.
4. At the workspace edge, the store yields the plaintext exactly once to write the scope, then marks the command consumed.

What you can see afterwards

The console's Environment Variables view presents a cross-environment matrix for each app. It shows which keys exist in Preview, Development, and Production, plus the last sync time. A bulk editor can update several keys in one governed operation. Values are never rendered back—Databricks Secrets is intentionally write-only through this product surface, so there is nothing to leak.

Updating an existing key overwrites its value at the workspace edge. Each key also has governed rename and delete controls. runway.secret_delete invokes the typed secrets.delete adapter and emits completion only after Databricks succeeds. runway.secret_rename requires a new opaque replacement-value command because Databricks Secrets cannot reveal or copy the old value; it durably writes the new key first, deletes the old key second, then emits RunwaySecretRenamed. The same actions are available to authorized Harness and MCP agents.