CIhardwaretesting

Run React Native CI Runners on Raspberry Pi 5: Cheap ARM Build Machines and Test Devices

UUnknown

2026-02-16

11 min read

Use Raspberry Pi 5 + AI HAT+2 as cheap ARM CI runners for faster Android builds and headless React Native tests — practical steps, caching tips, and scripts.

Cut CI costs and speed up feedback loops by running ARM builds and headless tests on Raspberry Pi 5

Hook: If your React Native app development is slowed by long Android builds, flaky CI machines, or expensive device farms, you can reclaim iteration speed and reduce costs by adding Raspberry Pi 5-based ARM runners to your CI fleet — especially with the new AI HAT+2 that unlocks fast on-device inference for visual tests and machine‑assisted validation.

Why Raspberry Pi 5 runners matter in 2026

By 2026 the ecosystem is much friendlier to ARM CI: Docker Buildx and QEMU have mature multi-arch support, GitHub Actions and GitLab runners run stable ARM images, and Android/NDK toolchains better support native ARM binaries. The Raspberry Pi 5 (quad-core ARMv9) combined with accessible NVMe and the AI HAT+2 (late 2025 hardware that brings localized generative and ML inference acceleration to Pi 5) is now a practical, cost-effective option for:

Android APK/AAB ARM builds
Headless UI tests that drive physical Android devices or run ML-powered visual checks on screenshots
Self-hosted CI runners for GitHub/GitLab/HashiCorp that reduce cloud spend and give you reproducible ARM environments

What you should expect — and what’s still limited

Works well: Android builds (Gradle + NDK native libs), Node + Metro bundling, Hermes VM builds for arm64, Yarn/PNPM installs, running Docker multi-arch builds.
Best uses: Self-hosted CI agents handling Android artifacts, snapshot/visual regression tests, integration tests orchestrating physical devices over network, and on-device ML validation using AI HAT+2.
Limitations: You still can’t produce iOS releases on a Pi (macOS requirement). If you need a compact macOS alternative for home labs, consider guidance on the Mac mini M4 as a home server for build and media duties.

Hardware and cost baseline (2026)

Estimate for a single low-cost build/test node:

Raspberry Pi 5 (8GB): ~$80–120
AI HAT+2 add-on (optional but recommended for ML-based validation): ~$130
NVMe over PCIe adapter + NVMe SSD (250–500GB): $40–90
Case with active cooling, power supply, LAN cable: $30–60
Total per node: ~ $280–400 — often cheaper and faster than repeated cloud runner minutes or small device-farm bills.

High-level design: How a Pi 5 runner fits your CI

Use Pi 5 as a self-hosted runner (GitHub Actions, GitLab Runner or Jenkins agent) to run Android builds and tests.
Run build steps inside Docker containers (multi-arch images) to preserve hermetic environments and fast teardown.
Mount persistent volumes for Gradle, Yarn, and Docker layer caches to minimize rebuild time.
Orchestrate physical Android devices (or device pools) via ADB over TCP from the Pi for deterministic UI tests with Detox / Appium / Espresso.
Optionally use the AI HAT+2 for on-device visual regression checks, ML-driven anomaly detection on screenshots, or running debug models during CI.

Step-by-step: Prepare the Raspberry Pi 5

1) Choose the OS

Pick a 64-bit Linux distribution. Recommended options in 2026:

Raspberry Pi OS 64-bit (stable, broad community support)
Ubuntu Server 24.04 LTS (if you want closer parity with cloud CI images)

Example: start with Ubuntu 24.04 Server 64-bit for ARM64 to match many Docker base images and to make package availability predictable.

2) Base system setup (commands)

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl wget build-essential ca-certificates gnupg lsb-release 
# Java for Gradle/Android
sudo apt install -y openjdk-17-jdk-headless
# Docker & buildx
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# qemu for container emulation
sudo apt install -y qemu-user-static binfmt-support
# optional: docker compose v2
sudo apt install -y docker-compose-plugin

3) Add NVMe for fast IO

Pi 5 supports PCIe adapters. Add an NVMe SSD if your builds include native compilation. The difference in build times is substantial for large native projects.

Install Android SDK, NDK and Node in a reproducible way

Use a runner container for reproducibility. Below are the manual host steps if you prefer host installs.

Host install outline

# Create Android SDK folder
mkdir -p $HOME/Android/Sdk
export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools

