Configure remote execution

Choose the execution service

With Managed Builds, Hermetiq supplies your remote cache and execution infrastructure. With Intelligence, you keep the Buildbarn you already operate. The executor endpoint, credentials and worker platforms must match the service actually provisioned for your project.

Start Managed Builds

Not using Bazel yet? Start with a workload and migration assessment. The agreed workload needs a supported Bazel build before Hermetiq can operate it.

1. Create the project. For Cloud, create a project and connect Bazel build data. For On-Prem, plan and install the service in your environment.
2. Provision execution. Agree on execution platforms, region, worker images and capacity with Hermetiq. Obtain the executor endpoint, instance name, required platform properties and authentication configuration for that project.
3. Configure Bazel. Add the executor configuration below using those supplied values. Existing BEP ingestion or remote cache access alone does not enable remote execution.
4. Verify a remote action. Run a representative target and check both Bazel’s execution evidence and the Hermetiq invocation before moving CI traffic.

Check workload compatibility

Choose the execution environment for the tools your actions run, separately from the developer’s laptop and the platform you are building for. Use the platform values supplied for your provisioned worker pool.

For on-prem installation platform requirements, see the Kubernetes support matrix. That matrix describes the hosting platform, not every OS or architecture that a remote action can execute on.

Configure Bazel

Set --remote_executor to the execution frontend and use the instance name required by that service. Keep the flags in an explicit configuration until the integration is verified.

# Structure only: use the values supplied for your project
build:hermetiq-rbe --remote_executor=<RBE_ENDPOINT>
build:hermetiq-rbe --remote_instance_name=<INSTANCE_NAME>

# Repeat this flag for the properties required by your execution platform
build:hermetiq-rbe --remote_default_exec_properties=<NAME>=<VALUE>

Activate these scoped entries with --config=hermetiq-rbe. If you choose a different configuration name, use that name consistently in local and CI commands.

Use the credential-helper host mapping generated for the project or supplied by the customer-managed administrator. If the deployment uses separate cache and executor endpoints, ensure the helper covers every authenticated host and configure the matching remote cache explicitly.

Match instance and authentication

• The --remote_instance_name value must identify the storage and execution namespace assigned to the project.
• The machine credential must be authorized for that project and for the executor, cache, CAS, or Bytestream hosts it contacts.
• Use grpcs:// when the service requires TLS. Install the required trust chain rather than disabling certificate validation.
• For customer-managed RBE, follow the deployment’s OAuth, mTLS, or metadata convention; not every deployment enables every authentication method.

Authentication success does not guarantee access to the requested instance. A credential can be valid while the instance name or routing metadata is wrong.

Match execution platforms

Remote schedulers match actions to workers using platform properties. The Buildbarn or managed-service operator should publish the supported operating system, architecture, container image or worker pool, and any custom property names and values.

• Set only properties the scheduler recognizes, using the exact spelling and values supplied by the operator.
• Use Bazel execution platforms and toolchain constraints when different targets require different workers.
• Keep target and exec-platform constraints separate: a target may produce one platform’s output while its tools run on another.
• Verify that worker capacity exists for every property combination emitted by the build.

Make actions portable

A remote worker does not automatically have the tools installed on the Bazel client. Actions should declare their tools and inputs through Bazel toolchains, repositories, runfiles, or the execution environment agreed with the RBE operator.

• Avoid undeclared reads from the client filesystem, home directory, or host-specific absolute paths.
• Do not assume the worker image contains a compiler, shell, SDK, certificate bundle, or system package unless the platform contract says it does.
• Keep environment-dependent values explicit and stable when they affect action keys.
• Test representative targets, tests, code generation, and packaging workflows before moving all CI traffic.

Enable action-level observability

Completed-action logging is separate from executing actions. When the deployment’s action logger, event stream, project setting, and request metadata propagation are configured, Hermetiq can associate remote actions with queue, input-fetch, execution, output-upload, worker, and cost context.

If builds execute remotely but the Remote Execution Analytics or action timing views are empty, verify the Completed Action Log integration. Enabling it only affects newly emitted action events and does not reconstruct older runs.

Verify the integration

1. Run a small representative target with the explicit RBE configuration. Choose an action that actually needs to execute, rather than a fully cached build.
2. Confirm Bazel reports remote execution for that action. Keep its execution log or equivalent runner evidence; a successful build, a remote cache hit or a recorded BEP event alone does not prove remote execution.
3. Open the invocation in Build History and check its command line, action outcomes, failures, and available remote-execution timing.
4. Repeat the build to exercise cache behavior, while remembering that a cache hit does not prove an action executed remotely on the second run.
5. Expand to representative tests and toolchains, then observe queue time and worker capacity under CI concurrency.

Troubleshoot remote execution