Variables and environment

Manage environment variables, stage changes, and run local commands with an app's variables.

stackblaze variables

Aliases: vars, var

Manages the linked app's environment variables. Every write sends only the change, and the server makes one release per command: an app built from source rebuilds, other apps roll.

usage

stackblaze variables list [--reveal]
stackblaze variables set <KEY=value>... [--stdin] [--skip-deploy] [-m <text>]
stackblaze variables unset <KEY>... [-y] [--skip-deploy] [-m <text>]
stackblaze variables import <file> [--replace] [-y] [--skip-deploy] [-m <text>]
stackblaze variables edit [-y] [--skip-deploy] [-m <text>]

list masks values unless you pass --reveal. It also shows where each variable comes from: the app itself, or a linked add-on or env group. Injected variables can be overridden with set but not removed with unset; detach the add-on or group instead.

set --stdin keeps secrets out of shell history: with a single bare key it reads the value (a hidden prompt in a terminal); without a key it reads KEY=VALUE lines.

edit opens $VISUAL or $EDITOR (default vi) on the app's own variables. Delete a line to unset it. After you save, the added (+), changed (~) and removed (-) names are shown without values, and you confirm before anything is applied. The temporary file is readable only by you and deleted afterwards.

unset is also available as delete. import --replace makes the app's own variables exactly the file; add-on and env-group variables are kept. --reveal and edit need write access to the app.

Flag	Description
`--reveal`	`list`: show values
`--stdin`	`set`: read `KEY=VALUE` lines from stdin, or the value of a single bare `KEY`
`--replace`	`import`: remove the app's own variables that are not in the file
`--skip-deploy`	Stage the change instead of deploying it; ship it later with `stackblaze pending apply`
`-m, --message <text>`	Release message shown in the deployment history
`-y, --yes`	`unset`, `import --replace`, `edit`: skip the confirmation

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. Common flags

Examples

terminal

stackblaze variables list
stackblaze variables set NODE_ENV=production PORT=8080 -m "Prod settings"
printf %s "$STRIPE_KEY" | stackblaze variables set STRIPE_KEY --stdin
stackblaze variables set STRIPE_KEY --stdin        # prompts, input hidden
cat .env | stackblaze variables set --stdin
stackblaze variables unset OLD_FLAG -y
stackblaze variables import .env.production --replace
stackblaze variables edit

stackblaze pending

Changes made with --skip-deploy (on variables and scale) are staged on the server instead of deployed. pending shows them, ships them as one release, or drops them.

usage

stackblaze pending list
stackblaze pending apply [-m <text>]
stackblaze pending discard [-y]

Staged changes are stored per app, so everyone with access sees the same list, and the dashboard shows them with Apply and Discard. Staged values are encrypted at rest and never shown back. stackblaze deploy --apply-pending is the same as pending apply.

Flag	Description
`-m, --message <text>`	`apply`: release message shown in the deployment history
`-y, --yes`	`discard`: skip the confirmation

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. Common flags

Examples

terminal

stackblaze variables set FEATURE_X=on --skip-deploy
stackblaze scale web=4 --skip-deploy
stackblaze pending list
stackblaze pending apply -m "Launch FEATURE_X"
stackblaze pending discard -y

stackblaze env pull

Writes the linked app's variables to a dotenv file. It will not overwrite an existing file unless you pass --force. The file holds secrets in plain text, so keep it out of git.

usage

stackblaze env pull [--out <file>] [--force] [--include-metadata]

Flag	Description
`--out <file>`	Output path (default `.env.local`)
`--force`	Overwrite the file if it exists
`--include-metadata`	Also write `STACKBLAZE_PIPELINE`, `STACKBLAZE_PHASE` and `STACKBLAZE_APP`

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. Common flags

Examples

terminal

stackblaze env pull --out .env --force

stackblaze run

Runs a command on your machine with the linked app's variables added to its environment. The app's values win over local ones, and STACKBLAZE_PIPELINE, STACKBLAZE_PHASE and STACKBLAZE_APP are set too. Put CLI flags before the command; everything after it is passed through unchanged. Exits with the command's exit code.

usage

stackblaze run [scope flags] <command> [args...]

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app), plus --token and --api-url. Common flags

Examples

terminal

stackblaze run npm test
stackblaze run -a api node scripts/migrate.js --dry-run

stackblaze shell

Starts your shell ($SHELL, or cmd.exe on Windows) on your machine with the linked app's variables set, like run for an interactive session. Type exit to leave. For a shell inside the running app, use stackblaze ssh.

usage

stackblaze shell

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app), plus --token and --api-url. Common flags

Examples

terminal

stackblaze shell -a api

← Deploy and builds Scaling and pausing →