This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.

Reference for the environment variables available inside EAS Workflows jobs, including the env context and additional worker variables.

Every workflow job runs on a worker that has a set of environment variables available to it. You can read these variables in two ways:

• With the ${{ env.NAME }} interpolation syntax, anywhere a job interpolates values (for example, in params, if, env, and run).
• As standard shell variables ($NAME) or through process.env.NAME from inside a run step.

name: Print environment

jobs:
  print:
    steps:
      # Interpolated before the command runs.
      - run: echo "Project: ${{ env.EAS_BUILD_PROJECT_ID }}"
      # Read from the shell environment at runtime.
      - run: echo "Project: $EAS_BUILD_PROJECT_ID"

Precedence

The variables available in a job are merged from three sources. When the same name is defined in more than one source, the one higher in this list wins:

On top of these, the worker sets a number of additional variables such as EAS_BUILD_ID and CI. Avoid naming your own variables with the EAS_ prefix so these don't shadow them.

The job environment

Which EAS environment variables a job can read depends on its environment: production (the default), preview, or development. Only variables assigned to that environment are exposed to the job.

Each job resolves its environment differently:

• build jobs infer it from the build profile's environment in eas.json.
• submit jobs inherit it from the submitted build.
• maestro and maestro-cloud jobs default to preview.
• Other jobs default to production.

Set jobs.<job_id>.environment explicitly to override the default and keep a job in sync with the build profile it pairs with. For more details on selecting an environment for a job, see Using environment variables in EAS Workflows.

The ${{ env }} context

The ${{ env }} context is a record of environment variables keyed by name. It is available within a job's context, not at the top level of the workflow. For example, you can use it in a job's params, if, env, outputs, and run, but not in the top-level on triggers.

jobs:
  notify:
    type: slack
    params:
      # Reads the SLACK_WEBHOOK_URL EAS environment variable.
      webhook_url: ${{ env.SLACK_WEBHOOK_URL }}
      message: 'Deploy finished'

Interpolation happens in two places, which changes what ${{ env.NAME }} can resolve:

• Job configuration (params, if, outputs, and the value of env itself) is interpolated before the job is dispatched to a worker. At this point, env contains your EAS environment variables for the resolved environment. The additional worker variables and the job's own env values are not yet available here.
• run commands are interpolated on the worker, where env reflects the full runtime environment: EAS environment variables, the job's env, and the additional variables.

Because of this, read variables like EAS_BUILD_ID inside a run step rather than in a job's params. Inside a run step, ${{ env.EAS_BUILD_ID }} and $EAS_BUILD_ID are equivalent.

Values interpolated from EAS environment variables of type secret or sensitive are redacted in workflow logs.

Context variables

Environment variables are not the only thing a job can interpolate. The same ${{ ... }} syntax exposes several context objects that describe the workflow run. The env context covered above is one of them. The others are documented below. For the interpolation syntax and the available context functions such as toJSON, fromJSON, and success(), see Syntax.

To see the full contents of any context at runtime, print it with toJSON. For example, run: echo '${{ toJSON(github) }}'.

github

Fields from the GitHub event that triggered the workflow. When you start a run with eas workflow:run, event_name is workflow_dispatch and the other fields are empty.

github {
  triggering_actor,   // User who triggered the run, e.g. jonexpo
  event_name,         // 'pull_request', 'push', 'schedule', or 'workflow_dispatch'
  sha,                // Commit SHA
  ref,                // Full ref, e.g. refs/heads/main
  ref_name,           // Short ref, e.g. main
  ref_type,           // 'branch', 'tag', or 'other'
  commit_message,     // Only for push and schedule events
  label,              // Label name, for pull_request_labeled events
  repository,         // e.g. expo/expo
  repository_owner,   // e.g. expo
  event {             // Full GitHub webhook payload
    action,
    head_commit { message, id },   // Only for push and schedule events
    pull_request {
      number,
      title,
      body,
      state,          // 'open' or 'closed'
      draft,
      merged,
      html_url,
      user { login },
      labels,         // Array of { name }
      head { ref, sha },   // Source branch
      base { ref, sha },   // Target branch
      created_at,
      updated_at,
      merged_at,
      // ... and other fields from the GitHub Pull Request webhook payload
    },
    inputs,           // workflow_dispatch inputs
    schedule,         // Cron expression, for scheduled runs
    number,
  }
}

