DEV Community: Kévin Huang

Cutting our CI time in half thanks to custom AWS runners

Kévin Huang — Tue, 21 Apr 2026 14:19:27 +0000

We moved our Nx monorepo from CircleCI to GitHub Actions on self-hosted AWS runners, tightened caching, and brought the full CI run from ~33 minutes down to ~15 minutes while owning cache and runner behavior end to end.

At Wecasa, our CI used to run on CircleCI. We wanted to consolidate on GitHub Actions and run jobs on self-hosted runners in AWS, with specs we control and costs we can optimize.

Our repo is a large Nx monorepo: each package is an app or library (SPAs, React Native / Expo mobile apps, etc.). Every push should run lint and tests through Nx, but we also needed fast feedback, reliable caching, and behavior that matches how developers work (branch pushes, master always green).

This post is a practical walkthrough: how we sized runners, provisioned them with Terraform, built a composite setup action for Yarn + Nx cache, parallelized test and lint, and tuned Jest to avoid OOMs on larger runners.

1) Runner specs: CircleCI vs our AWS runners

Before changing workflows, we analysed our current CI setup.

CircleCI (before)

Lint (medium runner): 2 vCPUs, 7.5 GB RAM
Tests (large runner): 4 vCPUs, 15 GB RAM

AWS self-hosted runners (after)

Lint (medium runner): 4 vCPUs, 7 GB RAM
Tests (large runner): 8 vCPUs, 15 GB RAM

The test job got twice the CPU on the large runner, which matters a lot for parallel Nx tasks and Jest workers. Lint stayed on a smaller machine with more cores than our old Circle medium tier, which helped wall-clock time for ESLint/TypeScript-style work.

2) Infrastructure: Terraform-provisioned GitHub Actions runners

We created the runners with Terraform and registered them as labels GitHub Actions can target (medium-runner, large-runner). That gives us repeatable infra, clear ownership, and an obvious place to evolve instance types or scaling later.

3) One composite action: Yarn, install, and Nx cache

Repeated setup (Corepack, Yarn cache, yarn install, env files for mobile, Nx restore) belonged in one composite action so every job stays consistent and DRY.

Rough responsibilities:

Validate the cache target (test vs lint) so we never restore the wrong Nx cache key by mistake.
Enable Corepack and resolve Yarn's cache directory.
Restore Yarn's global cache (actions/cache@v4) keyed on yarn.lock.
yarn install --immutable
Restore Nx cache only (actions/cache/restore@v4), we save Nx cache in each job’s workflow so we don’t double-save the same key from the composite action.

Splitting restore (composite) vs save (workflow) avoids competing writes and duplicate cache saves for the same key.

name: "Setup and run CI"
description: "Setup Yarn, restore Yarn cache and Nx cache"

inputs:
  nx-cache:
    description: "Which Nx cache to restore (test or lint)"
    required: true

runs:
  using: composite
  steps:
    - name: Validate nx-cache input
      run: |
        if [ "${{ inputs.nx-cache }}" != 'test' ] && [ "${{ inputs.nx-cache }}" != 'lint' ]; then
          echo "::error::nx-cache must be 'test' or 'lint', got: ${{ inputs.nx-cache }}"
          exit 1
        fi
      shell: bash

    - name: Setup Yarn (1/4) -> Enable corepack
      run: corepack enable
      shell: bash

    - name: Setup Yarn (2/4) -> Get yarn cache directory path
      id: yarn-cache-dir-path
      run: echo "dir=$(yarn config get cacheFolder)" >> $GITHUB_OUTPUT
      shell: bash

    - name: Setup Yarn (3/4) -> Retrieve global cache
      uses: actions/cache@v4
      id: yarn-cache
      with:
        path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
        key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
        restore-keys: |
          ${{ runner.os }}-yarn-

    - name: Setup Yarn (4/4) -> Install packages and copy env files
      run: yarn install --immutable
      shell: bash

    # Restore only; save is in workflow (test/lint job) to avoid duplicate save for same key
    - name: Restore Nx cache
      uses: actions/cache/restore@v4
      with:
        path: .nx
        key: nx-${{ runner.os }}-${{ inputs.nx-cache }}-${{ hashFiles('nx.json', 'yarn.lock') }}-${{ hashFiles('**/project.json') }}
        restore-keys: |
          nx-${{ runner.os }}-${{ inputs.nx-cache }}-${{ hashFiles('nx.json', 'yarn.lock') }}-

4) Workflow: concurrency, ECR Public, parallel test + lint

Triggers and concurrency

We run on every push. We use concurrency so that a new push on the same branch cancels an in-flight run. Except on master, where we always let CI complete (release / mainline stability).

name: CI • Test and Lint

on:
  push:
    branches:
      - "**" # all branches

concurrency:
  group: test-and-lint-${{ github.ref }}
  cancel-in-progress: ${{ github.ref != 'refs/heads/master' }} # Run CI everytime `master` branch is pushed

Docker image without Docker Hub rate limits

