EAS Build seems to ignore environment variables


We have tried different ways to use environments variables in app.config.js. Like described in switching-configuration-based-on-the-environment. But we cannot make it work with EAS Build. Following command fails on expo build server. Because our app.config cannot find the process.env.APP_ENV env variable.

npx cross-env APP_ENV='qa' VERSION_CODE=20 eas build --platform android

Minimal example of eas config that fails on EAS Build

the same env you are setting locally needs to be also set on eas worker either

1 Like

Amazeballs! Updating eas.json with env records worked. This is great for choosing qa or production environment :smiley:

How do we then dynamic change android VERSION_CODE?

We usually let our CI handle that. But with a static eas.json file we don’t have a clear path?

A workaround could be to

  1. update eas.json with VERSION_CODE record in env on CI system
  2. git commit (would like to avoid this on our CI system)
  3. execute the eas build command

Is there a better way (we also need to update releaseChannel dynamic)?

1 Like

It’s possible that in the future we will provide a way to specify some envs dynamically, but we don’t plan to support dynamic values in eas.json, it still is possible to do it with workarounds, but it’s not sth we are recommending.

To address specific cases you mentioned, the recommended approach would be:

  • VERSION_CODE seems like a value that should be committed to repo
  • release channel for classic updates has to be generated in some cases, but new updates service will introduce concepts e.g runtimeVersion that will make it unnecessary and you won’t need more than a fixed number of channels, so you can create separate profile in eas.json for that.
  • for iOS updating version/buildNumber on ios you can use autoIncrement option, it’s problematic when running on ci because you would need to push changes back to your repo and it’s supported only for ios, so it’s probably not a good approach for your case

If you want to keep your current workflow, the only workaround I see is to modify eas.json on the fly and commit changes before build.

If you want to avoid git commit at all costs you can run build with EAS_NO_VCS=1, but I don’t recommend that, it may result in a larger upload because only top level .gitignore is respected and it’s problematic to use in monorepo


Thank you for your insightful answers and help. It is much appreciated!

We use the VERSION_CODE as a build number for android, and that is the reason it is a bit tedious to keep track of in our git repo. It is so easy to forget :sweat_smile:

I like your ideas about autoIncrement. But you’re right. It is not a good solution when we use CI system.

We will go back to your recommendation, and change the VERSION_CODE on each commit to our release branch.

Would be nice, if we could update it the environment like the concepts of EAS Secrets you mentioned.

Secrets just needs an update command (i couldn’t find it). Maybe sth like:

Manage an environment variable on the current project or owner account.

  $ eas env:COMMAND

  env:create  Create an environment variable on the current project or owner account.
  env:update Update an environment variable on the current project or owner account.
  env:delete  Delete an environment variable by ID.
  env:list    Lists environment variables available for your current current project or owner account.
eas secret
Create an environment secret on the current project or owner account.

  $ eas secret:COMMAND

  secret:create  Create an environment secret on the current project or owner account.
  secret:delete  Delete an environment secret by ID.
  secret:list    Lists environment secrets available for your current app
1 Like

Thanks again :pray:


How do i update a secret?

Delete and then create again? :blush:

My example above was a wish for how it could look like for defining environment variables. But I am aware that this almost the same as secrets. Secrets just have another purpose IMO

yup, you can delete and re-create to update it

1 Like

Not being able to do this is a huge pain when it comes to automating builds. It took me FOREVER to figure out that it was the environment variables not being passed to EAS. I’d LOVE to be able to pass environment variables to EAS via the command line.

I ended up writing a script to manually update my app.json from env variables and went with the EAS_NO_VCS=1 flag. I don’t use a monorepo approach (everything’s in its own repo), so this works well for me.

There is env filed in eas.json that you can use, those envs will be both available on the remote builder and when evaluating app.config.js locally Configuring EAS Build with eas.json - Expo Documentation

Is there any chance that in future doing something like this:

SOME_ENV_VAR="something" eas build

could do the usual shallow clone, and then set the value of SOME_ENV_VAR in env in eas.json? (Only for environment variables that are already defined in eas.json, presumably)?

I have been facing a similar issue around dynamically adding preview API_URL for each app build on the CI. We have an API backend architecture in which a separate & dynamic API_URL is created for each PR’s CI process which needs to be the fed through environment variables in the app build. I would have imagined API_URL="https:/dynamic-api-url" eas build --profile preview --platform all --non-interactive would have solved the issue and added API_URL into the build as an env var, but after reading this and trying to implement it, that doesn’t seem to be the case.

I am going to give the custom script/EAS_NO_VCS thing a go but seeing as mine is a monorep, I’m not that hopeful.

I was hoping if “environment variables through command prompt” can be implemented into eas cli as it would such a huge help?

1 Like

I still facing the same problem in here, eas build is not reading environment variables from eas.json when it is triggered from gitlab-ci.yml

So it works for you if you run the command manually instead of via gitlab-ci.yml?

What command is being run?