Chromium
Building Chromium with NativeLink as the Reclient backend — a worked example for the largest public consumer.
Chromium's build system shells out to Reclient, which speaks the Remote Execution API. Pointing it at a NativeLink cluster is a configuration change — no patches to the Chromium tree.
The Samsung Internet team runs this configuration in production for their browser fork; the same pattern works for upstream Chromium and any Chromium-based browser.
Prerequisites
- A NativeLink cluster reachable from your build machines. Cache-only is fine to start; remote execution drops build times further.
- Reclient installed and on
$PATH. Chromium'sgclient syncwill install it underbuildtools/. - The Chromium source checkout (
fetch chromium).
Configure Reclient
Reclient reads its server settings from environment variables. Add to your build shell:
export RBE_service=cas.nativelink.internal:50051
export RBE_instance=chromium
export RBE_use_application_default_credentials=false
export RBE_service_no_security=false # mTLS in production
export RBE_tls_client_auth_cert=/etc/nativelink/tls/client.crt
export RBE_tls_client_auth_key=/etc/nativelink/tls/client.key
export RBE_tls_ca_cert=/etc/nativelink/tls/ca.crtFor local development against a non-TLS NativeLink:
export RBE_service=localhost:50051
export RBE_instance=chromium
export RBE_service_no_security=trueGenerate Chromium build files
In your Chromium checkout:
gn gen out/Default --args='
use_remoteexec=true
use_goma=false
use_siso=false
reclient_cfg_dir="../../buildtools/reclient_cfgs/chromium-browser-clang"
'The use_remoteexec=true flag is the one that matters — it tells the
build to wrap every compile invocation with Reclient.
Start the reproxy daemon
Reclient uses a long-lived daemon (reproxy) that batches requests
to the RE-API server. Start it before invoking the build:
buildtools/reclient/bootstrap --re_proxy=buildtools/reclient/reproxyThe daemon stays up; bootstrap --shutdown shuts it down when
you're done.
Build
autoninja -C out/Default chromeWatch the build go. On a fresh cluster the first build will be mostly misses; subsequent builds hit the cache and run in a fraction of the time.
What good looks like
The Reclient stats endpoint reports cache statistics per build:
buildtools/reclient/reclient statsHealthy numbers on warm builds:
- Cache hit rate: 85-95% on incremental builds; 60-80% on full builds.
- Local fallback rate: under 1%. Higher means workers are rejecting actions (platform mismatch, capacity).
- Network errors: zero. Anything else is a problem.
Worker requirements
Chromium actions have specific platform requirements. Your worker config should advertise:
container_image: chromium-build-base:<version>OSFamily: linuxcpu_count: 8(minimum; 16+ recommended for link steps)
The
deployment-examples/chromium/
directory in the source tree has the worker config Samsung uses.
Troubleshooting
- All actions falling back to local. Likely a platform-property mismatch. Compare what Chromium is requesting (in the reclient log) against what your workers advertise.
- Cache writes succeed, reads always miss. Almost always a toolchain version mismatch between the action that wrote the cache and the one trying to read.
- Reproxy hangs on shutdown. Known issue —
reclient_cleanupfixes it.
What's next
- Persistent workers for the hot toolchain paths.
- Metrics — Chromium builds produce a lot of telemetry; have the dashboards ready.