Introduction

Better Compute tracks GPU and CPU capacity: what hardware exists, what is free, and who holds it, from a whole NVLink set of GPUs to a few vCPUs and GiB of memory. The database referees every booking, so a GPU or a vCPU can never be given to two holders at once. It also makes machines useful: you can adopt a server that is already running, deploy an image to a bare machine over PXE, or run isolated VMs, as VPS or as sandboxes, on your own hosts or on a provider's. A sandbox is a hosted VPS instance with a template, a time-to-live and an optional warm pool, served by the sandboxes, sandboxTemplates and sandboxSnapshots API groups of vps().

It is a library, not a hosted service. You construct the control plane with betterCompute() in your own process, on your own PostgreSQL, the same way you construct Better IAM with betterIam():

import { betterCompute } from 'better-compute';
import { postgres } from 'better-compute/postgres';

export const compute = betterCompute({
  database: postgres({ url: process.env.BETTER_COMPUTE_DATABASE_URL! }),
  secret: process.env.BETTER_COMPUTE_SECRET!, // at least 32 characters
  baseURL: 'https://compute.example.com',
  rootTenantId, // the Better IAM root (platform) tenant
  iam, // an IamPort, for example bridge.embedded(iam, { rootTenantId })
  modules: [], // metal(), vps(), provisionModule() and friends
});

await compute.initialize(); // registry checks, migrations, module start()

What it is for

GPU fleets are usually tracked in spreadsheets, a scheduler's memory, or a cloud console, and each of those forgets something: who holds which device, which machine is healthy, or what was promised for next Tuesday. Better Compute keeps one authoritative record and builds everything else on it:

• Fleet truth. Sites, pools, nodes, devices, health and holders, in PostgreSQL.
• Exact capacity, now and over a horizon. Every claim is a booking row guarded by an EXCLUDE constraint, so double-booking is impossible by construction, not by careful scheduling.
• Many provisioning paths. Adopt a running server, PXE or virtual media plus an image stream, a provider reinstall, a VPS on libvirt/KVM or Cloud Hypervisor, or a provider VM. Each path is a composition of drivers.
• A daemon per server and a horizontally scalable control plane, with an API, a typed client, a CLI and MCP tools.
• Scale targets per region on one PostgreSQL primary: 10,000 nodes, 100,000 GPUs, at least 200 placements per second and a command p99 under 1.5 s. These are design targets that the v0.4 phase is meant to prove.
• Modularity. New provisioning methods and providers are modules, drivers and profiles. They need no edits to the @better-compute/* packages.
• Agent-ready. AI agents use the same typed API or MCP tools, and a person can confirm what an agent asks for.

What it is not

The design lists these as non-goals for v1:

• A workload orchestrator. Capacity goes to Kubernetes or Slurm through config drivers; Better Compute hands out devices, it does not run jobs.
• A source of users, roles, keys or invoices of its own. Better IAM owns all of those.
• A telemetry store. Metrics go to a time-series database, never through PostgreSQL or the control stream.
• Active-active multi-region, live migration, or volumes and software-defined networking beyond bridges, VLANs and IPAM.
• Windows or macOS nodes.
• Equinix Metal, which reached end of life on 2026-06-30.

Three runtime parts

bcd, the daemon

bcd is one Go binary with a mode per job:

It only ever dials out, over gRPC on mutual TLS to a gateway on port 443. See the daemon.

The control plane

betterCompute(options) returns { api, handler, nodeHandler, gatewayServices, initialize, start, stop, … }. The same configuration runs in any of four process modes: api (stateless HTTP, admission and JoinService), gateway (daemon sessions and dispatch), worker (reconcilers, event sinks, IAM jobs) or all. PostgreSQL is the truth, and all SQL reads one clock, compute_now(). See architecture.

The API and its clients

Every method is POST /api/compute/{group}/{method}. On the server you call it as compute.api.reservations.create(credential, input), in the browser through a typed client inferred from your server instance, from a shell through the better-compute CLI, and from AI agents through MCP tools. All of them go through the same envelope: authentication, the tenant pre-check, one IAM decision, then one transaction. See clients and the API reference.

Better Compute and Better IAM

Better Compute has no users, roles or API keys of its own. Better IAM is its only identity provider, policy decision point and billing ledger, and also its feature-flag store and event source. Better Compute owns only its machine PKI: the certificates that identify daemons.

• One decision per mutation. Each mutating call makes exactly one Better IAM decision, such as compute:reservations:create on the reservation being requested. Reads use a short decision cache.
• Fleet paths never call IAM. Heartbeats, inventory, commands and reconcilers run without a single IAM call, so a busy fleet cannot saturate the identity system.
• Application-owned resources. Better Compute contributes compute-* resource types (compute-pool, compute-reservation, …) to Better IAM's catalog and resolves them itself from an in-memory projection.
• Billing on reserved time. Usage windows such as gpu.<model>.hours are recorded in Better IAM's billing ledger.
• Embedded by default. The IAM bridge (better-compute/iam) runs Better IAM in the same processes. A remote mode, where Better IAM runs elsewhere, is part of the v0.4 phase.

Both are on npm: Better Compute 0.1.1 works with Better IAM >=0.2.0 <0.4.0 (0.3 today), and you install the two side by side (npm install better-compute better-iam).

What it covers

Project status

The roadmap runs in phases, and a phase closes only when its exit tests pass in CI. Much of the TypeScript control plane for later phases has already landed; what is still open is mostly the Go daemon and the tests that need it:

The daemon deserves a note. daemon/ holds the Go module, and its v0.1 node agent works: bcd join, bcd node, bcd status, bcd doctor and bcd version, with the bbolt journal, the devices and access convergers, five command kinds (including gpu.reset), tunnels, XID and host-pressure reporting, and sealed secret and workload-token requests. tests/e2e/bcd.test.ts runs it against a real control plane and gateway. It is not released (no binaries have been published), and it reads GPUs through nvidia-smi rather than the NVML library (cb987e5). bcd site (Redfish BMC operations, proxy DHCP, TFTP, iPXE and the image cache) and bcd ramdisk (wipes, image streaming, kexec, DCGM) are written and covered by Go unit tests only; a site agent drives IPMI BMCs through the bcx-ipmi plugin. The instances converger runs VMs on libvirt-kvm on a host with virsh and on cloud-hypervisor on a host with its binary (both tested against fake tools only) and on a file-backed runtime in fake-hardware builds, which alone run bcd sim (many real node agents in one process against a gateway). Self-update with A/B slots, the WebSocket fallback and bcd helper (privilege separation, self-update included) are written too. The TypeScript FakeDaemon in @better-compute/testing covers the rest, and it is what joins in better-compute dev --sim N, the simulator and most test suites. See what bcd does today and the roadmap for each phase's exit tests.

Where to go next