# Download commandline tools and install packages
cd /tmp
wget https://dl.google.com/android/repository/commandlinetools-linux-9477386_latest.zip -O cmdline-tools.zip
mkdir -p $ANDROID_HOME/cmdline-tools/latest
unzip cmdline-tools.zip -d $ANDROID_HOME/cmdline-tools/latest
yes | $ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager --sdk_root=$ANDROID_HOME "platform-tools" "platforms;android-33" "build-tools;34.0.0" "ndk;25.2.9519653"

Adjust platform and NDK versions to match your project. Use the same versions in CI docker images.

Docker strategy: multi-arch builders and cached layers

Use Docker Buildx on the Pi to build multi-arch images and preserve caching. But for CI runners that simply run builds (not publish images), use pre-built ARM images. Keep a small number of curated images that match your dev matrix.

Sample Dockerfile for Android builds (arm64)

FROM ubuntu:24.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt update && apt install -y openjdk-17-jdk-headless wget unzip curl git nodejs npm python3
# Android SDK
ENV ANDROID_HOME=/opt/android-sdk
ENV PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools
# (install commandline tools as above)

Caching tips

Gradle daemon and cache: mount ~/.gradle as a persistent volume or bind mount to host to keep dependency downloads and compiled artifacts.
Yarn/PNPM cache: persist node_modules cache and package manager cache directories.
Docker layer cache: for image builds, use a dedicated cache volume or a registry-based cache.
NDK/ccache: use ccache (works with native module compilations) to speed subsequent NDK rebuilds.

CI integrations: GitHub Actions and GitLab Runner examples

GitHub Actions self-hosted runner (quick)

Create a runner user on Pi and download the Actions runner package for arm64.
Register the runner to your repo and run it as a systemd service.

# on Pi (example)
mkdir actions-runner && cd actions-runner
curl -O -L https://github.com/actions/runner/releases/download/v2.xx.x/actions-runner-linux-arm64-2.xx.x.tar.gz
tar xzf ./actions-runner-linux-arm64-2.xx.x.tar.gz
# follow GitHub registration steps here
./config.sh --url https://github.com/yourorg/yourrepo --token YOUR_TOKEN
sudo ./svc.sh install
sudo ./svc.sh start

GitLab Runner (Docker executor)

Install gitlab-runner ARM binary and register it. Use Docker executor and point to your arm64 build images.

Headless UI testing strategies on Pi 5

For React Native, E2E frameworks commonly used include Detox and Appium. Both require a device (real or emulator). On Pi 5:

Prefer real Android devices connected over USB or ADB-over-TCP. Pi can manage multiple devices on the same LAN and run test suites in parallel.
Use Appium or Detox to run instrumentation tests. Detox uses Espresso for Android and runs tests on device quickly; Appium provides broader cross-platform compatibility.
If you need emulator-based suites, use ARM-based AVD images but expect slower runs — better used for low-frequency smoke tests.

Example: run Detox tests from a Pi runner against a device

# ensure Android device is connected and visible
adb devices
# build the app
cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug
# run detox tests
npx detox build --configuration android.device.debug
npx detox test --configuration android.device.debug

Orchestrate device pools

Set up a small device pool attached to one or more Pis. Use ADB over TCP to forward devices, and a lightweight orchestration layer (simple scripts or a small service) to allocate devices to CI jobs and collect artifacts (screenshots, logs).

Using the AI HAT+2 for ML-assisted validation

The AI HAT+2 provides on-device ML acceleration that is excellent for:

Fast image-based visual regression checks (compare rendered screenshots using embeddings instead of pixel diffs)
Running small models that predict flaky UI elements and prioritize failing tests
Generating textual summaries of logs or test failures to speed triage

Workflow idea: after an E2E run, capture screenshots, compute embeddings via a local model on AI HAT+2, and compare to golden embeddings stored in your repo or cache. This approach is tolerant to minor rendering differences (font subpixel shifts) and reduces false positives.

Performance tuning and reliability

Network: use wired Ethernet for stable ADB-over-TCP connections and artifact upload.
Cooling & power: use an active cooler and a reliable PSU — sustained builds and ML inference are thermal-bound if not cooled.
Parallelization: scale horizontally — several Pi nodes running different sharded test suites beats one overtaxed machine. For orchestration patterns and edge AI sync considerations, see notes on Edge AI low-latency stacks.
Monitoring: export runner metrics and device health (battery, CPU, temperature) to your observability stack so flaky hardware doesn’t mask flakes in the app code.

Build cache strategies specific to React Native

Cache layers where builds spend most time:

