Monorail reads the real dependency graph of your monorepo, runs only the tasks a change can actually affect, and restores everything else from a cache your whole team shares. Eighteen-minute pipelines collapse to seconds — on every laptop, in every CI run, for every developer.
$ monorail run build test lint --affected
→ diff vs origin/main: 1 file in packages/checkout
→ graph: 214 tasks · 41 packages · 6 affected
✓ ui-kit#build CACHE HIT remote 0.4s
✓ analytics#build CACHE HIT remote 0.3s
✓ payments#test CACHE HIT local 0.0s
· 205 tasks CACHE HIT replayed —
▶ checkout#build RUN 6.2s
▶ checkout#test RUN 4.1s
208 / 214 cached (97.2%) ran 6 of 214
done in 11.3s · cold build: 18m 02s
↳ cache shared with 38 teammates + CI
$ _Platform teams who stopped waiting on the build
Monorail derives the smallest correct set of work for every change from the dependency graph that's already in your code — not a hand-maintained list of paths that quietly drifts out of date.
Monorail walks the dependency graph out from each changed file and runs only what that change can reach — the touched package plus everything downstream of it. Edit one shared util and it rebuilds the eleven packages that import it, and not the other thirty. The end of `build everything` because nobody trusts the path filters.
Each task is hashed from its inputs, env, and toolchain version. Same hash, same output — restored in milliseconds, never recomputed.
Independent tasks fan out across every core and every CI agent at once, while the scheduler holds back anything whose inputs aren't ready yet.
When a test passes and fails on byte-identical inputs, Monorail flags it, isolates it from your signal, and names the commit that made it flaky.
Every artifact ships with a signed record of the exact inputs and commands that produced it — auditable, replayable, tamper-evident.
What lands in the first week
A one-line change to the checkout package, executed against a 214-task graph. This is what Monorail decided to do — and skip.
git diff against origin/main returns one changed file. Monorail loads the cached task graph and marks the checkout package and its dependents as affected — six tasks in all.
Source, dependency outputs, env, and toolchain fold into one cache key per task. Two hundred and eight keys match an artifact that already exists, on a laptop or in CI, somewhere on the team.
208 tasks stream back from the remote cache — logs, outputs, and exit codes intact — in under half a second each. Nothing rebuilds. Nothing is recomputed.
checkout#build and checkout#test, plus the four targets downstream of them, run in graph order across available cores. Total wall time: 11.3 seconds against a cold-build cost of 18 minutes.
When CI builds a task, your laptop gets it for free. When a teammate runs the tests, you skip them. One artifact, computed once, reused everywhere — across machines, branches, and pipelines.
Laptops, CI runners, and ephemeral preview environments all read and write the same cache. The first run anywhere warms it for everyone after.
Wrap the Nx, Turborepo, Bazel, or npm targets you already have. Monorail caches the tasks as they stand — no rewrite, no migration project to staff.
Run the cache on Monorail Cloud, or point it at your own S3, R2, or GCS. Your artifacts never leave your account unless you want them to.
Hand heavy compiles to a managed build farm and stream results back. Your laptop fan stays quiet; the graph still runs in the right order.
“Our monorepo CI was at 22 minutes and climbing one task per sprint. We put Monorail in front of our existing targets on a Friday; Monday's pipelines averaged under two. We didn't touch a single build script to do it.”
“The shared cache is the part nobody believes until it happens to them. A teammate's CI run warmed my laptop — I pulled the branch, ran the app, and it was just there. Zero rebuilds, no waiting.”
“We were a quarter into a Bazel migration nobody had asked for. Monorail handed us most of the caching wins on the scripts we already had, in an afternoon. We closed the migration epic the next standup.”
Local caching is free forever. You pay for the shared remote cache and remote execution — priced per developer, never per build minute, so the faster Monorail makes you, the less each build costs.
Local caching and public repositories.
One fast cache, shared by the whole team.
Large monorepos and regulated fleets.
No. Monorail wraps the task runner you already use. Point it at your existing build, test, and lint targets and it starts hashing inputs and caching outputs on the next run — no rewrite, no new build language to learn. Most teams keep their current setup and gain shared caching and affected-only execution on top of it.
Monorail derives the dependency graph from your real import statements, package manifests, and config files — not a hand-maintained path filter that drifts out of date. Each cache key folds in a task's source, its dependencies' outputs, the toolchain version, and the env that matters. Change anything load-bearing and the hash changes, so a stale or wrong cache hit can't happen by construction.
Yes, and the trust is structural. Caching is content-addressed: a task is only restored when every input hashes identically, so you can never receive a result built from different code. Entries are integrity-checked on restore, and Enterprise adds signed SLSA provenance so you can prove exactly which inputs and commands produced any artifact.
On Monorail Cloud by default, or in your own S3, R2, or GCS bucket if you'd rather keep everything inside your account. Enterprise can run the entire cache and build farm within your VPC. Either way artifacts are encrypted in transit and at rest, and you can purge any key on demand.
Nothing beyond your seat. We price per developer — never per build minute or per gigabyte stored — so a pipeline that drops from 18 minutes to 11 seconds costs exactly what it did before. The savings are entirely yours.
The first run warms the cache; the second run is fast. Most teams install Monorail, run CI twice, and watch pipeline time fall by an order of magnitude the same afternoon — no graph to hand-author, no week-long config project to schedule.
Install the CLI, wrap the tasks you already have, and run your pipeline twice. The second run makes the case better than we can.