NativeLink

Operate

What to watch, what to tune, and what to do at 3am, once other people depend on your cluster.

Who this is for: whoever gets paged when the build farm is slow. What you'll have at the end of this section: a production-shaped deployment, a metrics pipeline that tells you when it's unhealthy, and a written answer for each of the ways it fails. Time: ongoing.

Before you start

A NativeLink deployment you configured yourself. See Your first full config.

The shift this section represents

Everything up to the How-to guides is about making NativeLink do what you want. This section is about making it keep doing that while you aren't looking. The questions change shape: not "how do I configure a filesystem store" but "what happens when that filesystem fills up overnight, how will I know, and what do I do about it."

That's a different reader moment, so it's a different section, even though some of the same subsystems come up.

The arc

Get the shape right. The production configuration is not the quickstart configuration with bigger numbers. It has a fast tier over a durable one, eviction policies that match your disk, and a deliberate split between the public listeners and the worker API.

Deploy it somewhere real. Docker Compose or bare metal, each with the topology, the resource sizing, and the failure domains that go with it. For Kubernetes, the Helm charts ship with NativeLink Enterprise.

See it. OTLP to Prometheus to Grafana, and the specific metrics worth alerting on rather than all of them.

Scale it. Workers scale on queue depth and action duration; the CAS scales on throughput and eviction pressure. They are separate problems with separate signals, and conflating them is the most common scaling mistake.

Tune it. A small number of levers move the needle. Most of the config surface does not, and knowing which is which saves a lot of afternoons.

Harden it. Port exposure, mTLS, and keeping the worker API private, which matters more than it sounds, because a worker API is an arbitrary code execution endpoint by design.

Have runbooks. Redis failover, worker OOM, disk full, backpressure. Each one written down before it happens.

Start here, or skip ahead

Start here if you're moving from a working setup to one people depend on.

Skip back to How-to guides if what you have isn't working the way you want yet. Operate assumes the shape is right and the question is whether it stays right.

Current pages

  • Production configuration: the three-process shape, the port surface, and the pre-launch checklist.
  • Tuning: the lever table (the signal you see, the knob that moves it, and what moving it costs).
  • Deploy with Docker Compose or on bare metal: the two deployment shapes, and what separates each from a production one.
  • Observability: the OTLP to Prometheus to Grafana pipeline, and why skipping the collector silently breaks every shipped dashboard.
  • Security hardening: there is no inbound authentication anywhere, so the network is the authorization layer.
  • Scaling workers: sizing one worker, the queue-depth signal, and wiring an autoscaler to it.
  • Scaling the CAS: composing the store graph, sizing eviction, and what a second CAS process actually costs.
  • An autoscaling reference deployment: the manifests that make the worker pool size itself, and the five gaps in the shipped examples you close first.
  • Runbooks: the four incidents NativeLink actually produces: a worker OOM-killed, the disk full, Redis failing over, and a queue that backpressures and never recovers.
  • Troubleshooting: symptom to cause to fix, indexed on the error strings the system really emits.
NextProduction configuration

The production shape: three processes, a split port surface, and what to turn on before other people depend on it.

On this page