Jobs run in a Node container pulled from Amazon ECR Public (same family as docker.io/library/node), after a small job that logs in via AWS.

Parallel jobs

After ecr-login, test and lint run in parallel on large-runner and medium-runner respectively. Each calling the composite action with nx-cache: test or nx-cache: lint, then yarn ci:test / yarn ci:lint, and always saving the matching Nx cache.

Jest reports when Nx skips work

With Nx, if nothing relevant changed in a project, tests might not run, so no JUnit XML is produced. We still want the job summary to be meaningful when reports exist. After tests, we check for reports/**/*.xml (from jest-junit); only then we run dorny/test-reporter so we don’t fail the step when there’s nothing to publish.

Test job:

test:
  needs: ecr-login
  name: Test
  runs-on: large-runner
  env:
    TZ: Europe/Paris
  container:
    # Use ECR Public Gallery to avoid Docker Hub rate limits (same image as docker.io/library/node)
    # @see https://gallery.ecr.aws/docker/library/node
    image: public.ecr.aws/docker/library/node:20.17.0
  steps:
    - name: Checkout
      uses: actions/checkout@v4
      with:
        fetch-depth: 0

    - name: Setup
      uses: ./.github/actions/setup
      with:
        nx-cache: test

    - name: Run test
      id: run-test
      run: yarn ci:test

    - name: Save Nx cache (test)
      if: always()
      uses: actions/cache/save@v4
      with:
        path: .nx
        key: nx-${{ runner.os }}-test-${{ hashFiles('nx.json', 'yarn.lock') }}-${{ hashFiles('**/project.json') }}

    # Check if tests reports should be skipped because of NX cache and no changes in codebase
    - name: Check for test reports
      id: check_reports
      if: always()
      run: |
        if [ -d reports ] && [ -n "$(find reports -name '*.xml' -print -quit 2>/dev/null)" ]; then
          echo "exist=true" >> $GITHUB_OUTPUT
        else
          echo "exist=false" >> $GITHUB_OUTPUT
        fi

    - name: Publish test results to Job Summary
      if: always() && steps.check_reports.outputs.exist == 'true'
      uses: dorny/test-reporter@v2
      with:
        name: Jest Tests
        path: reports/*.xml
        reporter: jest-junit

Lint job:

lint:
  name: Lint
  needs: ecr-login
  runs-on: medium-runner
  env:
    TZ: Europe/Paris
  container:
    # Use ECR Public Gallery to avoid Docker Hub rate limits (same image as docker.io/library/node)
    # @see https://gallery.ecr.aws/docker/library/node
    image: public.ecr.aws/docker/library/node:20.17.0
  steps:
    - name: Checkout
      uses: actions/checkout@v4
      with:
        fetch-depth: 0

    - name: Setup
      uses: ./.github/actions/setup
      with:
        nx-cache: lint

    - name: Run lint
      id: run-lint
      run: yarn ci:lint

    - name: Save Nx cache (lint)
      if: always()
      uses: actions/cache/save@v4
      with:
        path: .nx
        key: nx-${{ runner.os }}-lint-${{ hashFiles('nx.json', 'yarn.lock') }}-${{ hashFiles('**/project.json') }}

5) Jest, parallelism, and Out Of Memory (OOM): capping `maxWorkers`

On Jest 29 we hit OOM when launching tests.

We added a small TypeScript helper used when invoking the CI’s test job (and lint where relevant). So that total parallelism stays bounded: we assume up to three test streams in parallel and divide CPU count so that each Jest process gets a sane --maxWorkers value.

import os from "node:os";

const CORES_COUNT = os.cpus().length;
const PARALLEL_TEST_COUNT = 3;
const MAX_WORKERS_COUNT_PER_TEST =
  Math.floor(CORES_COUNT / PARALLEL_TEST_COUNT) || 1;

We expect to revisit this after moving to Vitest or Jest 30, where defaults and memory behavior may change.

Conclusion

Migrating our CI was not only swapping CircleCI for GitHub Actions. It was aligning runner size, caching, and Jest concurrency with how Nx actually schedules work. We now own setup and cache behavior via a composite action and Terraform-managed runners. Which led to reduced costs and an improvement of the CI’s wall-clock from ~33 minutes to ~15 minutes.

Next iteration: keep tuning workers and task graphs as we modernize the test runner.

If you like monorepo and platform engineering notes like this, follow Wecasa and get in touch if you want to build this kind of stack with us.

Migrating Yarn 1 to 4 in an Nx Monorepo

Kévin Huang — Tue, 21 Apr 2026 14:19:14 +0000

With just one migration, we reduced the execution time of yarn install on our CI from ~110s to ~25s. While also removing legacy patching with postinstall and by also keeping behaviour close enough to Yarn 1 to ensure a safe migration.

At Wecasa, our frontend lives in a large Nx monorepo (web + mobile apps) and we were still running on Yarn 1.22.0. It worked well for a while, but at some point the dependency installation became a bottleneck on our CI. And our patch workflow (patch-package + postinstall-postinstall) was adding maintenance overhead a well.

