Overview

bcd is the Better Compute daemon. One Go binary runs on every server you manage, on the site agents that boot bare metal, and inside the PXE ramdisk. It connects out to a regional gateway, reports what the machine is, runs the typed commands the control plane sends, and converges the machine toward its NodeSpec.

The daemon holds no policy. It never decides who gets a GPU or when a machine is wiped; the TypeScript control plane does. What bcd decides on its own is about safety: refusing a command meant for another node or past its deadline, never running a side effect twice, and never dropping a device assignment because it lost its connection.

Where bcd sits

Each daemon holds one long-lived gRPC session to one gateway. The gateway keeps sessions, heartbeats and lane counters in memory and writes what matters to PostgreSQL, which stays the only source of truth. Losing a gateway loses open streams and nothing else: the daemon redials, the next gateway replays what was in flight, and the daemon's journal makes sure nothing runs twice. See sessions and delivery.

Modes

The same binary runs in several modes. The mode decides which command kinds the daemon accepts and which role its certificate carries.

A site agent and the ramdisk speak the same session protocol as a node and run the same agent (runAgent: session, journal, dispatcher, convergers, status socket); only their command kinds and what runs beside the agent differ. Sites and deploying cover what they do for bare metal.

The three agent modes take these flags:

Beside the modes, bcd has five local commands, all of which work:

Exit codes are 0 for success, 1 for a failure and 2 for a usage error. bcd never echoes a positional argument, so a join token pasted into the command line does not end up in logs:

$ bcd join bcjt_jt_01...
bcd join: takes no positional arguments
bcd join reads the join token from BCD_JOIN_TOKEN or stdin, never from arguments

bcd doctor prints one line per check, with a status of ok, warn or fail. The nvml check asks nvidia-smi for the driver version and GPU count (cb987e5); a host without nvidia-smi warns (nvml: nvidia-smi not found (no NVIDIA driver on this host)), and a build with -tags nonvml warns that NVML is not available in this build:

ok    config    /etc/bcd/config.toml: gateway https://gw.eu-1.example.com, site fsn1
ok    nvml      driver …, 8 GPUs
ok    hardware  host: 8 GPUs, … inventory sections hashed
ok    kvm       /dev/kvm present
ok    iommu     16 IOMMU units
ok    gateway   gw.eu-1.example.com:443 reachable in 4ms
ok    identity  node node_01k5w… (site fsn1, role node), certificate valid for 14h12m0s

Since f9d7af9 doctor also prints one gpu line per GPU from nvidia-smi: its UUID and name, how busy it is, its temperature, power draw of its limit and memory used of its total. A pending row remap or a MIG mode change waiting for a reset is a warning; failed row remapping or uncorrectable ECC errors since the driver loaded is a failure. A host without the NVIDIA driver prints no gpu line. With a configuration file it adds the Kubernetes checks: kubernetes fails when [kubernetes] allowed_clusters does not parse, reports the number of allowed clusters, and fails a node bcd joined to a cluster without any, since every k8s-join then refuses (9f860ad); on a node bcd joined to a cluster, kubelet fails when the kubelet is not running, and device-plugin warns when /var/lib/kubelet/device-plugins is missing. gpu-isolation fails whenever bcd would report ForeignGpuExposure: on a joined worker for a toolkit configuration that lets unprivileged pods pick GPUs and for another GPU DRA driver in the node's ResourceSlices, and, since f88bcdb, on a node with [host] units = false (a DaemonSet) for the toolkit and for a container runtime configuration it cannot read (see GPU isolation). As root with [helper], helper says what the helper binds host units to: root's signed join record (ok), trust on first use for a node joined before that record (warn), or a record that names another node or fails its signature (fail; f77c6f9), and fails when neither command_root_sha256 nor the record names command-signing roots, so host units would go unsigned (71ccf71; see signed specs).

ok    gpu       GPU-5f1c… NVIDIA H100 80GB HBM3: 87% busy, 61 C, 540/700 W, 71.2/79.6 GiB
warn  gpu       GPU-9a02… NVIDIA H100 80GB HBM3: 0% busy, 34 C, 72/700 W, 0.0/79.6 GiB; a row remap waits for a GPU reset
ok    kubernetes 1 allowed clusters