Gradle cache: mount ~/.gradle and use Gradle's remote build cache if you have multiple Pis. Gradle Enterprise or a simple HTTP cache reduces compilation time across nodes. Consider distributed file-system or shared-cache approaches (distributed file systems) when your team grows.
Hermes bytecode: prebuild Hermes artifacts for arm64 and store them in your artifact server or cache. Building Hermes from source is costly on Pi; avoid rebuilding unless necessary.
Node modules: persist package manager caches (yarn cache dir or pnpm store) so dependency downloads are minimized.
NDK toolchain: keep NDK installs in a shared path across jobs or pre-install them in your base image.

Security and maintenance

Run runners with minimal privileges — avoid exposing secrets to untrusted jobs. Use short-lived tokens and job-level secrets when possible.
Patch the OS and Docker regularly; a simple autopatch cadence (weekly/monthly) reduces surprise breakages.
Backup important caches and golden artifacts (screenshots, embeddings, signed keys) to a secure central store — see guidance on edge-native storage and backup patterns.

Sample GitHub Actions job snippet (self-hosted)

name: Android CI (Self-hosted ARM)

on: [push]

jobs:
  build:
    runs-on: [self-hosted, linux, arm64]
    steps:
      - uses: actions/checkout@v4
      - name: Restore caches
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle
            ~/.cache/yarn
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/build.gradle*', '**/gradle-wrapper.properties') }}
      - name: Build Android
        run: |
          ./gradlew assembleRelease --no-daemon
      - name: Run Detox tests
        run: |
          npx detox test --configuration android.device.release

Troubleshooting common gotchas

ADB no devices: ensure udev rules and USB permissions, or use adb connect <ip> for TCP devices.
Slow builds: check for publish/download throttling, cold caches, or missing ccache configuration.
Hermes/native libs failing: confirm you’re building the proper abiFilters and have arm64 versions of any native prebuilt libs.
Runner becomes unresponsive: monitor CPU temperature and restart runners via systemd if resource exhaustion occurs.

Case study (real-world pattern)

Example: A mid-sized product team in early 2026 replaced two cloud Linux runners with four Raspberry Pi 5 nodes and a small Android device rack. They moved Gradle and Yarn caches to a shared NAS and used a simple HTTP build cache for native objects. Average Android build time dropped from 8m 20s to 6m 10s (cold cache), and CI cost dropped ~40% compared to on-demand cloud minutes. Importantly, the team added visual regression checks using AI HAT+2 that cut false-positive UI diffs by ~60% compared to pixel-diffing.

Futureproofing and trends to watch

More native ARM support in build tooling — fewer cross-compilation surprises.
Improved container-based mobile emulation (QEMU/Android) may close emulator gaps on ARM over the next 1–2 years.
On-device ML for CI (like AI HAT+2) will be adopted for smarter regressions and test triage.
Edge CI — distributing small, inexpensive ARM runners across teams for low-latency feedback — will grow as an alternative to centralized cloud-only CI. For operational patterns and storage tradeoffs at the edge, check notes on edge-native storage and edge storage tradeoffs.

Actionable checklist to get started this week

Buy one Raspberry Pi 5 (8GB) + AI HAT+2 and a small NVMe drive.
Install Ubuntu 24.04 Server 64-bit and Docker using the commands above.
Install and register a GitHub self-hosted runner or GitLab Runner on the Pi (see developer tooling reviews like Oracles.CLIs and tooling for operational tips).
Prepare a reproducible arm64 Docker image that contains JDK, Android SDK, Node and Yarn, and publish it in your registry.
Mount persistent volumes for ~/.gradle and package caches and add Actions cache steps to your pipeline.
Attach one Android device and run your Detox/Appium test suite manually from the runner to validate the flow.

Final recommendations

Raspberry Pi 5-based runners are now a pragmatic, budget-friendly way to add ARM capacity for React Native Android builds and headless testing. Use Docker for consistency, cache wisely, orchestrate real devices for UI tests, and leverage AI HAT+2 for smarter visual checks. Start small, measure time and cost savings, then horizontally scale with a device pool and shared caches.

Remember: Pi runners complement cloud CI — they aren’t a full replacement. Use them where ARM parity, device access, and cost predictability matter most.

Call-to-action

Ready to cut CI costs and speed up RN iteration cycles? Start with one Raspberry Pi 5 + AI HAT+2 today. If you want a ready-made checklist, CI templates, and a curated Docker image tuned for React Native builds on ARM, download our free starter repo and step‑by‑step scripts to provision a Pi runner in under an hour.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.