This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.

An introduction to EAS Workflows tutorial and the core concepts for setting up a CI/CD pipeline for Expo and React Native apps.

Building, testing, and delivering an Expo and React Native app is rarely a one-step process. Each code change goes through a similar flow of building for Android and iOS, running unit and end-to-end (E2E) tests, and handing it off to teammates, QA, or the app stores. Doing this on every commit gets tedious fast, and it's exactly the kind of work a CI/CD pipeline should handle for us.

By the end of this tutorial, every push to our Expo project builds, tests, or ships automatically. The service that makes this possible is EAS Workflows, a Continuous Integration (CI)/Continuous Delivery (CD) service from Expo Application Services (EAS) for Expo and React Native apps.

We define a workflow in a YAML file that lives in .eas/workflows/ at the root of our Expo project. Here is a complete example that builds an Android development build on every push to the main branch in a GitHub repository:

name: Build Android

on:
  push:
    branches: ['main']

jobs:
  build:
    type: build
    params:
      platform: android
      profile: development

That handful of lines is the entire workflow, and EAS handles the rest. We build on this pattern throughout the tutorial.

Why use EAS Workflows?

EAS Workflows runs Android, iOS, and web builds, publishes OTA updates, submits to app stores, and runs E2E tests with Maestro, all defined in YAML files like the example above. Because jobs run in a managed cloud environment, there is no build server for us to set up or maintain.

We can trigger workflows from GitHub events (push, pull request, tags, or labels), on a schedule (cron), or manually with EAS CLI.

Topics covered

The tutorial has three parts:

• Development. Create custom jobs, automate development builds with fingerprinting, and ship pull request (PR) preview updates for stakeholders.
• Testing and releasing. Run E2E tests with Maestro in a workflow, then create a production workflow that uses fingerprinting to choose between a native build and an OTA update.
• Extensions. Switch production triggers from branches to version tags and deploy web builds with EAS Hosting.

Concepts worth knowing first

Tip: Already familiar with EAS Build and EAS Update? Skip to the next section.

Before we create our first workflow, here are a few concepts worth knowing: