EngFlow is a Cursor Origin launch partner¶
Bazel makes your builds correct and reproducible. Making them fast, and keeping them fast as your codebase and your team grow, is a different problem. It's the very problem that Ulf and I started EngFlow to solve. I have spent years on the adoption side of Bazel, helping teams put it into production and co-creating BazelCon, and the pattern is almost always the same: teams love what Bazel does for correctness, then run straight into what it costs to operate for speed.
Today, that's much easier to reach. EngFlow, the platform that runs the largest managed Bazel fleet in the world, with over 3 billion build and test actions every week for teams like Arm, Databricks, and Canva, is now one install away for every team on Origin. Read more about this in Origins's announcement on X (Twitter) and Linkedin.
We are starting with CI Runners¶
CI Runners are the fastest on-ramp to the platform, so we're starting there.
- Install EngFlow from the Origin Marketplace
- add
.engflow/jobs/job.jsonon the repository's default branch
| JSON | |
|---|---|
Your Bazel jobs run on the same autoscaling infrastructure that carries those 3+ billion weekly actions. No cluster to stand up and no CI YAML to hand-tune.
Already running pipelines on Buildkite?¶
Buildkite keeps orchestrating your builds; EngFlow supplies the machines they run on and keeps Bazel warm.
- Make sure you are logged in at https://managed.engflow.com/org
- Click on the Connect button inside the Buildkite card
- Authorize EngFlow to connect to your organization
- Add Engflow CI Runners as Agent by adding them to your
pipeline.yml:
This is battle-tested infrastructure. CI Runners are already in production with EngFlow customers, where they have cut CI time and compute spend. Origin makes them reachable in a few minutes, not through a procurement cycle.
The platform behind the fleet¶
Most teams meet Bazel and hit the same wall. The builds are correct, but the speed everyone was promised depends on infrastructure they don't have and don't want to operate. That infrastructure is what we run, as a managed platform:
- Remote Execution spreads a build's actions across a fleet, turning a machine-bound build into a horizontally scalable one.
- Remote Caching shares results across every engineer and every CI run, so no one builds the same thing twice.
- CI Runners bring that speed to continuous integration, with no cluster to operate.
- Build and Test Observability turns Bazel build data into answers: where the time goes, what is flaky, and what is worth optimizing.
Each product removes a specific bottleneck. Together, they power 3.5 billion actions a week. On Origin, CI Runners are the starting point. Build and Test Observability, Remote Execution, and Remote Caching are all on the path.
Built around Bazel, not bolted on¶
Plenty of tools can run Bazel build. Very few are built around Bazel: the analysis phase, the action graph, cache locality, the execution model. That difference is the entire point.
Sixteen of the people on our team helped create Bazel at Google, and we still spend our days in the parts of the system most tools treat as a black box. When we say "managed Bazel," we mean exactly that. Bazel, run by the people who helped build it, not a generic runner with Bazel attached to the side.
Why this matters now¶
Origin gives teams a place to build at agent scale, and agent-scale development means more code, more changes, and more builds landing on the same infrastructure underneath. Making builds fast has always mattered. Keeping them fast as that load grows is the harder job, and it is the one we operate for our customers every day.
If you build with Bazel, the question was never whether this infrastructure would help. It was whether it was worth standing up and operating it yourself. On Origin, that question is gone.
So here is the one question that is left: how fast should your builds actually be? Install EngFlow from the Origin Marketplace and find out. Setup takes about five minutes.
More from the fleet soon. Next in the series, I will get back to what running at over 3 billion actions a week is teaching us about build management at AI scale.