Open source and Enterprise

Who this is for: anyone who has to answer "are we allowed to run this?", and anyone deciding between self-hosting and NativeLink Enterprise. What you'll have at the end: an accurate picture of what is licensed how, what activates it, and what the open-source build does and does not restrict. Time: ten minutes.

The short version

The whole of NativeLink is in the public repository. No separate "enterprise build", no stripped-down community edition, and no compile-time feature flag that divides them. What differs between the free and paid product is the licence you hold, not the code you run.

Two modules inside that one codebase carry a different licence from the rest. Both are compiled into every binary, both are active by default, and nothing checks whether you are entitled to them.

Two licences, one repository

The repository root carries LICENSE, the Functional Source License 1.1 with an Apache 2.0 future grant. Its restriction is narrower than most people expect on first reading: it permits everything except a Competing Use, which the licence defines as making the software available to others in a commercial product or service that substitutes for NativeLink, substitutes for something Trace Machina already offers using it, or offers substantially similar functionality.

Named as explicitly permitted, in the licence text itself: internal use and access, non-commercial education, non-commercial research, and use in connection with professional services you provide to someone else who is themselves complying.

The practical read for most readers is that running NativeLink as your own build farm (for a team, for a company, in production, commercially) is internal use, and internal use is permitted. Reselling a managed NativeLink service is what the licence is written to prevent.

The Business Source Licensed modules

Five files in the tree carry a Business Source License 1.1 header instead of the repository licence. They form two modules:

Their headers say the same thing, verbatim:

// Use of this module requires an enterprise license agreement, which can be
// attained by emailing contact@nativelink.com or signing up for Nativelink
// Cloud at app.nativelink.com.

(The header still names NativeLink Cloud, which is no longer offered; the managed option today is NativeLink Enterprise, and the email address is the route to either agreement.)

The wording matters. It is a licence obligation attached to use of the module, which is a different question from whether you may run the binary at all. You may run the binary; whether you may exercise those two modules in a shared, production or commercial setting depends on a separate agreement.

Nothing in the binary enforces any of this

This is not an oversight to route around. It is the reason this page exists: if you rely on the binary to tell you which features you are entitled to, it will tell you that you are entitled to everything.

Metrics are always on

No configuration turns instrumentation off. The meter provider is constructed unconditionally during startup and installed globally, and the scheduler and store layers call into the licensed instruments on their normal paths: simple_scheduler_state_manager.rs records completed executions, memory_awaited_action_db.rs records stage transitions, and cache_metrics_store.rs records every cache operation.

NL_OTEL_ENDPOINT is often mistaken for the switch. It is not. Setting it chooses a load-balanced gRPC channel for the OTLP exporters; leaving it unset means the exporter builds its own channel to the OTLP default instead. Either way the instruments are declared and recorded. What changes is where the export attempt goes, not whether measurement happens.

The consequence for licensing is that "we don't use metrics" is not a configuration you can be in. What you can choose is whether you consume them: whether a collector is running, whether dashboards and alerts are built on them, whether they are part of how your team operates the cluster. That consumption is what the licence is about. See Observability for the pipeline itself, and note that page's own licence callout.

Persistent workers activate from the action, not from your config

No persistent_worker key exists anywhere in the configuration schema; searching nativelink-config for it returns nothing at all. The module is reached entirely from the action's own platform properties:

Those properties come from your build tool. Bazel sets them on rules that declare worker support: Java and Scala compilation, TypeScript, and anything using ctx.actions.run with execution_requirements asking for workers. A Bazel build that already uses persistent workers locally will exercise the licensed module remotely the first time it runs an affected action, with no NativeLink-side opt-in and nothing in your configuration mentioning it.

Because there is no config surface, the pool's behaviour is fixed at compile-time defaults:

Two actions share a worker process when their worker key matches: same resolved executable, same startup-flag prefix (the arguments before the first @response-file), and same wire format. The full picture, including what isolation you give up, is on Persistent workers.

What the open-source build does not limit

Nothing in the code artificially constrains scale. Specifically, there is no cap on cache size, stored object count, action throughput, connected worker count, or number of people using the cluster; no trial period, expiry date, or time-limited mode; and no registration, activation, or account required to start the binary.

Nor does the binary report anything home. The only outbound HTTP clients in the tree belong to storage backends you configure yourself (the S3-compatible, GCS and Azure object stores), and the only other egress is to the other backends you configure (Redis, MongoDB, grpc stores), gRPC to the peers in your own cluster, and the OTLP exporters. Those exporters send to whatever endpoint you point them at, which is your collector; if you point them somewhere else, that is your configuration doing it, not a default.

The limits you will actually hit are the operational ones (file descriptors, disk, memory, scheduler backpressure), and those are documented in Troubleshooting and Runbooks.

What Enterprise adds

The honest answer, from inside this repository, is that the paid tier is not a different codebase, so this documentation cannot enumerate its feature list by reading the source. What can be said accurately:

It carries the licence for the two Business Source modules in shared, production and commercial settings, which for most teams running metrics-driven operations is the substantive difference, since as shown above there is no way to run without touching that module.

It removes the operational work. The whole of the Operate section (the deployment shape, the metrics pipeline, the eviction sizing, the incident runbooks) describes work that a managed tier does instead of you. That is the trade Shared cache frames as an operational-cost question (control-plane compute, CAS storage, worker compute, and the engineer hours to run it) rather than a licence question.

For what Enterprise includes, its pricing, and what support attaches to it, the sources of truth are nativelink.com/pricing and the licence page. Meaningful contributors to the project may be eligible for waivers on the Business Source modules; ask the maintainers before relying on one.

Telling what you are running

The binary is a clap parser with version derived from the crate, so:

nativelink --version

prints the crate version (1.6.5 at the time of writing) and exits. The container image is tagged with the same version prefixed by v (ghcr.io/tracemachina/nativelink:v1.6.5); pin that tag in production rather than a floating one. See CLI and environment for the complete flag surface, which is --help and --version and nothing else, and Upgrade versions for moving between them.

No command prints licence status, because there is no licence status to print.

FAQ