A missing /dev/kvm or IOMMU is a warning (the host cannot run VPS instances, or pass GPUs through to them), and so is a node that has not joined. An identity that is there but does not load (a node key that no longer matches its certificate, an unreadable identity.json) is a failure since a1c1a46 (it was a warning); its detail, like that of an expired certificate, ends with the way back: join again as root: bcd join --reset --yes, then bcd join. A host with neither virsh nor cloud-hypervisor gets a warning that it runs no VPS instances. With either, doctor reports the runtime it found and checks a VPS host's tools: it fails one missing qemu-img (no instance disks), both genisoimage and xorriso (no NoCloud user data seed) or nft (no anti-spoofing or network policies, so the metadata service and instance dials stay off) (4a0165f). For cloud-hypervisor it also warns when /usr/share/cloud-hypervisor/CLOUDHV.fd is missing (its instances cannot boot) and fails without systemd-run (its VMMs could not outlive bcd) (2598f0a). Since 2845f41 it also warns when [update] release_pins is missing (self-update is refused) and otherwise reports the pin count and threshold, fails when the slots are in use but the entrypoint does not link to the slots directory's current, warns about a pending update and each failed version (pointing at bcd update --clear-failed), and warns when a site agent has no [site] bmc_networks. It finds the slots and records where bcd update does (8eca2b1): [update] slots_dir, else /usr/local/lib/bcd under the helper, else <data_dir>/bin. Run as root on a helper node, it fails the helper check for each directory on the way to the slots, the helper socket or the entrypoint that is not root's alone, the condition that keeps bcd helper from starting (9e71b1f). A gateway that does not accept a TCP connection within 5 seconds, or an expired node certificate, is a failure. It also warns when others can read config.toml or its group can write it (group read is the --unprivileged install's root:bcd 0640), and exits 1 when any check fails. Since e2a0cf0 it also checks that the host clock is synchronized (clock), and bcd hardware reports what the host really is; see running bcd on real hardware.

Since ab26e87 doctor also checks what enforcing booked host resources needs from the host:

bcd status

bcd status prints the agent's state first, then, since ad8791f, the machine's:

gpus       2
  0 GPU-5f1c…   87%   61 C   540/700 W  71.2/79.6 GiB  held by alloc_01k…
  1 GPU-9a02…    0%   34 C    72/700 W  0.0/79.6 GiB  UNHEALTHY
kubernetes hosted node gpu-node-7, offering 1 bcd.dev/gpu
telemetry  https://otel.example.internal:4318, last export 2026-09-26T08:12:00Z

• gpus. One line per GPU, read from nvidia-smi at that moment: index, UUID, how busy, temperature, power draw of its limit, memory used of its total, the allocation holding it, and UNHEALTHY when it may take no work (a failed or pending row remap, uncorrectable ECC errors, an XID). --json also carries the model and the processes.
• kubernetes. On a Kubernetes worker: joined or hosted, the Node and, when joined, its API server, and how many devices each bcd.dev resource offers the kubelet (no devices when none).
• telemetry. With a telemetry section: the OTLP endpoint, the last export and the last error.

--json has gpus, kubernetes and telemetry objects for the same.

bcd sim

bcd sim (aa7501c) runs many real node agents in one process against the gateway of a configuration file, so the load a gateway sees is the real daemon's, not a model of it. It exists only in fakehw builds (go build -tags fakehw); a host build exits 2 with bcd sim: needs a fakehw build.

Each simulated machine i gets its own data directory <data_dir>/sim/<i> holding its node.key, identity.json, bbolt journal, fakehw boot id and the file-backed libvirt-kvm instance runtime, and runs the same agent as bcd node over its own session. A machine that has not joined yet joins as role node (claims hostname sim-<i>) with the one token bcd sim reads at start from BCD_JOIN_TOKEN or standard input; the token must allow as many uses as there are unjoined machines, and at most 16 joins are in flight at once. The token is only read when some machine still needs it, and join-encryption.jwk must sit next to the configuration file (there is no --server fallback). Machines that joined before simply reconnect on the next run.