The event object contains the full GitHub webhook payload. For a detailed field reference and examples, see github in the Syntax guide.

inputs

A record of the inputs provided when you start the workflow manually with workflow_dispatch. Empty when the workflow is triggered another way.

jobs:
  greet:
    steps:
      - run: echo "Hello, ${{ inputs.name }}!"

needs

A record of the upstream jobs listed in the current job's needs. Each entry provides the job's status (success, failure, or skipped) and its outputs.

jobs:
  notify:
    needs: [build]
    steps:
      - run: echo "Build status: ${{ needs.build.status }}"

after

A record of the upstream jobs listed in the current job's after, whether or not they succeeded. Each entry provides the same status and outputs shape as needs.

jobs:
  notify:
    after: [build]
    steps:
      - run: echo "Build status: ${{ after.build.status }}"

steps

A record of the steps in the current job, keyed by step id. Each entry exposes the outputs set with the set-output function. This context is only available within a job's steps.

jobs:
  my_job:
    steps:
      - id: step_1
        run: set-output my_greeting "hello"
      - run: echo "${{ steps.step_1.outputs.my_greeting }}"

metadata

Metadata about the build associated with the job. It is populated for build jobs and is an empty object ({}) for job types without build metadata, such as custom jobs.

metadata {
  buildProfile,     // Build profile from eas.json, e.g. production
  appVersion,       // App version, e.g. 1.0.0
  appBuildVersion,  // Build number (iOS) or version code (Android)
  sdkVersion,       // Expo SDK version, e.g. 54.0.0
  runtimeVersion,   // Runtime version for EAS Update
  gitCommitHash,    // Git commit the build ran against
  distribution,     // 'store' or 'internal'
}

workflow

Information about the current workflow run.

workflow {
  id,        // ID of the workflow run
  name,      // Name of the workflow
  filename,  // Name of the workflow file, e.g. deploy.yml
  url,       // URL of the run on the EAS dashboard
}

jobs:
  notify:
    type: slack
    params:
      message: |
        Workflow run completed: ${{ workflow.name }}
        View details: ${{ workflow.url }}

app_store_connect

Information about the App Store Connect entities associated with the run. This context is present only for workflows triggered by an App Store Connect event.

app_store_connect {
  app { id },
  build_upload {
    id,
    state,             // 'awaiting_upload', 'processing', 'failed', or 'complete'
    cf_bundle_version,
    build { id },
  },
  app_version { id, state },
  external_beta { id, state },
  beta_feedback {
    id,
    type,              // 'crash' or 'screenshot'
    url,
  },
}

on:
  app_store_connect:
    build_upload:
      states:
        - complete

jobs:
  notify:
    type: slack
    params:
      webhook_url: ${{ env.SLACK_WEBHOOK_URL }}
      message: |
        Upload complete for app: ${{ app_store_connect.app.id }}
        Upload state: ${{ app_store_connect.build_upload.state }}

For the event domains that populate each field and full examples, see app_store_connect in the Syntax guide.

Additional environment variables

In addition to the variables you set, the worker provides a number of variables on every job that runs on a virtual machine (VM), such as EAS_BUILD_ID, EAS_BUILD_PROJECT_ID, and CI. They are read at runtime, so reference them from within a run step. For the full list, see Built-in environment variables.

Workers also expose standard toolchain variables such as HOME, PATH, LANG, ANDROID_HOME, ANDROID_SDK_ROOT, and JAVA_HOME. Their exact values depend on the worker image and are subject to change.

Setting environment variables in a job

To define your own variables, use the env key on a job. Values can reference other context properties.

jobs:
  my_job:
    env:
      APP_VARIANT: staging
      COMMIT: ${{ github.sha }}
    steps:
      - run: echo "Building $APP_VARIANT at $COMMIT"

Share a value with later steps in the same job

Use the set-env command to compute a value in one step and read it in later steps of the same job. The command is available on the worker's PATH. It's the environment-variable counterpart to set-output: set-output exposes a named job output, while set-env exposes an environment variable to the job's subsequent steps.

jobs:
  my_job:
    steps:
      - run: set-env GENERATED_TAG "v$(date +%Y%m%d)"
      # `set-env` only affects later steps, so the value is available here.
      - run: echo "Tag is $GENERATED_TAG"