Faster Rust CI Jobs

July 2, 2026

Compiling Rust is slow out of the box. This becomes a problem in CI. One small change can kick off a 15+ minute CI job. This is not ideal from a cost or developer experience perspective. In this post I take a real workflow from roughly 26 minutes down to under 5 minutes and walk through each optimization.

Why Rust Behaves This Way

There are three areas that cause Rust to compile slowly:

Dependency Compilation
Project Compilation
Linking

Build times are particularly painful in Rust because it relies heavily on monomorphization. That sounds like a big scary word, but it isn’t. It means every time there is some generic type used in your Rust code, the compiler generates implementations for each concrete type.

…ok, maybe that is kind of advanced. If you don’t understand what that means, don’t worry about it; know that this is a lot of work, and you want to avoid it when you can.

Cargo’s default local caching behavior lets you avoid it when building locally.

In contrast, when a GitHub Actions runner starts, it is a clean slate. It downloads everything and does all three steps every time.

An Unoptimized CI Job

An unoptimized GitHub Actions workflow might look like this. The comments label six baseline behaviors. Each one gets addressed in the next section.

1
name: Unoptimized Rust CI
2

3
permissions:
4
  contents: read
5

6
on:
7
  push:
8
    branches:
9
      - main
10
  pull_request:
11
  workflow_dispatch:
12

13
jobs:
14
  validate:
15
    name: Validate (lint, test)
16
    runs-on: ubuntu-latest
17

18
    # Baseline #1 (Linker): no RUSTFLAGS override, so every link
19
    # step uses the default GNU ld.
20
    # Baseline #2 (Compiler Cache): no sccache, so every compilation
21
    # unit is rebuilt from scratch on every run.
22
    # Baseline #3 (Dependency Cache): no cache action, so all
23
    # dependencies are recompiled on every run.
24
    steps:
25
      - name: Checkout
26
        uses: actions/checkout@v6
27

28
      - name: Install Rust
29
        uses: dtolnay/rust-toolchain@stable
30

31
      - name: cargo fmt
32
        run: cargo fmt -- --check
33

34
      - name: cargo clippy
35
        run: cargo clippy --locked --all-targets --all-features -- -D warnings
36

37
      # Baseline #4 (Test Runner): plain `cargo test`, which runs test
38
      # binaries with less parallelism than nextest.
39
      - name: Run tests
40
        run: cargo test --locked --all-features
41

42
  build:
43
    name: Build (${{ matrix.target }})
44
    runs-on: ubuntu-latest
45
    needs: [ validate ]
46
    strategy:
47
      fail-fast: false
48
      matrix:
49
        target:
50
          - x86_64-unknown-linux-musl
51
          - aarch64-unknown-linux-musl
52

53
    steps:
54
      - name: Checkout
55
        uses: actions/checkout@v6
56

57
      - name: Install Rust
58
        uses: dtolnay/rust-toolchain@stable
59

60
      # Baseline #5 (Cross Compilation): `cargo install` compiles
61
      # the cross tool from source on every run before any project
62
      # code builds.
63
      - name: Install cross
64
        run: cargo install cross
65

66
      # Baseline #6 (Build Environment): cross runs the build inside
67
      # a Docker container that must be pulled first, once per matrix
68
      # target.
69
      - name: Build with cross
70
        run: cross build --release --locked --target ${{ matrix.target }}
71

72
      - name: Upload binary
73
        uses: actions/upload-artifact@v7
74
        with:
75
          name: rust_build_demo-${{ matrix.target }}
76
          path: target/${{ matrix.target }}/release/rust_build_demo

Step-by-Step Optimization

There are six areas where the job can be optimized.

Category	Unoptimized baseline	Optimized
#1 Linker	default GNU ld	mold linker via RUSTFLAGS
#2 Compiler Cache	no compiler cache, full rebuild every run	sccache with GHA backend
#3 Dependency Cache	no dependency cache, dependencies recompile every run	Swatinem/rust-cache
#4 Test Runner	plain cargo test	nextest via prebuilt binary
#5 Cross Compilation	cargo install cross compiled from source every run	cargo-zigbuild via prebuilt binary
#6 Build Environment	cross builds inside Docker containers it must pull first	Zig cross-linking on the host

#1 Linker

An alternative linker is a huge gain. Linking is the final, serial step of every build, and mold is dramatically faster at it than the default GNU ld. mold only supports Linux, so if you are developing locally on Mac or Windows you are stuck with the default linker. However, GitHub Actions runners are Linux, which allows mold to be used.

Enable mold with an environment variable and an apt package:

1
env:
2
  RUSTFLAGS: "-C link-arg=-fuse-ld=mold"
3

4
steps:
5
  - name: Install mold
6
    run: sudo apt-get update -y && sudo apt-get install -y mold

#2 Compiler Cache