A node.reboot writes a new boot id and restarts only that machine's agent, not the process; a machine whose agent fails is restarted after a back-off of one second per consecutive failure, capped at a minute. The process runs until SIGINT or SIGTERM, then prints how many machines joined and how many reboots it saw:

printf '%s\n' "$SIM_TOKEN" | bcd sim --config ./sim.toml --nodes 5 --seed 100
# bcd sim: 5 nodes (fakehw seeds 100-104) against <gateway_url>
# ... one "simulated node joined" log line per machine ...
# bcd sim: stopped; 5 joined, 0 reboots

tests/e2e/bcd.test.ts runs five of them with one five-use join token and checks that five distinct machines (five distinct hardware keys) connect and that the token appears nowhere in the output. better-compute sim is a different tool: the deterministic, single-process fleet simulator built on the TypeScript FakeDaemon, with chaos and invariant checks and no real gateway. bcd sim is the one to point at a real gateway and PostgreSQL. PLAN.md's nightly run of bcd sim --nodes 10000 through Toxiproxy (v0.4) is not wired up.

What bcd does today

bcd node is the v0.1 node agent (daemon/internal/agent); bcd site and bcd ramdisk run the same agent with their own kinds. What it implements and what is still missing, as of commit 2598f0a:

Outbound only

Nodes only dial out. A daemon connects to gw.<region>:443 through an L4 load balancer that passes TLS through to the gateway, so a server needs no inbound port, no public address and no firewall exception. Everything the control plane wants from a node travels down the session the node opened: commands, desired state, requests to open a tunnel, revocation notices.

bcd ramdisk opens no TCP listener, and neither does bcd node unless it serves the metadata service. The only local endpoint is a root-only unix socket (mode 0600 in a 0700 directory) that serves bcd status; PLAN.md also plans doctor and support-bundle against the running agent on it. If the socket cannot be created, the agent logs it and runs without. Under privilege separation there is a second unix socket, bcd helper's at [helper] socket, which only the node's account and root may use. A VPS host with [imds] listen set serves its instances' metadata service there (for example 169.254.169.254:80 on the instances' bridge), answering only requests whose source address belongs to one of its running instances. The other exception is a site agent with a [boot] section: its boot server listens on plain HTTP at [boot] listen, and optionally for proxy DHCP (UDP 67 and 4011) and TFTP, for the PXE machines of its own provisioning network. It answers a booting machine only while it holds the site's boot lease (see sites).

Privilege separation

By default bcd node runs as root under systemd hardening: ProtectSystem=strict, NoNewPrivileges, a narrow set of writable paths and a bounded capability set. Installing bcd shows the unit.

PLAN.md §6 (v0.4) splits the daemon in two, and since 28dc2ae bcd can run that way. With [helper] socket and [helper] user in config.toml, bcd node runs as that unprivileged account, and bcd helper --config /etc/bcd/config.toml runs as root beside it and performs a few typed operations on the node's behalf. daemon install-script --unprivileged (169c459) sets this up: the bcd account, bcd-helper.service, and a bcd.service drop-in that runs the node as bcd (see running bcd node unprivileged). The session, the journal, and every command, spec and frame that comes from the network are then parsed by the unprivileged process; the helper parses only its own small requests, and trusts nothing in them.

What the helper does

The helper builds each file's path from its own table:

Every file is written mode 0644, except k8s-token, which is 0600. The helper walks each directory down from / with os.Root, checking every component with Lstat and refusing a symlink or anything that is not a directory (a missing one is created 0755). Running as root on the real filesystem, it also refuses a directory on the way that is not root's or that group or others can write (02485b3). It writes a temporary file created exclusively in that directory, then renames it over the target, so a symlink planted at the target is replaced, never followed. The node side (helper.Client) maps a path to its kind and id and refuses any path outside the table before it sends anything.

