expo-react-native-cicd builds Expo apps on GitHub Actions

The pipeline that stands in for a paid build plan

The project exists because of a bill. The README frames it as a free alternative to Expo EAS build plans, and the comparison table puts the saving in numbers: the EAS free plan allows 30 builds a month, production is listed at 99 dollars a month and priority at 299 dollars a month, while the proposal is that the GitHub Actions route costs nothing. The scope of the tool is narrower than the marketing implies, and the README is honest about the shape of it. Everything happens on GitHub's own infrastructure, and the flow is a code push into GitHub Actions, then dependency installation, then tests, then the build, then the upload of the artefact, then a success notification. The point is not to replace EAS as a product but to move the build step onto runners you may already be paying for, and to give the result somewhere specific to live.

The EAS CLI does the build, the workflow only orchestrates it

This is the detail that determines what the project really is. The pipeline spins up an Ubuntu runner with Node.js and the required tools, installs the project dependencies and the EAS CLI, runs the TypeScript, ESLint and Prettier checks, and then builds using the EAS CLI locally on the runner, uploading the artefacts to the chosen storage destination. So the compilation is still done by Expo's tooling, just invoked by a workflow you control rather than by a hosted EAS build. That distinction decides the cost argument, the credential handling and the amount of freedom you have over the pipeline shape. It also means the project is not a replacement for EAS in any sense beyond who hosts the runner. The README documents the whole path as a diagram, with the sequence from code push through to the success notification drawn out as an explicit graph:

graph LR
    A[Code Push] --> B[GitHub Actions]
    B --> C[Install Dependencies]
    C --> D[Run Tests]
    D --> E[Build APK/AAB]
    E --> F[Upload Artifacts]
    F --> G[Notify Success]

Two ways in, and both end in a workflow file you commit

The quick start offers two routes and they converge on the same artefact. The first is the interactive workflow generator on expobuilder.vercel.app, where you configure storage, build types and tests, copy the generated workflow file, save it as .github/workflows/react-native-cicd.yml in your repository, and add your EXPO_TOKEN under repository settings, Secrets and variables, Actions. The second route avoids the generator entirely and goes through the Actions tab in your repository, where you search for React Native Expo Builder, click Configure, commit the workflow, and add your Expo token in repository settings. Either way the output is a YAML workflow committed to your own repository, which is the point: the build definition is reviewable in a pull request like any other code. A push to the main branch then triggers automatic builds.

Three build formats and five places to put the result

The build types are named plainly. A development build is a debug APK for testing, a production APK is described as release-ready for sideloading, and a production AAB is the app bundle for Google Play Store. Storage is a separate axis, and this is where the project is more flexible than the hosted alternative. You can push to GitHub Releases for automatic versioned releases, to GitHub Artifacts with seven day retention on the free tier, to Google Drive with sharing, to Zoho Drive for enterprise storage, or to any rclone-supported custom destination. The trade-off that matters is retention. GitHub Artifacts are described as free but expire in seven days, while GitHub Releases keep a versioned history you can point a download link at. Choosing a Drive destination buys you long term storage but moves your build output to a third party account, which is a decision about where your binaries live rather than about the pipeline.

TypeScript, ESLint and Prettier run before anything is packaged

The quality checks are wired into the same run as the build, and they cover the three tools a TypeScript React Native project usually already has configured. Type checking is listed first, then ESLint for code quality and standards, then Prettier for formatting. Putting them ahead of the build means a pull request that breaks a type fails before anyone waits for an APK, which is the practical payoff of moving the pipeline to a system you already trigger on every change. Triggers are configurable in three ways: push events for automatic builds on code changes, pull requests for build verification, and manual dispatch for on-demand runs. The README does not document how long the checks take on your project, and the sample build output in the README shows illustrative timings per step rather than a benchmark, so treat any number you see there as an example of the format rather than a promise.

The generator writes the workflow, the repository keeps the parts

The top level layout explains what kind of project this is. There is a webapp directory for the generator, a standalone-workflow-generator.js script, a generate-workflows.sh shell script, examples/ holding sample workflow files such as generalized-workflow.yml, a github-release-draft-pr-workflow.yml and a zoho-drive-workflow.yml, and separate content/, docs/, integration-tests/, sample-apps/ and sample-config/ directories. The examples directory is the most useful thing for an adopter, because it shows the same pipeline pointed at different storage backends, and the zoho-drive-workflow.yml and github-release-draft-pr-workflow.yml names indicate the shapes that are not the default. The README also links to detailed documentation and a workflow generator under the same expobuilder.vercel.app host, and an example directory marked as not tested, which is a fair signal about how much to trust the samples without running them yourself.

MIT licensed, no releases, and a last push in May

The repository is MIT licensed, which covers both the workflow templates and the generator code, so you can adapt either without obligations beyond retaining the notice. Maintenance is the more significant caveat. The last push to the repository was on 2026-05-10 and there are no GitHub releases at all, so there is no tagged version to pin and no changelog to check when something changes. That matters more here than it would for a library, because the thing you are adopting is a workflow file that talks to a service whose own client, the EAS CLI, changes on its own schedule. The project also depends on hosted infrastructure that is outside its control, and the README notes that builds run on GitHub's secure infrastructure with Expo tokens stored in GitHub Secrets, so the security story rests on how carefully you set up the repository secret rather than on anything inside this repository. Reading the workflow file before you commit it is the only review you get.

Editorial conclusion

expo-react-native-cicd suits a team already on GitHub Actions that wants repeatable Android builds, a PR that fails on a type error, and artefacts it controls, and it suits a solo developer who wants to stop paying per build. It does not suit a project that needs iOS builds or EAS-managed signing and credentials, because the documented pipeline is Android only and it still relies on an Expo token and the EAS CLI. Before adopting, add EXPO_TOKEN as a repository secret rather than in the workflow file, read examples/generalized-workflow.yml to see the shape of the generated file, and check the storage destination you pick, since GitHub Artifacts are described as having seven day retention while GitHub Releases keep versioned builds.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. TanayK07/expo-react-native-cicd on GitHub