Comments URL: https://news.ycombinator.com/item?id=47613428

Points: 2

# Comments: 0

I couldn’t agree more. It’s always felt odd to me that the entire performance of CI is pretty much pushed out of the primitives and requires an immense amount of custom bash scripts and the like. That kind of flexibility isn’t inherently bad. But there should be primitives that are fast by design baked into the system as well.

Parallel steps is one of those things that unlocks a lot when it’s baked into the system.

It looks and sounds incredibly powerful on paper. But the reality is drastically different. It's a big glob of homegrown thoughts and ideas. Some of them are really slick, like build deduplication. Others are clever and hard to reason about, or in the worst case, terrifying to touch.

We had to fork BuildKit very early in our Depot journey. We've fixed a ton of things in it that we hit for our use case. Some of them we tried to upstream early on, but only for it to die on the vine for one reason or another.

Today, our container builders are our own version of BuildKit, so we maintain 100% compatibility with the ecosystem. But our implementation is greatly simplified. I hope someday we can open-source that implementation to give back and show what is possible with these ideas applied at scale.

[0] https://depot.dev/products/container-builds

Comments URL: https://news.ycombinator.com/item?id=46800909

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46719958

Points: 63

# Comments: 21

Sounds strange to say as someone who has a product that is built around making GitHub Actions exponentially faster to close these feedback loops faster.

But I can honestly say it's only really possible because the overall system with GitHub Actions is so poor. We discover new bottlenecks in the runner and control plane weekly. Things that you'd think would be simple are either non-existent, don't work, or have terrible performance.

I'm convinced there are better ways of doing things, and we are actively building ideas in that realm. So if anybody wants to learn more or just have a therapy session about what could be better with GitHub Actions, my email is in my bio.

[0] https://depot.dev/

We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.

[0] https://depot.dev

To your second statement, I generally agree. Sounds strange to say given we're in the business of GHA runners. But it's just not a performant or reliable system at scale. This change from GitHub doesn't smell of a company that wants to do right by it's users.

If you are interested in what is up next for us at Depot, feel free to ping me via the email in my bio. I think you'll be quite interested in what we are doing.

[0] https://depot.dev

[0] https://depot.dev/

We (Depot) are sponsoring this year and have a private leaderboard [0]. We’re donating $1k/each for the top five finishers to a charity of their choice.

[0] https://depot.dev/events/advent-of-code-2025

All that said, to have an outage reported turned around practically the same day, that is this detailed, is quite impressive. Here's to hoping they make their changes from this learning, and we don't see this exact failure mode again.