Documentation sections

Automate

Variables and secrets

Variables keep configuration out of workflow source. SolidActions has workspace Variables with values for each environment, and project mappings that decide what a workflow variable receives at runtime.

Last reviewed July 14, 2026

Problems this solves

Start with the recurring problem, then use this feature when its boundary matches the outcome you need.

Problem

Keep environment configuration out of source

Development and production need different IDs, limits, URLs, or secrets without separate branches of workflow code.

How this helps

Declare stable workflow-facing names, then give each Project environment its own local, global, secret, or Connection-backed value.

See calendar IDs, limits, and prefixes →

Problem

Rotate one shared value safely

A credential used by several Projects changes and editing, rebuilding, and redeploying every repository would create needless risk.

How this helps

Map Projects to a workspace Variable so an authorized operator can rotate the value centrally while keeping it out of bundles and logs.

Understand the two levels

LevelUse it forPath
Workspace VariableA reusable value such as a database URL or internal API key, with production, staging, and dev resolution.Automate → Variables
Project mappingThe value source for one workflow-facing name in one project environment.Projects → project → Variables

Create a workspace Variable

  1. Open Automate → Variables and choose Add variable.
  2. Enter an uppercase key such as DATABASE_URL.
  3. Turn on Secret for credentials or values that should remain masked.
  4. Set the production value, then choose direct or inherited values for staging and dev.

Environment inheritance

  • Production uses its own required value.
  • Staging can use its own value or inherit production.
  • Dev can use its own value, inherit production, or inherit staging.

Expand a row to inspect resolution for all environments. Secret values stay masked until someone with the necessary Connections permission explicitly reveals them.

Map a project variable

Open the exact project environment, then Project → Variables. Variables declared by YAML appear first; additional bindings appear under Manually Added. Choose Add orAdd mapping, then select one source:

Global variable
Resolve a workspace Variable for this project's production, staging, or dev environment.
OAuth connection
Inject authorization from a named workflow Connection at runtime.
Local value
Store a value only for this specific project environment.

YAML defaults remain visible after an override. Use Reset to YAML default to return to the deployed declaration. Removing a configured YAML binding clears its current source without erasing the declaration from the project.

Declare variables in YAML

env:
  - REQUIRED_AT_DEPLOY
  - DATABASE_URL: WORKSPACE_DATABASE_URL
  - GITHUB:
      oauth: "Production GitHub"

Workflow code reads the local names (REQUIRED_AT_DEPLOY, DATABASE_URL, andGITHUB). A variable can map to one source at a time. Names beginning withSOLIDACTIONS_ are reserved for the runtime and cannot be used as project mappings.

Create global mapping targets before the first deploy.

A plain YAML declaration may be deployed before it has a value. A mapping such asDATABASE_URL: WORKSPACE_DATABASE_URL needs the workspace Variable to exist when deploy syncs the project. If you create it later, map it in the app or with solidactions env map, or redeploy. Verify the result with solidactions env list my-project -e production.

Use the CLI for local development

solidactions env set DATABASE_URL VALUE --global --secret
solidactions env map my-project DATABASE_URL DATABASE_URL
solidactions env list my-project -e production
solidactions env pull my-project -e staging
solidactions env push my-project . -e staging

Review confirmation prompts before pulling plaintext secrets. The deploy bundle always excludes.env and .env.*; that is a safety boundary, not a file-transfer mechanism.

Do not use API keys as command arguments unless a command explicitly provides a secret-safe input.

Shell history, logs, and process inspection can expose secrets. Prefer masked prompts and protected environment files.

Next: create a reusable workflow Connection or deploy the mappings withyour project.