Environment variables in EAS

An overview of how to use Expo Application Services (EAS) environment variables across builds, updates, and workflows.

This guide explains how to use Environment Variables in Expo Application Services (EAS): Build, Updates, Workflows, and Hosting. For general information on how environment variables work with the Expo framework, refer to Environment variables in Expo.

During a local development, environment variables are loaded from your local .env or .env.local files. These files are generally excluded from the project's version control (that is, if they are listed in the .gitignore file or not committed) so they are not available for jobs that run on a remote server, for example, EAS Build and EAS Workflows. Additionally, most projects have multiple app variants and require multiple sets of environment variables (for instance Development and Production).

Why use EAS environment variables

You might want to use EAS Environment Variable if you need to:

• Keep configuration in one place for cloud builds, updates, and workflows without committing .env files.
• Separate values by environment (development, preview, production) while reusing names.
• Control visibility (plain text, sensitive, secret) so only the right surfaces can read each value.
• Apply the same set locally with eas env:pull or inside CI/CD.

These are the problems that EAS Environment variables is built to solve. With EAS Environment variables, the variables are configured in EAS via the EAS CLI or directly on the expo.dev dashboard, and can be accessed by EAS Build and EAS Workflows as well as your local machine via the EAS CLI.

Quick start

{
  "build": {
    "production": {
      "environment": "production"
    }
  }
}

Key concepts

Available environments

By default, EAS supports three environments for environment variables: development, preview, and production environments. Custom environment names are available on Enterprise and Production plans.

Each environment is an independent set of variables that can be used to customize your app in different contexts. For example, you can use different API keys for development and production, or use different bundle identifiers for app store releases.

Every EAS Build and Workflows job runs using environment variables from one of the available environments. You can also use environments for updates, allowing you to use the same set of environment variables for your build jobs. You can do this when publishing an update by providing the --environment flag.

Environment variables can be assigned to multiple environments and have the same value across all of them, or be created for a single environment.

Scope

• Project-wide: Specific to a single EAS project. You can create, view, and manage them by navigating to the Environment variables page in your project's dashboard. These environment variables are available in any jobs that run on EAS servers and updates for this project. They can also be pulled locally for development if their visibility setting allows it.
• Account-wide: Available across all projects in your EAS account. You can create, view, and manage them by navigating to the Environment variables page in your account's dashboard. These environment variables are available in jobs that run on EAS servers and updates, together with project-wide variables for a project. You can pull them locally or read outside of EAS servers if their visibility setting allows it.

Variable types

• Strings: Standard key/value pairs that can be used across builds, updates, workflows, and hosting.
• Files: Values uploaded as files (for example, google-services.json or a certificate) that are made available to jobs as file paths on the build runner.

Visibility settings for environment variables

There are three different visibility settings available for each environment variable:

Note that anything that is included in your client side code should be considered public and readable to any individual that can run your app.

Secret type environment variables are intended to provide values to an EAS Build or Workflows job so that they may be used to alter how a job runs. For example, setting an NPM_TOKEN to install private packages from npm, or a setting a Sentry API key to create a release and upload your source maps. Secrets do not provide any additional security for values that you end up embedding in your application itself.

Where to go next