Blacksmith

@sequoia is leading our Series C at a $1B valuation.

Since January, we’ve gone from running 5M CI jobs a week to over 90M. Agents are writing an order of magnitude more code, and all of it still needs to be built and tested before it ships.

On November 5, 2026, our security team detected and contained unauthorized access to the system that stores the console output (job logs) of CI jobs run on Blacksmith runners. The access was revoked the same day, and a later attempt by the same party to regain access was blocked. Our investigation is ongoing. At this time there is no evidence that customer exposure goes beyond the job-log store.

Based on what we know at this time, the incident impacted job-log data belonging to approximately 2.6% of customer accounts. We have contacted each of these customers directly with the specifics for their organization, and we continue to work with them. We do not believe any other Blacksmith customer needs to take action at this time. If our understanding changes, we will update this notice and notify any affected customers directly.

We are continuing to actively investigate and to harden our systems, and we will publish a full report once that work is complete. Please reach out to security@blacksmith.sh if you have any further questions.

You can't have fast CI with a concurrency cap.
So Blacksmith doesn't have one, and we go to great lengths to keep it that way.

Managed CI shouldn't mean managing limits. When your agents open 100 PRs at once, none of them should wait in a queue.

To restore a cache, Blacksmith runners pull from many storage servers at once, and under load those bursts kept stalling.

We retuned the network path, and the median restore for caches over 256 MiB fell from 5.5 s to 2.8 s.

The slowest 1% went from 35 s to 17 s.

30% less job time on some workloads, just from running in the right region.

→ We record what every job pulls: code, images, data
→ We measure how fast each region reaches it
→ We place each org nearest its traffic