Astral builds high-performance developer tools for the Python ecosystem, including Ruff, a linter and formatter, and uv, a package and project manager. With a small team shipping releases daily on some of the most widely used Python developer tools, fast CI isn't optional. Zanie Blue is a software engineer at Astral who leads the uv project and oversees CI infrastructure across the org. We spoke with Zanie to learn how Astral used Depot to keep CI running when a single project threatened to bring it to a standstill.
The challenge
"If we moved the [python-build-standalone] project into our GitHub org, making a single commit in a pull request on that project would bring our org to a halt. CI would stop everywhere."
Astral runs an unusually large CI footprint for a company its size. The uv project alone requires a large integration test suite with over 100 jobs across operating systems, architectures, and Python versions. Because the tool operates at the systems level, the tests need to cover all the nuances of the different platforms.
The CI problem crystallized for Astral when they took stewardship of python-build-standalone, a project that produces self-contained, highly-portable CPython distributions across every supported Python version and architecture. Its CI matrix runs approximately 900 jobs, each taking between 20 and 60 minutes.
Astral was already pushing against GitHub’s 60-job free runner concurrency limit, which was shared across all of Astral's active projects. Early testing showed that moving the python-build-standalone repo into the organization would consume that entire pool on a single commit, halting CI for all projects across the organization.
Reducing job concurrency for the project was also off the table. “We could set a really low concurrency limit, but it's really important for us to get fast feedback across the architectures. The project targets so many different architectures, it’s hard to iterate on it locally,” explained Zanie.
GitHub hard-caps macOS runners at five concurrent jobs even on paid plans, which is a serious bottleneck for an org like Astral that runs macOS CI across several projects at once. And GitHub's larger runners are expensive. On GitHub's infrastructure alone, scaling wasn't viable.
The solution
"It was a no-brainer to pay less for the performance that we were getting from the larger GitHub runners. And in a lot of cases we’d switch to the equivalent Depot runner, which is cheaper, and it would also be faster. Why would we stay on GitHub?"
Zanie evaluated a few other providers before choosing Depot, preferring Depot’s developer experience over the alternatives. The initial migration was straightforward: switching python-build-standalone's Linux jobs to Depot runners unblocked the org without restructuring any workflows or negatively impacting other projects. "We just switched to Depot for the Linux runners, and that immediately gave us vastly more concurrency," said Zanie.
Dedicated macOS runners on Depot came next, supplementing GitHub's five-runner ceiling across all of Astral's projects.
- Concurrency at scale: Depot removed GitHub's concurrency ceiling for Linux and macOS, letting Astral run the full python-build-standalone matrix alongside macOS jobs across multiple projects simultaneously without starving the rest of the org.
- Faster runners at lower cost: Switching uv's Unix test jobs to Depot immediately cut test time (by 43% on Linux and 17% on macOS), and saved about 20% on costs.
- Faster releases: Increasing Depot runner size for uv's binary builds reduced job times by up to 48% across macOS and Linux ARM targets, directly shortening the time between opening a release PR and shipping.
- Simplified Docker builds: Depot's container builders replaced a complex multi-platform manifest workflow in uv's Docker image pipeline that previously required coordinating builds across multiple GitHub Actions runners.
The impetus for every improvement was the same: prioritizing engineering time. As Zanie puts it, “That's why Depot is something that's so valuable for us, because we don't have the engineering time to solve these problems ourselves."
The measurable impact
“For a company of our size, we choose to spend proportionally more on CI to scale the productivity of our team through automation and prevent regressions with extensive testing. We care a lot about the speed of our CI and Depot is consistently faster.”
Developers count on Astral’s tools for every commit, so the bar for CI has to be high. Depot helps Astral maintain the CI investment that the work demands. Here are some examples:
- 43% faster Linux test runs in uv (4m 12s → 2m 23s)
- ~20% cost reduction on uv's Unix test jobs versus equivalent GitHub larger runners
- Up to 48% faster binary build jobs across macOS and Linux ARM in uv
- 4.7x faster test runs for Ruff ecosystem tests (14m → 3m) with Depot 8 CPU runners
The gains show up most in the rhythm of daily work. Astral does a lot of stacked pull requests, so CI runs multiply with every merge. At peak, uv ships releases multiple times a day. Every minute shaved from a CI run compounds at that cadence.
Looking ahead
Astral has nearly doubled its Depot usage in the last six months. What started with a single project migration now runs across open source and commercial workloads alike, including large-scale concurrent builds of Python packages for their commercial service, pyx.