libvirt through the helper

The libvirt group gives root: whoever can write to qemu:///system can define a storage pool over /etc or a domain with a host disk. So since ed3c7d2 an unprivileged bcd node is not in that group. Its libvirt-kvm runtime (runtime.Libvirt with a Hypervisor) sends every privileged virsh verb to the helper's libvirt.* operations above, reads through libvirt's read-only socket (virsh -r) for list, domstate, dumpxml and domstats only, and refuses any other verb ("is not an operation bcd helper does"). A paused start or restore passes the helper's Paused flag (--paused; f3c6a65). libvirt.restore needs a definition, checked like a define and passed as --xml: a restore without one is refused before anything runs, since virsh restore alone would start the domain the node-written state file embeds (b6df6f1). The helper runs virsh -c qemu:///system as root, stages each definition in its own directory, /var/lib/bcd-hostconfig/libvirt, and acts only on domains whose bcd metadata names them, never on one bcd did not define.

libvirt.define checks the domain XML default-deny (c305a05, fea4d2e): only what the runtime renders is admitted, and anything else is refused, such as qemu:commandline, filesystems, block, USB or direct devices, graphics, a custom emulator or kernel, a seclabel, a DOCTYPE or entities, and foreign namespaces or attributes.

libvirt then runs with dynamic_ownership = 0, so it never chowns a path the node names: QEMU reaches the node's files through the node's group instead. The runtime makes instance disks 0660 (read-only ones 0640) and gives directories on the way group search rather than others' search. The file checks are the second line, since the node owns those directories and could race them. daemon install-script --unprivileged sets the host up (d418820; see running bcd node unprivileged), and bcd doctor's libvirt check fails a host that is not.

internal/helper tests the validator (domain_test.go), the operations against a fake virsh (libvirt_linux_test.go, a foreign domain refused, a paused start) and the file check on a real file system; the runtime's side is internal/runtime hypervisor_test.go. No test has run it against a real libvirtd.

cloud-hypervisor through the helper

Until 7fe74a1 an unprivileged node dropped cloud-hypervisor with a warning and did not advertise it, since its VMMs need root for their systemd-run units, taps and VFIO devices. Since then (runtime side d86fcbe, helper side 7fe74a1 and 94843ec) it runs under [helper] like libvirt-kvm, and sandboxes, which default to it, can use such a host. The node keeps owning every file and shares the instance's with the VMM's own uid through POSIX ACL entries (aclGrant, 55e0069; the unit's UMask becomes 0007), and root does only the steps that need root, each from what it checks itself:

The node still talks to each VMM over its API socket, which reaches only what the VMM's own uid can open inside its unit. Each call names the instance by the domain-name pattern and is logged with it (instance= in the helper's log). Without a cloud-hypervisor binary on root's PATH the helper refuses every ch.*. bcd doctor warns when [helper] instance_bridges is empty. See delivery for the runtime side. internal/helper's ch_test.go (taps on allowed bridges only, a launch never taking another unit's uid, VFIO for whole groups of this host's GPUs only) and internal/runtime's ch_privileged_linux_test.go run against fakes; no real VMM has run under the helper.

Node keys through the helper

bcd keeps the node key in the host's TPM (see the node key in the TPM). Until 8870b8d an unprivileged bcd node opened /dev/tpmrm0 itself, through the tss group the install script put it in. Security review 3 found that too much: the kernel's resource manager filters no command, so a compromised bcd user could change the hierarchies' authorization, clear the TPM through the (default empty) lockout authorization or trip its dictionary-attack lockout, breaking root's TPM-sealed secrets (LUKS keys enrolled with systemd-cryptenroll) and attestation. Now the unprivileged node never opens the TPM:

• Who opens it. Processes that run as root open it themselves: bcd join, bcd helper, and bcd node without [helper]. When bcd node runs unprivileged with [helper] socket set on a host with a TPM, every node-key operation goes to the helper instead (helper.TPMKeys).
• What the node can ask. Only the five operations below, each naming a node key by the 32-byte unique that node.key records. The helper derives the key from tpm.NodeKeyTemplate itself, with the empty password the template sets, and uses its own AK, so the node chooses no template, handle, hierarchy or authorization.
• What the node checks. The key the helper derives must have the node-key attributes, every signature must verify against the key's public half, and a certification must come from the AK the helper announced.

