EAS CLI: cloud builds, store submissions and OTA updates from the terminal

What EAS CLI solves, and who it is actually for

Producing a signed iOS binary normally means Xcode, a provisioning profile, a distribution certificate and a Mac. Producing a signed Android binary means a keystore and a Gradle release configuration. EAS CLI replaces that local toolchain with a remote one: the README describes it as the command-line interface for Expo Application Services, which it calls deeply integrated cloud services for Expo and React Native apps, from the team behind Expo. The terminal is the control surface; the compilation happens elsewhere.

The audience is narrow and specific. You need an Expo or React Native project, an Expo account, and a willingness to let a hosted service hold your signing credentials and run your builds. If your app is a bare native project with no Expo configuration, or if your organisation forbids uploading source to a third-party build service, this tool is not aimed at you. The README frames the whole product as a path from source code to production for Expo and React Native apps, and nothing in it suggests a use outside that pair.

How the CLI is structured: one binary, several cloud services

The repository is a Yarn 4 workspace. The root package.json is named eas-cli-root, is marked private, and declares workspaces under packages/*, with Lerna driving build, typecheck and test across them. The command surface is generated with oclif, which is why the README carries a long alphabetical command index beneath a Commands marker. That index is generated from packages/eas-cli/scripts/readme-header.md, and the README warns that running yarn version regenerates README.md and overwrites the generated content, so edits to the command list belong in the source file, not the README.

The commands map onto distinct services rather than one monolith. eas build compiles and signs binaries in the cloud and manages app credentials. eas submit uploads to Google Play and App Store Connect. eas update pushes JavaScript and asset fixes with branches, channels, runtime versions, rollouts and rollbacks. eas workflow runs CI/CD jobs defined under .eas/workflows. eas deploy handles Expo Router and React Native web apps and API routes. eas metadata:push maintains store listings and is marked in preview. A second tier of commands covers project operations: eas env, eas credentials, eas device, eas channel. The data flow is consistent: the CLI reads your project configuration, talks to the EAS service over the network, and returns a build, a submission or an update record that also appears in the Expo dashboard.

Installing EAS CLI globally and running a first build

The README's quick start is three commands: install the CLI, log in to your Expo account, and link the project. The npm package is eas-cli and the install is global.

npm install --global eas-cli
eas login
eas init

After eas login you are authenticated against your Expo account, and eas init links the current directory to an EAS project. If you would rather not install globally, the README states that every command also works through npx, and gives this example:

npx eas-cli@latest build --platform ios

With the project linked, the three shipping commands from the quick start are build, submit and update. The build command takes a platform flag; the update command takes a branch and a message.

eas build --platform all
eas submit --platform all
eas update --branch production --message "Fix checkout crash"

The README says eas build compiles installable Android and iOS binaries in the cloud, eas submit sends the latest builds to Google Play and the App Store, and eas update pushes an over-the-air update to users. For a complete walkthrough the README points to the Create your first build page in the Expo documentation rather than reproducing the steps.

The version policy is the part most teams get wrong

EAS CLI is designed to be installed globally or run with npx, and the README states plainly that installing eas-cli into project dependencies is strongly discouraged because it can cause dependency conflicts that are difficult to debug. That is an unusual position for a Node CLI, and it is a deliberate one. The tool talks to a hosted service whose API changes over time, so the CLI and the service are versioned together in a way a lockfile cannot capture.

The supported way to constrain the version is the cli.version field in eas.json, which the README shows as a range rather than an exact pin:

{
  "cli": {
    "version": ">=21.0.0"
  },
  "build": {
  },
  "submit": {
  }
}

The README describes this as the way to enforce the eas-cli version for your project. Note the trade-off: a range permits any newer release, so a CI image that installs latest and a developer machine that installed months ago can both satisfy the constraint while running different code. If reproducibility matters more than currency, pin the CLI version in your CI image and keep eas.json as a floor.

Where EAS CLI is the wrong tool

The clearest boundary is the one the README draws itself: this is a client for EAS, a hosted service. There is no documented offline mode, and no documented path to run eas build against your own build infrastructure. Every command that matters here is a network call to Expo's servers. If your release process must stay inside your own network, or if your organisation will not upload source and signing credentials to a third party, the tool does not fit, regardless of how convenient the command set is.

The second boundary is project type. The README describes the target as Expo and React Native apps throughout. A plain React Native project without Expo configuration is not what the quick start assumes, and the walkthrough it links to is Expo's own setup guide.

A third caveat is preview status. The README marks eas metadata:push as in preview, so treating store listing management as a settled part of the pipeline is premature. Similarly, eas update supports rollouts and rollbacks, but the README does not document rollback semantics in detail, so the exact behaviour when a rollout is reverted has to come from the EAS Update documentation, not from this repository.

EAS CLI compared with the Expo CLI

The Expo CLI ships with the expo package and runs your development server, bundles JavaScript and manages the local project. EAS CLI is a separate global binary that talks to cloud services. The split is by responsibility: local development on one side, cloud build, submission, update and deployment on the other.

In practice you use both, and the difference shows up when something fails. A bundling error surfaces in the Expo CLI on your machine. A failed credentials match, a rejected provisioning profile or a store submission error surfaces through EAS CLI and the dashboard, because that is where the signing and upload actually happen. Teams that expect EAS CLI to replace the local toolchain for day-to-day development will be disappointed; teams that expect the Expo CLI to produce a signed store binary without a Mac will be disappointed in the other direction.

Maintenance, licence and the cost of staying current

The repository is not archived. The last push was on 2026-08-26, and the release history shows v22.0.0 on 2026-08-14, v22.2.0 on 2026-08-20 and v22.6.0 on 2026-08-26, so releases arrive close together and major versions move quickly. That cadence is the real upgrade cost. A range like >=21.0.0 in eas.json will happily accept v22.x, and the jump from v21 to v22 happened within the period covered by those releases, so a project that pins a floor and installs latest on every CI run is exposed to breaking changes without a code change of its own.

The root LICENSE file is MIT, and the README's badge links to it. The repository also contains LICENSE-BUSL and LICENSE-eas-build-job at the top level, which indicates that not every part of the tree is under the same terms as the CLI itself. Anyone redistributing or embedding parts of this repository should read those files rather than assume the MIT badge covers everything; this is a description of what is in the repository, not legal advice.

Editorial conclusion

Adopt EAS CLI if your app is an Expo or React Native project and you want signed binaries, store submissions and over-the-air updates driven from one terminal command set, whether on a laptop or in CI. Do not install it into project dependencies: the README states that this is strongly discouraged because it causes dependency conflicts that are difficult to debug, and it points to the cli.version field in eas.json as the way to pin a range instead. Before committing, verify three things: that your npm global prefix is writable, that the version range you put in eas.json matches the CLI you actually run, and which account the CLI is authenticated as, because eas login and eas account:view decide which project the next build is billed to.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes