React Native CI/CD for OTA Updates: Automate, Test & Roll Out With Stallion

OTA releases should not depend on someone manually uploading a bundle after every merge.

With React Native Stallion, your CI pipeline can publish a bundle, promote the exact artifact you tested, configure rollout percentage, and control whether the release is mandatory.

Stallion also includes an in-app testing workflow that lets authorized testers switch between published OTA releases without creating a new native build for every JavaScript change.

This guide shows how to connect Stallion to CI/CD and build a workflow like:

Code merge → Publish → Test → Promote → Roll out

Why Automate OTA Releases?

A manual OTA workflow creates repetitive work:

1. Build or prepare the update.
2. Upload the bundle.
3. Select the target app version.
4. Configure the release.
5. Ask QA to test it.
6. Change the rollout percentage.
7. Monitor the release.

A CI/CD pipeline can automate the repetitive parts while keeping production release decisions behind the approval gates that make sense for your team.

You can trigger publishing from a merge, release branch, tag, manual approval, or another deployment event depending on your release process.

A Production-Ready OTA CI/CD Workflow

A typical Stallion workflow can be split into four stages:

1. Publish

CI generates and publishes the OTA bundle.

2. Test

QA validates the published artifact using Stallion Testing.

3. Promote

The exact bundle hash that passed testing is promoted to the target app version.

4. Roll out

The release is gradually exposed to users using rollout controls.

This gives teams a repeatable path:

Publish → Test → Promote → Roll out

The same published artifact can move through the release process without rebuilding the JavaScript bundle between QA and production.

Automate Releases With CI Tokens

Stallion supports CI tokens designed for automated workflows.

Store the token in your CI provider's secret manager rather than committing it to the repository or exposing it in source control.

Use the narrowest available credential scope for the workflow, and rotate or revoke the token if it is exposed.

Step 1: Generate a CI Token

From the Stallion Console:

1. Go to Project Settings.
2. Open Access Tokens.
3. Generate a CI Token.

Step 2: Store the Token as a CI/CD Secret

Store the token in your CI provider's encrypted secret store, such as GitHub Secrets, Bitrise Secrets, or the equivalent in your CI platform.

For GitHub Actions, for example, create:

STALLION_CI_TOKEN

You can also store the project ID as a CI secret when you do not want environment-specific identifiers in the workflow.

Step 3: Use the Token From the CLI

npx stallion publish-bundle \
  --upload-path=org-name/project-name/bucket \
  --platform=android \
  --release-note="your release notes" \
  --ci-token="$STALLION_CI_TOKEN"

The exact upload path and platform values depend on your Stallion project and release setup.

Publish First, Release Later

One of the useful patterns in Stallion's CI/CD workflow is separating artifact publishing from production release.

Publishing uploads the bundle and gives you a bundle hash.

You can then validate that exact artifact before promoting it to a target app version.

Once you're ready, the pipeline can release that hash and configure its rollout percentage.

This creates a workflow like:

Build → Publish → QA → Promote → Roll out

You do not need to rebuild the JavaScript bundle between QA and production. The same published artifact can move through the release process.

Publishing a Bundle

stallion publish-bundle \
  --upload-path=orgname/project-name/bucket-name \
  --platform=android \
  --release-note="Your release note here" \
  --ci-token="$STALLION_CI_TOKEN"

Promoting a Bundle

stallion release-bundle \
  --project-id="$STALLION_PROJECT_ID" \
  --hash="$BUNDLE_HASH" \
  --app-version="$TARGET_APP_VERSION" \
  --release-note="Your release note" \
  --ci-token="$STALLION_CI_TOKEN"

Updating a Release

stallion update-release \
  --project-id="$STALLION_PROJECT_ID" \
  --hash="$BUNDLE_HASH" \
  --release-note="Updated release note" \
  --rollout-percent="$ROLLOUT_PERCENT" \
  --is-mandatory="$IS_MANDATORY" \
  --ci-token="$STALLION_CI_TOKEN"

Automate OTA Publishing With GitHub Actions

If your team already uses GitHub Actions, OTA publishing can be another step in your existing release workflow.

