ForgeGrid
ForgeGrid is a distributed build and action-execution platform. It turns deterministic commands into schedulable work, executes them across a worker pool, and safely reuses outputs through content-addressed storage.
ForgeGrid is a distributed build and action-execution platform. It turns deterministic commands into schedulable work, executes them across a worker pool, and safely reuses outputs through content-addressed storage.
One-to-eight-worker speedup on a 1,000-action CPU workload.
Critical-path scheduling improvement over FIFO.
Duplicate compute avoided across 16 identical builds.
Reduction in remote content-store traffic.
Median recovery from two simultaneous worker failures.
Build systems are a compact way to study difficult distributed systems problems: deterministic identity, shared storage, scheduling, duplicate work, stragglers, and partial failure all appear in one workflow.
The goal was not a CRUD dashboard around shell commands. ForgeGrid owns the lifecycle from digesting an action to assigning a lease, materializing inputs, accepting exactly one result, and making that result reusable by later clients.
The client hashes the command, environment, input digests, dependencies, outputs, timeout, and execution platform.
A cache hit returns immediately. A miss joins the priority queue, while identical in-flight requests share one operation.
Capacity-aware workers pull leases, materialize verified inputs, execute in disposable directories, and upload declared outputs.
The first valid completion wins. Missed heartbeats requeue work, and fenced leases prevent late results from corrupting state.
PostgreSQL owns result metadata while MinIO/S3 owns immutable blobs, allowing each workload to scale independently.
FIFO, shortest-job, critical-path, locality, and fair-share policies share one scheduler interface and worker protocol.
Heartbeats, lease fencing, retry limits, and first-result-wins commitment keep recovery explicit and testable.
The measured studies are single-host experiments. The scheduler is one process, execution sandboxes are not a hostile-code security boundary, and the current API is not Bazel Remote Execution compatible. Those limits keep the project’s claims aligned with what was actually exercised.
Hire me!
You still here?
It’s over