Without a compiler cache, every run rebuilds every compilation unit from scratch. A solution to this is mozilla-actions/sccache-action, which wraps sccache. Setting RUSTC_WRAPPER routes every rustc invocation through sccache, and SCCACHE_GHA_ENABLED stores the results in the GitHub Actions cache. Compilation units that have not changed are fetched instead of rebuilt.

This is the barebones action setup:

1
env:
2
  SCCACHE_GHA_ENABLED: "true"
3
  RUSTC_WRAPPER: sccache
4

5
steps:
6
  - name: Configure sccache
7
    uses: mozilla-actions/sccache-action@v0.0.10

#3 Dependency Cache

Without a dependency cache, dependencies recompile every run (which, as we’ve established, is slow). A solution to this is Swatinem/rust-cache. It has sensible defaults. It fingerprints Cargo.lock and saves and restores ~/.cargo and the compiled dependencies in target/ between runs, so unchanged dependencies are never recompiled. It is important that you use the –locked flag for tools (e.g., clippy, nextest) or those tools will automatically regenerate the lockfile, which breaks caching.

rust-cache also composes well with sccache. It restores whole build directories keyed on your lockfile, while sccache catches individual compilation units when that key misses.

1
- name: Cache Rust dependencies
2
  uses: Swatinem/rust-cache@v2
3
  with:
4
    key: validation

#4 Test Runner

Plain cargo test runs each test binary one at a time. cargo-nextest runs every test in its own process and schedules them in parallel across binaries, which adds up as a test suite grows.

Just as important is how it gets installed. taiki-e/install-action downloads a prebuilt binary in about a second instead of compiling a tool from source with cargo install.

1
- name: Install cargo-nextest
2
  uses: taiki-e/install-action@nextest
3

4
- name: Run tests
5
  run: cargo nextest run --locked --all-features

#5 Cross Compilation

The unoptimized workflow runs cargo install cross, which compiles the cross tool from source on every run before a single line of project code builds. The replacement is cargo-zigbuild, installed as a prebuilt binary through the same install action as nextest.

1
- name: Install cargo-zigbuild
2
  uses: taiki-e/install-action@cargo-zigbuild

#6 Build Environment

cross runs each build inside a Docker container that the runner must pull first, once per matrix target. cargo-zigbuild takes a different approach. It drives an ordinary host-side cargo build and uses Zig as the cross-compiling C toolchain and linker. Both musl targets build on a plain x86_64 runner with no Docker images to pull, no QEMU, and no dedicated ARM hardware.

1
- name: Install Zig
2
  uses: mlugg/setup-zig@v2
3
  with:
4
    version: "0.15.1"
5

6
- name: Build with zigbuild
7
  run: cargo zigbuild --release --locked --target ${{ matrix.target }}

Full Optimized Example

Putting all six optimizations together:

1
name: Optimized Rust CI
2

3
permissions:
4
  contents: read
5

6
on:
7
  push:
8
    branches:
9
      - main
10
  pull_request:
11
  workflow_dispatch:
12

13
jobs:
14
  validate:
15
    name: Validate (lint, test)
16
    runs-on: ubuntu-latest
17
    env:
18
      # Optimization #1 (Linker): tell rustc to link with mold
19
      # instead of the default GNU ld. Linking is the final, serial
20
      # step of every build, and mold is dramatically faster at it.
21
      RUSTFLAGS: "-C link-arg=-fuse-ld=mold"
22
      # Optimization #2 (Compiler Cache): wrap every rustc invocation
23
      # with sccache and store the results in the GitHub Actions
24
      # cache, so compilation units that have not changed are fetched
25
      # instead of rebuilt.
26
      SCCACHE_GHA_ENABLED: "true"
27
      RUSTC_WRAPPER: sccache
28

29
    steps:
30
      - name: Checkout
31
        uses: actions/checkout@v6
32

33
      - name: Install Rust
34
        uses: dtolnay/rust-toolchain@stable
35

36
      # Optimization #1 (Linker): install the mold binary that the
37
      # RUSTFLAGS entry above points at.
38
      - name: Install mold
39
        run: sudo apt-get update -y && sudo apt-get install -y mold
40

41
      # Optimization #2 (Compiler Cache): install sccache and wire it
42
      # up to the GitHub Actions cache backend.
43
      - name: Configure sccache
44
        uses: mozilla-actions/sccache-action@v0.0.10
45

46
      # Optimization #3 (Dependency Cache): restore ~/.cargo and the
47
      # compiled dependencies in target/ between runs, so unchanged
48
      # dependencies are never recompiled.
49
      - name: Cache Rust dependencies
50
        uses: Swatinem/rust-cache@v2
51
        with:
52
          key: validation
53

54
      - name: cargo fmt
55
        run: cargo fmt -- --check
56

57
      - name: cargo clippy
58
        run: cargo clippy --locked --all-targets --all-features -- -D warnings
59

60
      # Optimization #4 (Test Runner): download a prebuilt
61
      # cargo-nextest binary instead of compiling a tool from source