The example below publishes an OTA bundle after changes reach main. Your team can adapt the trigger to use tags, release branches, manual approvals, or another deployment event.

name: Publish OTA with Stallion

on:
  push:
    branches:
      - main

jobs:
  publish:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v6

      - name: Setup Node.js
        uses: actions/setup-node@v6
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Publish OTA Update with Stallion
        env:
          STALLION_CI_TOKEN: ${{ secrets.STALLION_CI_TOKEN }}
          STALLION_PROJECT_ID: ${{ secrets.STALLION_PROJECT_ID }}
        run: |
          COMMIT_MSG=$(git log -1 --pretty=format:"%s")
          echo "Publishing with commit message: $COMMIT_MSG"

          npx stallion publish-bundle \
            --upload-path=my-org/my-project/prod \
            --platform=android \
            --release-note="$COMMIT_MSG" \
            --ci-token="$STALLION_CI_TOKEN"

Store your CI token as a GitHub secret named STALLION_CI_TOKEN.

If your workflow also promotes releases automatically, keep the project ID and other environment-specific values in CI secrets or environment configuration rather than hard-coding them into the repository.

Control Rollouts From CI/CD

Publishing an OTA artifact does not have to mean sending it to 100% of users immediately.

Stallion separates release promotion from rollout configuration, allowing your pipeline to control how quickly a release reaches users.

For example:

Publish → QA → Promote → 10% → Monitor → 50% → 100%

The rollout percentage can be updated through the CLI as confidence in the release increases.

This makes CI/CD more than an automated upload step. It becomes part of the release-control process.

Example rollout progression

# Start with a small rollout
stallion update-release \
  --project-id="$STALLION_PROJECT_ID" \
  --hash="$BUNDLE_HASH" \
  --rollout-percent=10 \
  --ci-token="$STALLION_CI_TOKEN"

# Increase after validation
stallion update-release \
  --project-id="$STALLION_PROJECT_ID" \
  --hash="$BUNDLE_HASH" \
  --rollout-percent=50 \
  --ci-token="$STALLION_CI_TOKEN"

# Complete the rollout
stallion update-release \
  --project-id="$STALLION_PROJECT_ID" \
  --hash="$BUNDLE_HASH" \
  --rollout-percent=100 \
  --ci-token="$STALLION_CI_TOKEN"

Use the rollout stages that match your team's risk tolerance. Critical fixes may need a different rollout strategy from routine UI changes.

Test OTA Releases Without Building a New Native App

Once a Stallion-enabled app build is installed on a tester's device, QA can switch between published OTA releases from the Stallion Testing modal.

That means a JavaScript change does not require another native build just to test the OTA release.

The native Stallion-enabled build is still required initially. After that, authorized testers can install and switch between compatible published OTA releases without creating another native distribution package for every JavaScript release.

Stallion's testing workflow is designed to let teams validate OTA updates in under 60 seconds.

Integrate the Stallion Testing Modal

import { useStallionModal } from "react-native-stallion";

const MyDebugScreen = () => {
  const { showModal } = useStallionModal();

  return <Button title="Open Stallion" onPress={showModal} />;
};

Restrict Testing With a Security PIN

Set a security PIN in the Stallion Console to restrict access to internal testers.

Authorized testers can open the Stallion modal, select an available OTA release, download it, and restart the app to validate the version.

The testing workflow is intended for a Stallion-enabled native application build. It does not replace the initial native build or app distribution process.

A Practical QA-to-Production Workflow

A team can combine the CI and testing workflows into a release pipeline like this:

Developer

Merge the JavaScript or TypeScript change.

CI

Publish the OTA artifact and capture its bundle hash.

QA

Use a Stallion-enabled app build to switch to the published release and validate it.

Release approval

Promote the exact bundle hash that passed QA to the target app version.

Controlled rollout

Start with a small percentage of users and increase the rollout after monitoring the release.

Recovery

If the release causes problems, use the available release and recovery controls to limit its impact and roll back when appropriate.

This avoids rebuilding the native application for every compatible JavaScript release while still giving the team control over the production rollout.

