> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# Spawns

> Learn how Bazel spawns actions during the execution phase using sandboxed, local, worker, and remote strategies, and how heuristics pick between them.

When an action has a cache miss in every cache, then it needs to be executed. Hopefully this execution is desirable and not just due to misconfiguration or non-determinism!

Bazel executes actions in the Execution phase by spawning a subprocess, with an API like `ctx.actions.run` or `ctx.actions.run_shell`

## Spawn strategies

Bazel can take several approaches to execute an action. Improvements to Bazel’s heuristics can make later releases faster without any changes to your code!
See [https://bazel.build/docs/user-manual#execution-strategy](https://bazel.build/docs/user-manual#execution-strategy)

* `sandboxed` causes commands to be executed inside a sandbox on the local machine.
  * This requires that all input files, data dependencies and tools are listed as direct dependencies in the `srcs`, `data` and `tools` attributes.
  * Bazel enables local sandboxing by default, on systems that support sandboxed execution.
* `local` causes commands to be executed as local sub-processes.
* `worker` causes commands to be executed using a persistent worker, if available.
* `docker` causes commands to be executed inside a docker sandbox on the local machine.
  * This requires that docker is installed.
* `remote` causes commands to be executed remotely; this is only available if a remote executor has been configured separately.
* `dynamic` is a special value to try both remote and local execution, take the first to complete.
  * See [https://bazel.build/remote/dynamic](https://bazel.build/remote/dynamic)

## Inspecting the sandbox

How to find it: run Bazel with the `--sandbox_debug` flag. It will print lots of extra information, and buried in there you can find paths beneath the temporary sandbox folder.

This flag also causes Bazel to skip the cleanup and removal of the sandbox folder - leaving it available to inspect and troubleshoot.

## Tuning resources per-action

Bazel has a heuristic-based scheduler that tries to maximize how much work can happen on the
computer without overloading the system.

Resources that might be overused:

* RAM: Bazel schedules too many compilation actions and exhausts system memory, the OS swaps and the machine is unusable or hangs.
* CPU: Bazel schedules too many intensive tests in parallel and they all fail to complete within their timeout because they run too slowly on a loaded system.
* Network throughput: A mis-configured NAT gateway throttles outbound connections resulting in a hung container test.

<Callout icon="book">
  Read more: [bazel oom](/blog/bazel-oom)
</Callout>

For tests, simply adjusting the `size` attribute causes more RAM to be reserved. To reserve resources for build steps or to reserve CPU, use the `resource_set` API on the action spawn. See [https://github.com/bazelbuild/bazel/issues/15187](https://github.com/bazelbuild/bazel/issues/15187) however - this API is designed for a rule author rather than an end user. [https://github.com/bazel-contrib/bazel-lib/blob/main/docs/resource\_sets.md](https://github.com/bazel-contrib/bazel-lib/blob/main/docs/resource_sets.md) provides an easy way for rule authors to expose a string-typed `resource_set` attribute for targets to configure.