1---
2title: Use environment variables with EAS Update
3sidebar_title: Environment variables
4description: Learn how to set up and use environment variables with EAS Update.
5---
6
7import { Terminal } from '~/ui/components/Snippet';
8import { Step } from '~/ui/components/Step';
9
10## Using .env files with EAS Update
11
12The [Environment variables in Expo guide](/guides/environment-variables) describes how to use **.env** files to set and use environment variables within your JavaScript code. The Expo CLI will substitute properly-prefixed variables in your code (for example,`process.env.EXPO_PUBLIC_VARNAME`) with the corresponding environment variable values in **.env** files present on your development machine.
13
14When you run `eas update`, any **.env** files present will be evaluated when your JavaScript is bundled. Therefore, any `EXPO_PUBLIC_` variables in your application code will be replaced inline with the corresponding values from your **.env** files that are present on the machine from which the update is published, whether that is your local machine or your CI/ CD server.
15
16> When publishing with EAS Update, `EXPO_PUBLIC_` variables in **.env** files will only be used when bundling your app's JavaScript. They will not be available when evaluating **app.config.js**.
17
18## Sharing environment variables between local development, EAS Update, and EAS Build
19
20Your local development environment and EAS Update can use **.env** files to inline `EXPO_PUBLIC_` variables into your app source code as long as they are present on the machine the `eas update` command is being run. Meanwhile, EAS Build also supports defining environment variables that will be available on the EAS Build server in **eas.json**.
21
22One approach to ensure the correct variables are defined in all cases would be to define your variables in **.env** files for local development and EAS Update, while setting the same variables in a second place in **eas.json** for EAS Build. However, this duplication can be avoided by consolidating common environment configurations into code and switching based on EAS Update channel.
23
24For example, you might have separate `staging` and `production` channels for EAS Update defined in your **eas.json**:
25
26```json eas.json
27{
28  "build": {
29    "production": {
30      "channel": "production"
31    },
32    "staging": {
33      "channel": "staging"
34    }
35  }
36}
37```
38
39Each channel uses a different `apiUrl`, and `enableHiddenFeatures` enables an experimental feature flag, and these values rarely change. Instead of defining these values in the `env` inside **eas.json**, create a **Config.js** file in your project that exports the correct values based on the channel:
40
41```js Config.js
42import * as Updates from 'expo-updates';
43
44let Config = {
45  apiUrl: 'https://localhost:3000',
46  enableHiddenFeatures: true,
47};
48
49if (Updates.channel === 'production') {
50  Config.apiUrl = 'https://api.production.com';
51  Config.enableHiddenFeatures = false;
52} else if (Updates.channel === 'staging') {
53  Config.apiUrl = 'https://api.staging.com';
54  Config.enableHiddenFeatures = true;
55}
56
57export default Config;
58```
59
60Since `channel` is set for a build when using EAS Build, and builds configured for EAS Update only download updates from that channel, using channel to set your environment ensures that the correct values are used for all standalone builds, whether running the original embedded JavaScript or an update.
61
62### Setting a custom local environment
63
64Note the above solution only allows for one local configuration. That may not be flexible enough, as it is common to sometimes point your local development environment to different servers. We can update **Config.js** to also look at our **.env** files:
65
66```js Config.js
67let Config = {
68  apiUrl: process.env.EXPO_PUBLIC_API_URL || 'https://localhost:3000',
69  enableHiddenFeatures: process.env.EXPO_PUBLIC_ENABLE_HIDDEN_FEATURES || true,
70};
71
72// set variables based on channel...
73
74export default Config;
75```
76
77Now you can set `EXPO_PUBLIC_API_URL` and `EXPO_PUBLIC_ENABLE_HIDDEN_FEATURES` in an uncommitted **.env.local** file, and they will be used instead of the default when running `npx expo start`.
78
79This can also be used for EAS Updates run from your [development build](/develop/development-builds/introduction/). For example, you can point updates created for [PR previews](/eas-update/github-actions/#publish-previews-on-pull-requests) to a specific API server by committing an **.env** file with `EXPO_PUBLIC_API_URL` set.
80
81## Using variables in app.config.js
82
83[Expo environment variables](/guides/environment-variables) are only available in SDK 49 or higher. In previous versions, it was common to set variables to be used in updates in **app.config.js** under the `expo.extra` property:
84
85```js app.config.js
86export default () => ({
87  expo: {
88    extra: {
89      API_URL: process.env.API_URL || null,
90    },
91    // ...
92  },
93});
94```
95
96Then, to set the `API_URL` environment variable during development, you can prepend the variables before running `npx expo start` as shown below:
97
98<Terminal cmd={['API_URL="http://localhost:3000" expo start']} />
99
100The command sets the `API_URL` to `"http://localhost:3000"`. Then, the [`expo-constants`](/versions/latest/sdk/constants/#installation) library provides the `Constants.expoConfig.extra.API_URL` property to access it inside a project.
101
102Variables `expo.extra` are still accessible in SDK 49 and higher, but it is recommended to use the `EXPO_PUBLIC_` prefix and **.env** files instead to reference variables directly in your application code.
103