Most important concepts

Japanese translation unavailable

This page has not been translated into Japanese yet - we apologise for the inconvenience! If you’re interested in helping us out, feel free to translate any article in the jp folder of the DevCenter repository and open a PR!

このページは日本語への翻訳がまだ完了しておりません。ご不便をおかけして申し訳ございません! もしお手伝いできる方がいらっしゃれば、ご自由にjpフォルダの記事を日本語に訳していただき、PRを開いてください

Every input, output and parameter is an Environment Variable

Every step input, step output, secret environment variable, app environment variable and workflow environment variable (basically every input and variable in your build config) is an environment variable.

There’s nothing special about how Bitrise handles environment variables, these are regular environment variable, with the same rules and restrictions as any other environment variable.

To highlight a couple of technical details:

The value of an Environment Variable can only be a String

Environment Variables can only hold String values. Even if you set a number or bool, like 1 or true as the value of the Environment Variable, that will be a string.

Parent process can’t access Environment Variables exposed by child processes

Parent process(es) can’t access Environment Variables exposed by child processes.

For example, if you run a in your Terminal with bash, and sets an environment variable with export MY_VAR=the-value, you won’t be able to access MY_VAR in your Terminal after the script is finished, MY_VAR will only be available in and in the processes / scripts started by

In terms of Bitrise CLI this means that if you export MY_VAR=... in a Script step, MY_VAR won’t be available in subsequent steps. This is true for the steps too, regardless of which language the step is written in.

Bitrise CLI includes a mechanism for exposing environment variables from Steps so that subsequent Steps can also access it, through the Bitrise CLI tool called envman.

To set an environment variable in your script or in your step to make that available in other steps too, you have to do that through envman.

A simple example:

envman add --key MY_TEST_ENV_KEY --value 'test value for test key'

You can find more examples in envman’s README, and in the Expose an Environment Variable and use it in another Step guide.

Availability order of environment variables

Environment variables are available after the environment variable is “processed”.

There are a few environment variables exposed by the Bitrise CLI itself, those are available from the start (e.g. BITRISE_SOURCE_DIR and BITRISE_TRIGGERED_WORKFLOW_ID).

All other environment variables are “processed” / made available as the build progresses.

There are two types of environment variables which are processed and made available before the workflow would be executed: Secrets and App Env Vars (app: envs: in the bitrise.yml).

After these, the processing of the specified Workflow starts, and the environment variables specified for that Workflow are made available. If the workflow has before or after workflows, when a specific workflow is processed (right before the first step of the workflow would run) the workflow’s environment variables are processed and made available.

Step inputs are also environment variables; those are exposed only for the specific step, and right before the Step would start.

Last but not least Step outputs are exposed by the specific step, so those are available for subsequent steps after the Step finishes.

The environment variable processing order:

  1. Bitrise CLI exposed environment variables
  2. Secrets
  3. One-off environment variables specified for the build through the Build Trigger API
  4. App Env Vars (app: envs: in the bitrise.yml)
  5. Workflow environment variables
  6. Step inputs
  7. Step outputs

So, why does the processing order matter?

An environment variable is only available after it is processed and made available. When you reference or use an environment variable, you can only reference/use those which are already processed!

A couple of examples:

Environment variables of chained workflows

Once an environment variable of a workflow is processed and made available, it is available everywhere else during the build. This means that other workflows of the chain can use the environment variables of a workflow which is performed before the specific workflow, similar to Step outputs, which are available for every other step after the step (which generates the outputs) completes.

You can find more information about environment variable availability of Workflow env vars in chained workflows in the Workflows: Note about workflow environment variables documentation.