At most 8 node keys stay loaded in the helper (TPM object slots are few); the least recently used one is unloaded to make room, and an unloaded key is derived again whenever it is used, so a helper restart costs nothing. The node's calls time out after 30 seconds. A helper on a host without a TPM refuses every tpm.* operation ("node keys in the TPM are not served by this helper (the host has no TPM)"), and any other tpm. verb is an unknown operation. Every TLS handshake and node statement signs, so a successful tpm.sign is not logged; its refusals and every other tpm.* call are.

daemon install-script --unprivileged no longer adds bcd to tss, and an upgrade run takes it out (see running bcd node unprivileged). Until that run, a host installed between 0ba2a79 and 8870b8d keeps bcd in tss, and since e6c3f53 bcd doctor fails its tpm check there (gpasswd -d bcd tss, then restart bcd.service). internal/helper's TestHelperTPMKeys checks the operations against tpmsim; no hardware TPM has run them.

Self-update through the helper

Self-update's privileged half is selfupdate.Manager (2d67b25): Prepare (verify only), Swap, Confirm, RollBack, Settle, Status, Expire and ClearFailed. A node without a helper runs it in process; under the helper the helper runs it, and the node only downloads and restarts:

1. The slots are root's. The binary slots and the upgrade and release records (upgrade.json, update.json) live in [update] slots_dir, by default /usr/local/lib/bcd under the helper (<data_dir>/bin otherwise, with the records in data_dir). The helper creates it, each missing directory on the way 0755 whatever its umask, never re-moding one that exists. A slots_dir inside data_dir (or containing it), or an [update] entrypoint inside data_dir, is refused under the helper, since the node owns that directory and could plant the binary root trusts (9e71b1f). Running as root, the helper adopts the entrypoint's binary into a slot only when it is a root-owned regular file that group and others cannot write.
2. The node downloads. It asks update.prepare which artifact to fetch and writes it to <data_dir>/staging/bcd-<version>.
3. The helper verifies and swaps. update.swap takes no path from the node. The helper verifies the signed manifest again under its own [update] pins, threshold and release floor, and the expiry against its own clock (the node's server time can only make that check stricter). It opens the staged file beneath the staging directory's parent without following a symlink or blocking on a FIFO, takes only a regular file with one link owned by the node's uid (c139b9c), and hashes it as it copies it into the other slot, so what is checked is what runs, then records upgrade.json and swaps.
4. The node confirms. The node restarts into the entrypoint, and on its first Welcome asks the helper for update.confirm, which moves the release floor up. The helper confirms only while current points at the pending slot.
5. The helper's own watchdog. An update still unconfirmed 30 seconds after its deadline is swapped back by the helper, which then restarts bcd.service, whatever the node does. The watchdog is re-armed when the helper starts.

A terminal refusal (a manifest that does not verify, a version below the floor) comes back flagged as such, so the node treats it as final rather than retrying.

The helper trusts nothing the node claims (c139b9c, security review 11). The running version is the current slot's record in slots.json (before the first update, the helper's own version), not the version the node reports. update.settle decides by where current points, so a node that falsely claims to run the old version cannot get the new one recorded as failed and the watchdog disarmed. slots.json records each slot's version, manifest sequence and written SHA-256, and the binary in the other slot is reused without a manifest only when its recorded sequence is known and not below the floor. Once a release is confirmed, nothing takes the node below it, so a compromised node cannot swap back to an older binary that root would then run. tests/e2e/bcd.test.ts delivers a build signed under the pinned key to an unprivileged node through a real helper, with the slots outside the data directory, and sees it confirmed.

Who it serves

