A push becomes a build. There is no pipeline.
A per-repo CI config is a hand-maintained description of a dependency graph you already have. fastverk reads the real graph instead: a push resolves to a target set, builds hermetically on your own remote execution, and reports back — with no YAML to write, drift from, or debug at 2am.
Your pipeline is a worse copy of your build graph.
Two descriptions of the same dependency structure, only one of which is checked by anything.
A Bazel build graph already states, precisely and mechanically, what depends on what. A CI config restates a fraction of that by hand — which jobs run, in what order, triggered by which path globs — and then drifts, because nothing verifies the restatement against the original.
The drift is what bites. A new dependency edge lands in BUILD.bazel and the pipeline doesn't learn about it, so a change ships without ever building the thing it broke. The fix isn't a better pipeline file. It's not having one.
What replaces it.
Four moving parts, none of which is a config file someone has to remember to update.
How a push becomes a build
- The graph resolves the work: a push is matched against the Bazel module graph, and the target set falls out of reverse-dependencies rather than a path glob someone wrote last year.
- Remote execution does the work: actions run hermetically on your own Buildbarn cluster, so a cache hit is a real cache hit and a green is reproducible tomorrow.
- The metrics already exist: cache, workers, queue depth and latency come from the Prometheus your RBE exposes. No Prometheus means empty panels — never a fabricated number.
- The forge gets one contract: status lands as native Check Runs, Deployments, and commit statuses across GitHub and self-hosted GitLab, written as the signed-in user.
The four numbers you actually tune.
Read from the Prometheus your remote execution already exposes — nothing new to instrument. Values illustrative.
| signal | now | what it tells you |
|---|---|---|
| cache hit rate | 91.4% | how much work you're not redoing |
| worker saturation | 0.62 | headroom before queueing starts |
| queue depth | 18 | whether merges outpace capacity |
| p99 action latency | 4.2s | the tail that sets wall-clock |
Derived beats declared.
The alternative asks a human to keep a second description of the dependency graph accurate, forever.
The pipeline file was always a second, unverified copy of the dependency graph. Delete the copy.
Backed by shipping plugins.
Each claim on this page is anchored to a plugin that provides it. The site build resolves these cross-references against the live feature catalog and fails if one of them doesn't exist — so this list can't quietly outlive what the platform ships.
Turns a push into a graph-scoped build on your own RBE by resolving it against the real Bazel module graph — the per-service pipeline file stops existing.
plugin detail →Cache hit rate, worker saturation, queue depth and latency percentiles read straight from the Prometheus your RBE already exposes — zero dashboards to build or maintain.
plugin detail →Every commit's image is inspectable down to the layer filesystem — config, ordered layers, and reading a file inside an image inline.
plugin detail →The result lands as a native Check Run, Deployment, or commit status through one contract that covers GitHub and self-hosted GitLab alike.
plugin detail →Adjacent problems.
At a hundred merges a day, testing everything is too slow and testing the diff is too little. The graph knows which answer is right.
Read more →An agent can open thirty pull requests an hour. The gate is what decides which of them are safe to merge.
Read more →Prove it's safe to merge.
Hosted, or launched into your own AWS account. Start free — no card required.