Early development open source, Apache 2.0
Remote builds on your own machines.
kbf is a remote execution build farm for Buck2 and Bazel. Your build tool sends actions to one address; kbf runs them on your workers and keeps every result in a shared, content-addressed cache.
Install published with the first release
$ curl -fsSL https://kbf.dev/install.sh | sudo shThe script verifies what it downloads and starts nothing. Other channels are on the install page.
Get started
From a host to a remote build in three steps
-
Install the installer
kbf-installerinstalls and verifies kbf, then takes update orders. Installing starts nothing. specified$ curl -fsSL https://kbf.dev/install.sh | sudo sh -
Set up a mode
One host can run everything; a farm splits the roles. specified
$ sudo kbf-installer setup --mode=all-in-one -
Point Buck2 at it
In your
.buckconfig, send actions and cache reads to the frontend. works today[buck2_re_client] engine_address = grpc://FRONTEND:8980 action_cache_address = grpc://FRONTEND:8980 cas_address = grpc://FRONTEND:8980
The quick start has every flag and what is built today.
Demo
A real build, replayed
A person writes a target, runs the build, and watches the farm work. This is a recorded run of the farm building a slice of a real project, replayed: the terminal is what the build tool printed, and the picture is what the farm did in the same window. Time is compressed.
This is the same target in Bazel. komira builds with Buck2, not Bazel, so this tab is how the same rule would read in a Bazel workspace, not a file from the recording.
- 0:00build time
- 0actions Buck2 is waiting on
- 0running on daemons
- 0answered from the cache
- 0remote runs finished
- 0leases granted
- 0remote runs failed
This demo replays a recording with a script, and scripts are off. The totals are below.
The recording: one cold build of a slice of a real project on a test farm of 2 daemons, started with buck2 build from a list of targets. The build client reported commands: answered from the cache (%), run remotely, local. It took and ended : remote actions failed, and the terminal shows what the build client printed for them.
What was kept: the terminal text is the build client's own output at its real relative times, with host names, addresses, paths, ids and digests removed. The farm side is the frontend's lease log, leases, with the daemons renamed daemon-1 and up. Cache hits are grouped into ms steps, because the recording has over a thousand and the picture draws one flash per step. The data is in the repository.
Why we built it
A farm for the work that needs real machines
We wanted one open farm that runs the whole build, including the tests that need a real Mac, a real display or a real device, and that keeps what happened.
-
UI, Mac and iOS tests on real machines
These tests need a logged-in macOS session, Xcode and, for iOS, a device on a cable. kbf runs actions on Mac nodes as plain processes with their process tree, memory and network watched.
-
Utilization you do not tune by hand
In our experience, fitting actions to machines is hard to configure. kbf has no per-action reservations: it admits actions by CPUs and a memory ladder, and sizes cgroups from what it measures.
-
Open source, all of it
Some other farms are not completely open source. kbf is licensed under the Apache License 2.0.
-
Every build kept, and a way to read it
kbf records the attempts and cache hits of each invocation. We are designing a UI to explore all logs and metrics, and an API that an AI agent can use to fetch results.
Architecture and the rest
Four parts, one binary
frontend
The one address clients, daemons and storage nodes know. Serves REAPI and schedules actions. Its state lives in a Postgres database you provide.
storage
The content-addressable store and action cache: an SSD hot tier, flushed in the background to an object store.
daemon
The worker. It fetches inputs, runs each action in isolation and uploads outputs. Linux and macOS.
all-in-one
The parts in one process, for a single machine or a first try.
A host takes a role with --mode: frontend, storage, daemon, storage-and-daemon or all-in-one. Read the architecture, every setting and how a farm updates itself.
Status. Early development. The project is design-first: interfaces and tests land before features, and nothing here is ready for production use yet. Expect breaking changes. Each step on these pages says whether it works today or is specified.