• The peer. For every connection the helper reads the caller's pid, uid and gid with SO_PEERCRED. The uid and gid must both be [helper] user's (its primary group), or the uid must be 0. /proc/<pid>/exe must be the same file as an installed bcd: [update] entrypoint, bcd-a or bcd-b in [update] slots_dir, or the helper's own binary. A refused caller gets only "not allowed"; the helper logs its pid, uid and the reason.
• The protocol. One request per connection: JSON {"v":1,"op":…} of at most 4 MiB, answered {"v":1,"ok":…} with an error when it failed. Both sides refuse unknown fields and another version, so a node and helper of different versions refuse each other rather than guess. Each side gives a request 2 minutes, and the helper serves at most 32 requests at once (c139b9c); a connection over that cap gets a retryable busy answer (9e71b1f).
• The socket. Mode 0660, owned by root and the node account's primary group. Its directory (created 0755 if missing) must be root's and closed to group and other writes, or the helper refuses to start. Run as root, it also requires every existing directory from / down to the slots, the socket and the entrypoint to be root's alone (c139b9c, 9e71b1f), and checks that before it touches its update records; bcd doctor as root reports a directory that is not as a failed helper check. The helper binds, chmods and chowns the socket inside a private 0700 directory and only then renames it into place, so no path the node could swap for a symlink is ever changed by root (2d67b25, after a security review found the earlier chmod-after-bind could be redirected). The install script uses /run/bcd-helper/helper.sock, not /run/bcd, which bcd owns.
• The log. Every operation is logged with the peer's pid, the operation, the file kind and id or the GPU, and the outcome (helper: operation … op=file.write kind=cdi name=<allocation> in text logs).

bcd helper refuses to start without [helper] socket, when [helper] user names no account, or when it is not root (a fakehw build excepted). The helper is Linux only, since it needs SO_PEERCRED. The configuration check requires an absolute socket path and a user that is not root. See the keys in config.toml.

Both units start the same entrypoint, which a swap points at the new slot. A self-update restarts only the node, so the helper keeps running the binary it started with until it restarts; that works as long as both speak the same helper protocol version (1 today), since a node and a helper of different versions refuse each other. A rerun of the install script restarts both units.