Secure Your CI/CD Pipeline

CI automation should never depend on credentials committed to source control.

Store your Stallion CI token in your CI provider's encrypted secret store and expose it only to the workflows that need it.

For additional OTA security, Stallion also supports bundle signing through the CLI, allowing bundles to be signed with a private key before publishing.

Good CI/CD security practices include:

• Store CI tokens in your provider's secret manager.
• Avoid printing credentials in workflow logs.
• Use the narrowest available credential scope.
• Rotate or revoke credentials if they are exposed.
• Keep production publishing behind the appropriate branch, environment, or approval gates.
• Separate development, staging, and production credentials where appropriate.

What This CI/CD Workflow Changes

Merge code without manual OTA uploads

Your existing CI pipeline can publish OTA artifacts as part of your release workflow, removing repetitive manual uploads.

Test without rebuilding for every JavaScript release

Once a Stallion-enabled native build is installed, authorized testers can switch between compatible published OTA releases without creating another native build for each JavaScript change.

Promote the exact artifact that passed QA

Publishing and releasing are separate steps, so the bundle tested by QA can be the same bundle promoted to production.

Control rollout from the pipeline

Your CI workflow can automate or gate rollout percentage, mandatory-update decisions, and other release actions according to your team's process.

Keep credentials out of source control

CI tokens remain in your CI provider's secret manager rather than being committed to the repository.

Works With Your Existing CI/CD Stack

Stallion CLI commands can be run from CI environments that support command-line workflows.

Common setups include:

• GitHub Actions
• Bitrise
• CircleCI
• Jenkins
• Codemagic
• Appcircle
• Other CI/CD systems that can run the Stallion CLI

The goal is not to replace your CI/CD platform. Stallion becomes another step in the release pipeline you already operate.

Expo and React Native CI/CD

If your application uses Expo, you can continue using Expo for development and native builds while using Stallion for OTA delivery.

Your CI workflow can build the native application with Expo and then use Stallion's CLI and release workflow for compatible OTA updates.

The Stallion-enabled native build still needs to be distributed through the appropriate app-store or testing channel before it can receive Stallion OTA updates.

This lets teams keep their existing application build workflow while using Stallion for patch-first OTA delivery and release controls.

Related Resources

• Release Automation Documentation →
• Stallion Testing Documentation →
• React Native Patch Updates →
• CodePush Migration Guide →
• Expo EAS Update Alternative →

Frequently Asked Questions

How do I automate React Native OTA updates with CI/CD?

Use the Stallion CLI from your existing CI/CD pipeline. A typical workflow publishes the bundle, captures its hash, validates the artifact, promotes it to the target app version, and then controls rollout percentage.

Does React Native Stallion support GitHub Actions?

Yes. Stallion CLI commands can be run from GitHub Actions workflows using a CI token stored in GitHub Secrets.

Can I use React Native Stallion with Bitrise?

Yes. Stallion CLI commands can be integrated into Bitrise workflows using a CI token stored in Bitrise's secret management system.

Does Stallion support other CI/CD platforms?

Yes. Any CI/CD environment that can run Stallion CLI commands can be integrated into the release workflow. Common setups include GitHub Actions, Bitrise, CircleCI, Jenkins, Codemagic, and Appcircle.

How do I secure CI tokens in my CI/CD pipeline?

Store CI tokens in your CI provider's encrypted secret manager. Do not commit them to source control or print them in workflow logs. Use the narrowest available credential scope and rotate or revoke exposed credentials.

What is the Stallion Testing Framework?

Stallion Testing provides an in-app workflow for authorized testers to switch between compatible published OTA releases from a Stallion-enabled native application. A security PIN can be configured to restrict access to internal testers.

Automate Your React Native OTA Releases

Your CI/CD pipeline should do more than upload an OTA bundle.

With Stallion, you can publish an artifact, test it, promote the exact version that passed QA, control its rollout, and recover when something goes wrong.

Keep your existing CI/CD platform. Add Stallion where your OTA release workflow needs it.

Get Started Free →

Read the Release Automation Documentation →