Monorepos with a shared remote cache

Let teams building overlapping subgraphs from the same sources reuse each other's results automatically.

The problem

In a monorepo, different teams build overlapping parts of the same dependency graph from the same source. Each developer and each CI lane recompiles shared libraries independently. The work is duplicated across the org because nothing shares the results — ninja has no notion of a cache that spans machines.

How rninja solves it

▸Stand up one async-nng remote cache endpoint and point developer machines and CI at it via RNINJA_REMOTE_URL.
▸Shared library actions are content-addressed, so whoever builds a subgraph first seeds it for everyone with identical inputs.
▸Fresh checkouts and first builds on new machines become mostly cached builds instead of full recompiles.
▸The local sled store still front-runs the remote, so repeat builds stay fast even offline.

// Shared cache lookup

$ rninja -C out //libs/core:all
[cache] local miss → remote hit  libs/core/allocator.o
[cache] local miss → remote hit  libs/core/arena.o
✓ pulled shared artifacts, no recompile

·rninja executes the build.ninja your generator emits — it works the same whether that file was written by CMake, GN, Meson, or by hand.
·The remote is a transport for content-addressed blobs; identical inputs across teams resolve to the same key with no coordination.

Questions

[+] Do all teams need the same generator?

They need to produce equivalent actions from equivalent inputs. rninja keys on the action content, not the generator, so CMake, GN, Meson, or hand-written ninja files interoperate as long as the actual commands and inputs match.

[+] Is the remote cache required?

No. It is opt-in. Without it, rninja still gives you the local content-addressed cache and the async scheduler on every machine.

Try it on this exact workload

Install rninja, point it at your existing build.ninja, and time it side by side. See the quickstart or browse other use cases.

Install rninja Compare tools