What the helper does not cover still runs with the node account's own rights: the journal, key and status socket in data_dir and socket_path, the libvirt-kvm runtime's reads on libvirt's read-only socket and its files under data_dir/libvirt, the cloud-hypervisor runtime's files and ACL grants and its VMMs' API sockets, and reading /dev/kmsg for XIDs. From 7dde6a3 until 7fe74a1 cloud-hypervisor was not offered under the helper; now its taps, VFIO and VMM units go through ch.* (see above). bcx plugins need root to start (they get their own uids only when bcd is root), so --unprivileged refuses --plugins. PLAN.md's runtime.* operations are not helper operations; the MIG layout, like every config unit, goes through host.unit. The end-to-end tests cover the CDI path (an unprivileged fakehw bcd node beside a real bcd helper binds and releases a GPU hold, and the helper's log shows the file.write and file.remove of its CDI spec) and self-update. Only bcd node uses the helper.

Other limits hold with or without the helper:

• Keys. The node key is in the host's TPM when there is one (50e18f9, 0ba2a79; for an unprivileged node, held by the helper, 8870b8d): /var/lib/bcd/node.key then holds only the record the key is derived from again, and the key cannot be copied off the machine, though root on the node can derive and use it. Otherwise it is a 0600 PKCS#8 file, which the next renewal moves into the TPM once one is usable. A bcd join --attestor tpm also proves it to the control plane: the TPM's attestation key certifies the join's key (cf24876), and the certificate then names that AK, so every renewal has the AK certify the next key in the TPM or fails loudly (d94f1f3; see renewing a TPM-held key). bcd never exports it. It signs only statements of the form "this node says": the mTLS handshake, renewal proofs of possession, attested results, allocation reports, and secret and workload-token requests.
• Allowlists. Each role accepts only its own command kinds; anything else is rejected UNSUPPORTED.
• Bounds. A command body is at most 1 MiB and a desired-state body at most 4 MiB. The journal is capped at 64 MiB and 10,000 unacked events.
• Secrets. Commands carry references, never values. bcd fetches a value with a node-signed SecretRequest and opens the answer, a JWE sealed to a fresh one-time key, only for that request id; the design keeps the value in memory only and zeroes it after use. The site agent asks for BMC credentials, site.httpProxy secret headers and each PXE machine's discovery token this way, and the ramdisk for deploy.image user data. logs.collect redacts tokens, JWTs, private keys and URL passwords from its bundle before the upload.

Inside bcd

The Go module (github.com/better-compute/better-compute/daemon, Go 1.26 or later per go.mod) is laid out by concern. Its third-party modules are connect-go, protobuf, bbolt and klauspost/compress (zstd for image streaming); go-nvml is not added: GPUs are read through nvidia-smi instead (cb987e5).

Two numbers shape everything the daemon runs. Commands go to one of three lanes, and each lane has a fixed worker pool, never a goroutine per command: control 4 workers, provision 2, bulk 1. The converger runs NodeSpec sections in a fixed order (host, devices, instances, access, telemetry, daemon), each as an idempotent plan and apply, and advances its observed generation only when every section has converged or failed terminally.

Contributors build and test the module from daemon/:

go test -tags nonvml,fakehw ./...   # logic tests: no cgo, no NVIDIA driver, fake HGX H100 hardware
go vet -tags nonvml,fakehw ./...
go build -ldflags "-X main.version=0.1.0" -o bin/bcd ./cmd/bcd

From the repository root, node scripts/daemon-test.mjs runs the same tests on any OS.

The nonvml tag builds without cgo and never loads libnvidia-ml; fakehw reports the fake HGX node instead of reading the host, keeps its boot id in data_dir, "reboots" by re-executing itself, and is the only build that accepts dev_insecure_h2c. bcd targets Linux on amd64 and arm64 (for Grace and GB200). On Windows, scripts/daemon-test.mjs cross-compiles each package's test binary for linux/amd64 and runs it in WSL, since Application Control may refuse locally built executables. See testing.

The FakeDaemon

FakeDaemon in @better-compute/testing is the daemon side of the protocol in TypeScript. It mirrors the Go packages rule for rule: the same journal rules, the same acceptance checks, the same lane credits and worker pools, the same converger order, the same server time mark. Its fake hardware produces the same inventory section hashes as Go's fakehw for the same seed. It runs over any frame transport: an in-memory link with fault injection, real HTTP/2 to a real gateway, or the WebSocket fallback.

It is what runs wherever features bcd lacks, or many daemons without a real gateway, are needed:

• better-compute dev --sim N joins N simulated machines through a loopback gateway, the way bcd does: a join token sealed to JoinService's key, the Join RPC, a session, diag.nvml acceptance and adoption. See local development.
• better-compute sim runs the deterministic fleet simulator with crashes, reboots, journal loss, partitions and gateway kills, then checks invariants I1, I2, I3, I4, I5 and I8.
• createFleetSim, createControlPlaneSim and the real-time harness drive fleets from tests and benchmarks. See testing.

better-compute dev --memory --sim 8
better-compute sim --nodes 100 --chaos heavy --seed 7

Both now speak the WebSocket fallback and self-update (bcd with a real A/B slot swap, the FakeDaemon's opt-in selfUpdate in simulation). bcd matches it on joining, sessions, the journal, signed intent, the five v0.1 kinds, driver.invoke (the same driver selection, secret handling and idempotency key), the devices section, the instances rules (on a fakehw build; the FakeDaemon's FakeHypervisor and bcd's fake runtime follow the same ones), the metadata service's contract, tunnels (both advertise tunnel.instance-dial: the FakeDaemon when its tunnels are configured, bcd when it runs a runtime), secret and workload-token requests, XID conditions and host pressure. bcd is ahead on the access and host sections, which the FakeDaemon still reports as SectionUnsupported, its tunnels run a real shell where the FakeDaemon's answer with an echo shell, and its site agent and ramdisk act on real BMCs and disks (disk image files under the fakehw build) where the FakeDaemon's simulate them.