---
modificationDate: March 16, 2026
title: Using Environment variables in EAS
description: Learn how to use environment variables in EAS builds, updates, hosting, and workflow jobs.
---

<AgentInstructions>

## Submitting Feedback

If this page contains errors, outdated information, or gaps that blocked you from completing a task, report it so the docs can be improved:

curl -X POST https://api.expo.dev/v2/feedback/docs-send -H 'Content-Type: application/json' -d '{"url":"/eas/environment-variables/usage/","feedback":"🤖 Agent feedback: <specific, actionable description>"}'

Only submit when you have something specific and actionable to report.

</AgentInstructions>

# Using Environment variables in EAS

Learn how to use environment variables in EAS builds, updates, hosting, and workflow jobs.

> For the complete documentation index, see [llms.txt](/llms.txt). Use this file to discover all available pages.

The following sections cover how to use environment variables in EAS builds, updates, and workflow jobs.

## Using environment variables with EAS Build

To have full control over the environments used for your builds, you can specify the [`environment`](/eas/json#environment) field in the build profiles settings in the **eas.json** file.

```json
{
  "build": {
    "development": {
      "environment": "development"
      ... 
    },
    "preview": {
      "environment": "preview"
      ... 
    },
    "production": {
      "environment": "production"
      ... 
    },
    "my-profile": {
      "environment": "production"
      ... 
    }
  }
}
```

All of the environment variables from the selected environment will be used during the build process. Plain text and sensitive variables will be available when resolving build configuration based on the dynamic app config in EAS CLI as well.

If you don't set the `environment` option, we will set the environment automatically based on your build's configuration:

-   `production` when `distribution` is set to `store`
-   `development` when `developmentClient` is `true`
-   `preview` for everything else

Built-in environment variables

The following environment variables are additional system environment variables exposed to each job and can be used within any build step. They are not a part of any project environment and are not available when evaluating **app.config.js** locally:

-   `CI=1`: Indicates this is a CI environment
-   `EAS_BUILD=true`: Indicates this is an EAS Build environment
-   `EAS_BUILD_PLATFORM`: Either `android` or `ios`
-   `EAS_BUILD_RUNNER`: Either `eas-build` for EAS Build cloud builds or `local-build-plugin` for [local builds](/build-reference/local-builds)
-   `EAS_BUILD_ID`: The build ID, for example, `f51831f0-ea30-406a-8c5f-f8e1cc57d39c`
-   `EAS_BUILD_PROFILE`: The name of the build profile from **eas.json**, for example, `production`
-   `EAS_BUILD_PROJECT_ID`: the EAS project ID, for example, `bd2f7e21-1ee7-47f2-8357-d7c4b50622fb`
-   `EAS_BUILD_GIT_COMMIT_HASH`: The hash of the Git commit, for example, `88f28ab5ea39108ade978de2d0d1adeedf0ece76`
-   `EAS_BUILD_NPM_CACHE_URL`: The URL of npm cache ([learn more](/build-reference/private-npm-packages))
-   `EAS_BUILD_MAVEN_CACHE_URL`: The URL of Maven cache ([learn more](/build-reference/caching#android-dependencies))
-   `EAS_BUILD_COCOAPODS_CACHE_URL`: The URL of CocoaPods cache ([learn more](/build-reference/caching#ios-dependencies))
-   `EAS_BUILD_USERNAME`: The username of the user initiating the build (it's undefined for bot users)
-   `EAS_BUILD_WORKINGDIR`: The remote directory path with your project
-   `EAS_BUILD_DISABLE_BUNDLE_JAVASCRIPT_STEP`: Set to `1` to skip the early JavaScript bundling check. By default, EAS Build runs the JavaScript bundler before the native build to surface JS errors earlier. Disabling this step means JavaScript errors won't be caught until the native build step.

> The environment variables of secret type are not available during build configuration resolution in EAS CLI as they are not readable outside of the EAS servers.

## Using environment variables with EAS Update

In **SDK 55 or later**, the `--environment` flag is required when running `eas update`. The environment variables from the specified EAS environment will be used during the update process. For projects using SDK 54 or earlier, `eas update` falls back to local **.env** files when the `--environment` flag is omitted.

To use EAS environment variables with EAS Update, run the `eas update` command with the `--environment` flag:

```sh
eas update --environment production
```

When the `--environment` flag is used, **only the environment variables from the specified EAS environment will be used during the update process** and won't use the **.env** files present in your project. This ensures the same environment variables are used for both your updates and builds.

Expo CLI will substitute prefixed variables in your code (for example, `process.env.EXPO_PUBLIC_VARNAME`) with the corresponding plain text and sensitive environment variable values set on EAS servers for the environment specified with the `--environment` flag. Any `EXPO_PUBLIC_` variables in your application code will be replaced inline with the corresponding values from your EAS environment whether that is your local machine or your CI/CD server.

The `--environment` flag ensures the same environment variables are used for both your update and build jobs.

> The secret variables will not be available during the update process as they are not readable outside of EAS servers.

## Using environment variables with EAS Hosting

An Expo Router web project can include environment variables that are used on both the client and the server. Client-side values are inlined in the JavaScript bundle when you run `npx expo export`, while server-side values are stored on the server and are deployed with your API routes when you run `eas deploy`.

> With EAS Hosting, only **plain text** and **sensitive** [environment variables](/eas/environment-variables#visibility-settings-for-environment-variables) can be used. Secrets cannot be deployed with EAS Hosting.

Client-side environment variables

All code that runs in the browser is client-side. In an Expo Router project, this includes all code that is not an API Route or server function. The environment variables in your client-side code are inlined at build time. You should never put any sensitive information in your client-side code, which is why all client-side environment variables must be prefixed with [`EXPO_PUBLIC_`](/guides/environment-variables).

When you run `npx expo export`, all instances of `process.env.EXPO_PUBLIC_*` environment variables will be replaced with values from the environment.

Server-side environment variables

All the code in your [API routes](/router/web/api-routes) (files ending with **+api.ts**) runs on the server. Since the code running on the server is never visible to the app user, you can safely use sensitive environment variables such as API keys and tokens.

Server-side environment variables are not inlined in the code, they are uploaded with the deployment when you run the `eas deploy` command.

### Storing environment variables

When deploying a project with EAS environment variables, note that the environment variables for the client-side and server-side code are included at different steps:

-   Running `npx expo export --platform web` will inline the `EXPO_PUBLIC_` variables in the frontend code. So ensure that your **.env.local** file includes the correct environment variables before running the `npx expo export` command.
-   `eas deploy --environment production` will include all variables for the given environment (in this case, `production`) in the API routes. EAS Environment variables loaded with the `--environment` flag will take precedence over ones defined in **.env** and **.env.local** files.

> **Environment variables are per deployment, and deployments are immutable**. This means that after changing an environment variable, you will need to re-export your project, and re-deploy in order for them to be updated.

### For local development

For local development, both client- and server-side environment variables are loaded from [local **.env** files](/guides/environment-variables), which should be gitignored. If you are using EAS environment variables, use [`eas env:pull`](/eas/environment-variables/manage#pull-variables-for-local-development) to retrieve the environment variables for `development`, `preview`, or `production`.

## Using environment variables for other commands

One way to supply non-secret EAS environment variables to other EAS commands is to use the `eas env:exec` command.

```sh
eas env:exec --environment production 'echo $APP_VARIANT'
```

For example, it can be useful when uploading source maps to Sentry using a [`SENTRY_AUTH_TOKEN`](/guides/using-sentry) variable after an update bundle is created.

```sh
eas env:exec --environment production 'npx sentry-expo-upload-sourcemaps dist'
```

## Using environment variables in EAS Workflows

### Setting EAS environment for workflow jobs

-   **Build jobs**: The environment comes from the build profile in **eas.json** (`build.<profile>.environment`). If that field is missing, the automatic defaults described above apply. [Using environment variables with EAS Build](/eas/environment-variables/usage#using-environment-variables-with-eas-build).
-   **Other jobs** (for example, update, submit, fingerprint, Maestro, and custom jobs): Set [`jobs.<job_id>.environment`](/eas/workflows/syntax#jobsjob_idenvironment). If you omit it, `production` is used. Setting it explicitly helps keep the job in sync with the build profile you used earlier in the workflow.

In the following example, a build job is configured to use the `preview` profile, then an update job is configured to use the same EAS environment.

```yaml
name: Publish preview build and update

jobs:
  build_preview:
    type: build
    params:
      platform: ios
      profile: preview # uses environment from eas.json's build.preview.environment

  publish_preview_update:
    needs: [build_preview]
    type: update
    environment: preview # pulls variables from the preview environment
    params:
      branch: preview
```

In the following example, a fingerprint job is configured to use the `production` environment, then a build job is configured to use the same EAS environment.

```yaml
name: Fingerprint and build

jobs:
  fingerprint:
    type: fingerprint
    environment: production # defaults to production, but set explicitly to match the build
  build_ios:
    needs: [fingerprint]
    type: build
    params:
      platform: ios
      profile: production # uses environment from eas.json's build.production.environment
```

Keep the job environment value in sync with the build profile to avoid mismatched secrets. For example, fingerprint/update jobs should usually match the build's profile environment.

### Dynamically setting environment variables during the job execution

You can also set environment variables dynamically during the job execution using the `set-env` command. The `set-env` executable is available in the `PATH` on EAS Build workers, and can be used to set environment variables that will be visible in the next build phases.

For example, you can add the following in one of the [EAS Build hooks](/build-reference/npm-hooks) and the environment variable `EXAMPLE_ENV` will be available until the end of the build job.

```sh
set-env EXAMPLE_ENV "example value"
```

### Accessing environment variables

After creating an environment variable, you can read it on subsequent EAS Build jobs with `process.env.VARIABLE_NAME` from Node.js or in shell scripts as `$VARIABLE_NAME`.