stackblaze variables

Manages the linked app’s environment variables. Aliases: vars, var.

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>]

Subcommand	Description
`list`	List variables. Values are masked unless you pass `--reveal`
`set <KEY=value>...`	Add or update one or more variables
`unset <KEY>...`	Remove variables; asks for confirmation unless `-y`. Alias: `delete`
`import <file>`	Set every variable from a `.env` file
`edit`	Edit the app’s variables in your editor, review the changed names, then apply

Every subcommand accepts the scope and output flags: -p, --pipeline, --phase, -a, --app, --token, --api-url, -o, --output, --json.

Options

Flag	Applies to	Description
`--reveal`	`list`	Show values (requires write access to the app)
`--stdin`	`set`	Read `KEY=VALUE` lines from stdin, or the value of a single bare `KEY`
`--replace`	`import`	Make the app’s own variables exactly the file: variables not in the file are removed (add-on and env-group variables are kept)
`--skip-deploy`	`set`, `unset`, `import`, `edit`	Stage the change instead of deploying it; ship it later with `stackblaze pending apply`
`-m, --message <text>`	`set`, `unset`, `import`, `edit`	Release message shown in the deployment history
`-y, --yes`	`unset`, `import`, `edit`	Skip the confirmation (`import`: only asked with `--replace` when variables would be removed)

Examples

stackblaze variables list                          # values masked
stackblaze variables list --reveal                 # show values
stackblaze variables set NODE_ENV=production PORT=8080 -m "Prod settings"
stackblaze variables unset OLD_FLAG -y
stackblaze variables import .env.production             # merge a .env file
stackblaze variables import .env.production --replace   # app variables become exactly the file
stackblaze variables edit
stackblaze variables list -o json | jq -r '.vars[].name'

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

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

How it works

Each set, unset, import or edit sends only the change. The server applies it and makes one release per command: an app built from source rebuilds its image (build tools can bake variables in), other apps roll their pods. The release appears in stackblaze deployments with your -m message.

Sources: list tags each variable with where it comes from: the app itself, or injected by a linked add-on or env group ((addon), (group)). Injected variables can be overridden with set but not removed with unset, because they come back on every deploy; detach the add-on or group instead. import --replace and edit only touch the app’s own variables.
Masking: list masks values by default. --reveal and edit need write access to the app.
edit: opens $VISUAL or $EDITOR (default vi) on a KEY=VALUE buffer of the app’s own variables. Delete a line to unset it. After you save and quit, 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 is deleted afterwards.
Staging: with --skip-deploy the change is stored on the server instead of deployed. Combine several staged changes (including scale) and ship them as one release with stackblaze pending apply or stackblaze deploy --apply-pending.

With -o json, write commands print the result: changed (the variable names), release (trigger, rebuild, configRevisionId, or null when staged) and staged (the number of staged changes, when staging).

To write the variables to a local .env file, use stackblaze env pull.