actiond Developer Reference Wiki

Pages

1. Technical OrientationWhat actiond is, its two execution modes (linux-actiond and darwin-actiond serve-vm), the top-level binary layout, the REAPI subset it implements, and how the rest of this reference is organized.
2. REAPI Server, CAS & Data FlowThe HTTP/2 gRPC server that implements the REAPI surface (Execution, CAS, ByteStream, ActionCache, Capabilities), how blobs are stored and addressed in the content-addressable store, and the end-to-end data flow from Bazel client through to action output collection.
3. Linux Host Execution — Chroot, Namespaces & CgroupsHow linux-actiond runs actions directly on a Linux host: execroot construction, read-only bind mounts for CAS inputs, private mount and network namespace setup, loopback-only networking, uid/gid drop, PR_SET_NO_NEW_PRIVS, and best-effort cgroup v2 resource limits.
4. macOS VM Execution — darwin-actiond, vsock & Guest WorkerHow darwin-actiond serve-vm boots a minimal arm64 Linux VM via Virtualization.framework, proxies REAPI traffic over virtio-vsock to linux-actiond-guest, manages the guest-owned ext4 CAS on a virtio block device, and handles standalone binary payload extraction at startup.
5. actiondfs — Lazy CAS-Backed Input FilesystemThe custom Linux kernel filesystem module that exposes REAPI input trees to VM actions without per-file copies: lazy Directory proto resolution from the guest CAS, VM-lifetime parsed Directory cache keyed by digest, backing-file delegation for read/splice/mmap, strict vs. overlayfs compatibility paths for input-mutating actions, and the /proc/actiondfs_stats counter interface.
6. Build System, Runtime Images & TestingHow the full repo is built with Bazel and rules_zig, how glibc runtime SquashFS images are packaged and selected via the libc platform property, how standalone binaries embed compressed kernel and initramfs payloads, and the layered testing strategy: unit tests, Docker Linux e2e, VM e2e, and the LLVM tblgen smoke benchmark.