[bldr]
our thesis

a build should be a fact, not a chore

ci systems spend most of their time rebuilding things that already exist. bldr starts from a different premise: if you address every artifact by the hash of its content, identical inputs can only ever produce one output — so a build becomes a lookup, and the network becomes a shared memory of everything anyone has ever built.

[01·the idea]

content-addressing, all the way down

every source, layer and output is an immutable block named by its blake3 hash. there is no cache invalidation — only content that does or doesn't already exist. results are exchanged peer-to-peer, so work done on one machine is instantly reusable on the next.

on top of that engine we build the boring-but-critical parts of a corporate ci/cd system — triggers, pipelines, secrets, audit — and offer them as a managed platform, while the engine itself stays open.

[ the same input, everywhere, once ]
inputsgit · oci · fs
blake3cid:fs:…q7f2
resolvecache ∨ peer ∨ build

given the same inputs, the runner returns the same output — from cache, from a peer, or by executing, in that order of preference.

[02·principles]

what we optimise for

determinism

same inputs, same output — always. reproducibility is the feature everything else is built on.

never build twice

a shared, content-addressed cache means a result computed once is reused across the whole fleet.

no lock-in

the core is open source and portable. the platform earns its place by being useful, not by trapping you.

boring where it counts

secrets, audit and governance should be dependable and unremarkable — so you can forget about them.

[ early software ]

bldr is under active development. apis, cli flags and on-disk formats can still change between releases. we'd rather ship in the open and improve fast than polish in private — if that trade-off suits you, you're exactly who we're building for.

come build with us

questions, feedback, or want to see it on your own workloads? we'd love to hear from you.