62
      # with `cargo install`.
63
      - name: Install cargo-nextest
64
        uses: taiki-e/install-action@nextest
65

66
      # Optimization #4 (Test Runner): nextest runs each test in its
67
      # own process and schedules them in parallel more effectively
68
      # than plain `cargo test`.
69
      - name: Run tests
70
        run: cargo nextest run --locked --all-features
71

72
  build:
73
    name: Build (${{ matrix.target }})
74
    runs-on: ubuntu-latest
75
    needs: [ validate ]
76
    env:
77
      # Optimization #2 (Compiler Cache): sccache again, shared
78
      # across both matrix targets through the GitHub Actions cache.
79
      SCCACHE_GHA_ENABLED: "true"
80
      RUSTC_WRAPPER: sccache
81
    strategy:
82
      fail-fast: false
83
      matrix:
84
        target:
85
          - x86_64-unknown-linux-musl
86
          - aarch64-unknown-linux-musl
87

88
    steps:
89
      - name: Checkout
90
        uses: actions/checkout@v6
91

92
      - name: Install Rust
93
        uses: dtolnay/rust-toolchain@stable
94
        with:
95
          targets: ${{ matrix.target }}
96

97
      # Optimization #6 (Build Environment): Zig provides the
98
      # cross-compiling C toolchain and linker directly on the host
99
      # runner. Both musl targets build on a plain x86_64 runner with
100
      # no Docker images to pull, no QEMU, and no dedicated ARM
101
      # hardware.
102
      - name: Install Zig
103
        uses: mlugg/setup-zig@v2
104
        with:
105
          version: "0.15.1"
106

107
      # Optimization #2 (Compiler Cache): see the validate job.
108
      - name: Configure sccache
109
        uses: mozilla-actions/sccache-action@v0.0.10
110

111
      # Optimization #3 (Dependency Cache): keyed per target so each
112
      # matrix leg restores its own compiled dependencies.
113
      - name: Cache Rust dependencies
114
        uses: Swatinem/rust-cache@v2
115
        with:
116
          key: ${{ matrix.target }}
117

118
      # Optimization #5 (Cross Compilation): download a prebuilt
119
      # cargo-zigbuild binary. The unoptimized workflow compiles its
120
      # cross tool from source with `cargo install` on every run.
121
      - name: Install cargo-zigbuild
122
        uses: taiki-e/install-action@cargo-zigbuild
123

124
      # Optimizations #5 and #6: cargo-zigbuild drives an ordinary
125
      # host-side cargo build and uses Zig as the cross-linker,
126
      # replacing the Docker-based `cross build` from the unoptimized
127
      # workflow.
128
      - name: Build with zigbuild
129
        run: cargo zigbuild --release --locked --target ${{ matrix.target }}
130

131
      - name: Upload binary
132
        uses: actions/upload-artifact@v7
133
        with:
134
          name: rust_build_demo-${{ matrix.target }}
135
          path: target/${{ matrix.target }}/release/rust_build_demo

The Results

Both workflows run the same lint, test, and cross-compile work on the same project. Here is the unoptimized run:

Unoptimized workflow run taking 11m 36s to validate and up to 14m 50s per build

And the optimized run:

Optimized workflow run taking 1m 27s to validate and about 3m per build

Job	Unoptimized	Optimized
Validate (lint, test)	11m 36s	1m 27s
Build (x86_64 musl)	13m 20s	2m 20s
Build (aarch64 musl)	14m 50s	3m 2s

Because the build matrix runs in parallel after validation, end-to-end wall clock time drops from roughly 26 minutes to about 4 and a half. The step-level numbers in the validate job are even more dramatic.

Side-by-side validate jobs showing clippy dropping from 5m 47s to 3s and tests from 5m 34s to 3s

To be fair about attribution, the clippy and test steps owe most of that speedup to the caches, since the compilation they used to do is already done. mold and nextest keep the remaining work fast, and they matter more as a project and its test suite grow.

The Caveats

Caching has limits, and it is worth knowing them before you rely on these numbers.

The optimized timings above are warm-cache runs. The first run after a change to Cargo.lock breaks the dependency cache and must re-prime it, so that run will look a lot more like the unoptimized one.
GitHub Actions has a 10GB cache limit per repository. A massive dependency tree, or many matrix targets each with their own cache key, can evict entries and quietly hand you cold builds.
mold only helps on Linux runners. If your CI runs on macOS or Windows, the linker row of the table does not apply.
cross is not a bad tool. It exists to provide reproducible cross-compilation environments, and if you need its container-level control, the Docker cost may be worth it. For plain musl targets, Zig does the same job faster.

Wrap-up

None of these changes touched the application code.

Six workflow-level swaps took the same pipeline from roughly 26 minutes to under 5.

If you only take one thing from this post, add Swatinem/rust-cache and sccache to your workflow. Those two lines of YAML are where most of the minutes go.

The workflows were run in ethanhann/rust_build_demo.