actiond is a local Remote Execution API worker and cache for Bazel. On macOS,
Windows, and Linux it starts a small Linux VM and runs Bazel actions inside
that VM, so the host can act like a local Linux remote-execution worker.
The macOS ARM64, Windows ARM64/x86_64, and Linux ARM64/x86_64 releases include zstd level 22 frames containing the matching VM kernel, initramfs, and Linux runtime image.
actiond
worker/cache instead of each running too many local actions.For implementation details, see ARCHITECTURE.md.
Download the latest macOS arm64 release:
curl -L \
https://github.com/hermeticbuild/actiond/releases/latest/download/darwin-actiond_macos_arm64 \
-o darwin-actiond_macos_arm64
curl -L \
https://github.com/hermeticbuild/actiond/releases/latest/download/SHA256.txt \
-o SHA256.txt
grep ' darwin-actiond_macos_arm64$' SHA256.txt | shasum -a 256 -c -
chmod +x darwin-actiond_macos_arm64
You can also download the binary from the GitHub releases page.
./darwin-actiond_macos_arm64 serve-vm \
--listen=127.0.0.1:8980 \
--root="$HOME/Library/Caches/actiond/vm"
--root stores the VM state, including the guest-owned CAS and ActionCache.
Reusing the same root keeps the local cache warm across worker restarts.
The Windows ARM64 and x86_64 release binaries use Host Compute System and Hyper-V sockets. The Windows smoke runs the embedded guest artifacts:
e2e\run_llvm_windows_vm_smoke.ps1
Windows requires Hyper-V. windows-actiond wraps the runtime SquashFS and
guest-owned ext4 CAS in fixed VHD files. The default VHD paths are under
--root; --cas-image can select another CAS VHD path.
The Linux releases embed zstd level 22 frames containing the matching QEMU
executable from rules_qemu and, on x86_64, qboot.rom. linux-actiond
expands QEMU, the Linux kernel, the initramfs, the runtime SquashFS, and
qboot.rom into sealed memfds. The guest-owned CAS remains a persistent ext4
file under --root. The QEMU process uses KVM, host CPU passthrough, and
io_uring for the CAS file.
The host kernel must support io_uring. linux-actiond requires read/write
access to /dev/kvm and /dev/vhost-vsock:
test -r /dev/kvm -a -w /dev/kvm
sudo modprobe vhost_vsock
./linux-actiond_linux_x86_64 serve-vm \
--listen=127.0.0.1:8980 \
--root="$HOME/.cache/actiond/vm"
Add a config like this to your workspace .bazelrc:
build:actiond --remote_executor=grpc://127.0.0.1:8980
build:actiond --remote_cache=grpc://127.0.0.1:8980
build:actiond --spawn_strategy=remote
build:actiond --genrule_strategy=remote
build:actiond --remote_local_fallback=false
build:actiond --remote_upload_local_results=false
build:actiond --noremote_cache_compression
Then build with:
bazel build --config=actiond //...
Your Bazel workspace still needs toolchains and platforms that can run in Linux.
actiond executes the actions Bazel sends it; it does not turn a macOS toolchain
into a Linux toolchain automatically.
The embedded runtime image currently includes:
glibc2.31glibc2.35glibc2.39bashActions that are not fully hermetic and need a glibc can request one be mounted into their chroot via execution property:
exec_properties = {"libc": "glibc2.35"}
Unsupported libc names fail explicitly.
Actions that invoke a Bash script can request the embedded Bash runtime with
the requires-bash exec property:
exec_properties = {"requires-bash": ""}
For a whole build, Bazel can inject the same property globally:
--remote_default_exec_properties=requires-bash=
Most users should use releases. Source builds are mainly for development:
bazel build --config=remote -c opt //cmd/darwin-actiond
bazel build --config=remote -c opt //cmd/linux-actiond:linux-actiond_linux_arm64
bazel build --config=remote -c opt //cmd/linux-actiond:linux-actiond_linux_x86_64
Normal contributor checks:
bazel build --config=remote //...
bazel test --config=remote //...
The macOS and Linux VM e2e harness is:
tools/e2e.sh vm
Zig
76.9%
C
9.0%
Starlark
5.5%
Shell
3.7%
Python
2.7%
PowerShell
1.3%
actiond is a local Remote Execution API worker and cache for Bazel. On macOS,
Windows, and Linux it starts a small Linux VM and runs Bazel actions inside
that VM, so the host can act like a local Linux remote-execution worker.
The macOS ARM64, Windows ARM64/x86_64, and Linux ARM64/x86_64 releases include zstd level 22 frames containing the matching VM kernel, initramfs, and Linux runtime image.
actiond
worker/cache instead of each running too many local actions.For implementation details, see ARCHITECTURE.md.
Download the latest macOS arm64 release:
curl -L \
https://github.com/hermeticbuild/actiond/releases/latest/download/darwin-actiond_macos_arm64 \
-o darwin-actiond_macos_arm64
curl -L \
https://github.com/hermeticbuild/actiond/releases/latest/download/SHA256.txt \
-o SHA256.txt
grep ' darwin-actiond_macos_arm64$' SHA256.txt | shasum -a 256 -c -
chmod +x darwin-actiond_macos_arm64
You can also download the binary from the GitHub releases page.
./darwin-actiond_macos_arm64 serve-vm \
--listen=127.0.0.1:8980 \
--root="$HOME/Library/Caches/actiond/vm"
--root stores the VM state, including the guest-owned CAS and ActionCache.
Reusing the same root keeps the local cache warm across worker restarts.
The Windows ARM64 and x86_64 release binaries use Host Compute System and Hyper-V sockets. The Windows smoke runs the embedded guest artifacts:
e2e\run_llvm_windows_vm_smoke.ps1
Windows requires Hyper-V. windows-actiond wraps the runtime SquashFS and
guest-owned ext4 CAS in fixed VHD files. The default VHD paths are under
--root; --cas-image can select another CAS VHD path.
The Linux releases embed zstd level 22 frames containing the matching QEMU
executable from rules_qemu and, on x86_64, qboot.rom. linux-actiond
expands QEMU, the Linux kernel, the initramfs, the runtime SquashFS, and
qboot.rom into sealed memfds. The guest-owned CAS remains a persistent ext4
file under --root. The QEMU process uses KVM, host CPU passthrough, and
io_uring for the CAS file.
The host kernel must support io_uring. linux-actiond requires read/write
access to /dev/kvm and /dev/vhost-vsock:
test -r /dev/kvm -a -w /dev/kvm
sudo modprobe vhost_vsock
./linux-actiond_linux_x86_64 serve-vm \
--listen=127.0.0.1:8980 \
--root="$HOME/.cache/actiond/vm"
Add a config like this to your workspace .bazelrc:
build:actiond --remote_executor=grpc://127.0.0.1:8980
build:actiond --remote_cache=grpc://127.0.0.1:8980
build:actiond --spawn_strategy=remote
build:actiond --genrule_strategy=remote
build:actiond --remote_local_fallback=false
build:actiond --remote_upload_local_results=false
build:actiond --noremote_cache_compression
Then build with:
bazel build --config=actiond //...
Your Bazel workspace still needs toolchains and platforms that can run in Linux.
actiond executes the actions Bazel sends it; it does not turn a macOS toolchain
into a Linux toolchain automatically.
The embedded runtime image currently includes:
glibc2.31glibc2.35glibc2.39bashActions that are not fully hermetic and need a glibc can request one be mounted into their chroot via execution property:
exec_properties = {"libc": "glibc2.35"}
Unsupported libc names fail explicitly.
Actions that invoke a Bash script can request the embedded Bash runtime with
the requires-bash exec property:
exec_properties = {"requires-bash": ""}
For a whole build, Bazel can inject the same property globally:
--remote_default_exec_properties=requires-bash=
Most users should use releases. Source builds are mainly for development:
bazel build --config=remote -c opt //cmd/darwin-actiond
bazel build --config=remote -c opt //cmd/linux-actiond:linux-actiond_linux_arm64
bazel build --config=remote -c opt //cmd/linux-actiond:linux-actiond_linux_x86_64
Normal contributor checks:
bazel build --config=remote //...
bazel test --config=remote //...
The macOS and Linux VM e2e harness is:
tools/e2e.sh vm
Zig
76.9%
C
9.0%
Starlark
5.5%
Shell
3.7%
Python
2.7%
PowerShell
1.3%