NativeLink
Deployment examples

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's gclient sync will install it under buildtools/.
  • 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.crt

For local development against a non-TLS NativeLink:

export RBE_service=localhost:50051
export RBE_instance=chromium
export RBE_service_no_security=true

Generate 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/reproxy

The daemon stays up; bootstrap --shutdown shuts it down when you're done.

Build

autoninja -C out/Default chrome

Watch 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 stats

Healthy 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: linux
  • cpu_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_cleanup fixes it.

What's next

  • Persistent workers for the hot toolchain paths.
  • Metrics — Chromium builds produce a lot of telemetry; have the dashboards ready.