So we decided to migrate to Yarn 4, but with one strict goal: minimize risk. Instead of changing everything at once, we focused on a compatibility-first setup (especially important because React Native / Expo still requires node_modules) and planned optimizations for later iterations.

1) Migration Strategy: Stability First, Optimization Later

We followed the official guide: Yarn migration guide , with a progressive approach:

corepack enable
yarn set version berry
yarn install

Key decision: keep behavior as close as possible to Yarn 1 during the first step.

That meant postponing advanced hoisting changes and avoiding Plug’n’Play for now.

Plug’n’Play makes Yarn resolve packages via a .pnp.cjs map instead of a full node_modules folder but not always compatible with every toolchain (e.g. React Native / Expo still require using typical node_modules install).

Our .yarnrc.yml:

nmHoistingLimits: none
nodeLinker: node-modules
patchFolder: .yarn/patches
yarnPath: .yarn/releases/yarn-4.12.0.cjs

Why this setup:

nodeLinker: node-modules keeps compatibility with React Native / Expo.
nmHoistingLimits: none avoids introducing too many resolution differences on day one.
patchFolder and yarnPath make Yarn behavior explicit and reproducible across environments.

As documentation by Yarn

A notable exception is React Native / Expo, which require using typical node_modules installs.

2) Lockfile and Repository Changes

After switching versions, we ran yarn install to regenerate the yarn.lock file with a Yarn 4 format while preserving dependency versions.

This gave us a clean, deterministic baseline before any deeper dependency cleanup.

We also updated git ignore rules by adding this file: .yarn/install-state.gz

As documented by Yarn , this file is only an optimization artifact and should not be committed.

.yarn/install-state.gz is an optimization file that you shouldn't ever have to commit. It simply stores the exact state of your project so that the next commands can boot without having to resolve your workspaces all over again.

3) Migrating Existing Patches from `patch-package` to Yarn Native Patches

Before migration, our patches lived under <root>/patches and were applied via postinstall scripts.

With Yarn 4, we moved to the native patch workflow, and new patches now live in .yarn/patches.

Step-by-step for each existing patch

Start an editable patch session:

yarn patch <package-name>

Move to the temporary folder shown in the command output:

cd <temp-folder>

Apply your existing patch file:

patch -p<number> < /absolute/path/to/patches/<package>.patch

Commit the patch back into Yarn:

yarn patch-commit --save <temp-folder>

About `-p<number>`

The -p value depends on how many path segments must be stripped from your patch paths.

Example patch path:

diff --git a/node_modules/@types/react/path/to/file.js

In this case, -p4 strips a/node_modules/@types/react, so paths match files in the temp patch directory.

4) What Changed in `package.json`

Once committed, dependencies patched by Yarn are rewritten like this:

- "my-package-name": "52.0.6",
+ "my-package-name": "patch:my-package-name@npm%3A52.0.6#~/.yarn/patches/my-package-name-npm-52.0.6-20053456a7.patch",

This removes the need for patch-package + postinstall patch execution and centralizes patch handling in Yarn itself.

5) Results and Next Iterations

Immediate gains after the migration:

CI install time dropped from ~110s to ~25s
patching workflow simplified (no more postinstall patch mechanism)
safer long-term setup with modern Yarn tooling

What we’ll iterate on next:

refine hoisting strategy (nmHoistingLimits)
audit dependency constraints and deduplication opportunities
progressively adopt more Yarn 4 capabilities where ecosystem compatibility allows

Conclusion

Migrating Yarn 1 to Yarn 4 in a large Nx monorepo can be low-risk if you prioritize compatibility first.

We got a 4x CI install speed-up and cleaner patch management in one pass, while keeping mobile compatibility intact.

If you enjoy pragmatic monorepo migration stories and performance wins, follow Wecasa’s engineering journey.

DEV Community: Kévin Huang

Cutting our CI time in half thanks to custom AWS runners

1) Runner specs: CircleCI vs our AWS runners

2) Infrastructure: Terraform-provisioned GitHub Actions runners

3) One composite action: Yarn, install, and Nx cache

4) Workflow: concurrency, ECR Public, parallel test + lint

Triggers and concurrency

Docker image without Docker Hub rate limits

Parallel jobs

Jest reports when Nx skips work

5) Jest, parallelism, and Out Of Memory (OOM): capping maxWorkers

Conclusion

Migrating Yarn 1 to 4 in an Nx Monorepo

1) Migration Strategy: Stability First, Optimization Later

2) Lockfile and Repository Changes

3) Migrating Existing Patches from patch-package to Yarn Native Patches

Step-by-step for each existing patch

About -p<number>

4) What Changed in package.json

5) Results and Next Iterations

Conclusion

5) Jest, parallelism, and Out Of Memory (OOM): capping `maxWorkers`

3) Migrating Existing Patches from `patch-package` to Yarn Native Patches

About `-p<number>`

4) What Changed in `package.json`