# How PlanetScale scrapped Buildkite and runs CI in half the time with Depot (https://depot.dev/customers/planetscale)
PlanetScale provides high-performance, scalable databases in the cloud, offering hosting for both Postgres and Vitess. Building and operating a platform at that scale means that around 90% of the company is writing software every day. Software delivery at PlanetScale means dozens of jobs per commit and a heavy end-to-end test load. PlanetScale was running CI on infrastructure they had to manage themselves.
When they went looking for a solution, they had specific reasons for choosing Depot: performance and scale, and a vendor that meets them where they are today, while still actively building CI for the future.
We spoke with Nick Van Wiggeren, CTO, and Joe Miller, Infrastructure Engineer, about the move.
## The challenge
"This came to a head when Buildkite was having database problems and asked us to accept a multi-hour downtime window
for their service, where we just couldn't do any CI. We're a global company. We have people all over the world who
rely on our CI and CD. When they refused to take a meeting with us to talk about it…it just felt very
non-collaborative."
For about five years, PlanetScale ran CI on a mix of self-hosted Buildkite and GitHub Actions runners. The team had moved from standard GitHub Actions runners to self-hosted for cost and performance, but managing the underlying AWS resources became a constant drain on the infrastructure team. They spent their time debugging why SSM was stopping `apt-get` from working, tuning the ratio of on-demand to spot instances so long-running jobs wouldn't get killed, and standing up separate queues as workarounds when one team's CI load starved everyone else.
Buildkite itself added friction. Simple workflows turned into hundreds of lines of YAML and do-it-yourself plugins, runs were slow, and there was no unified cache API, so engineers spent hours on caching that sometimes never worked. The breaking point came when Buildkite asked PlanetScale to absorb a multi-hour CI outage and declined to discuss it. With engineers around the world relying on CI and CD, that wasn't something the team could accept.
## The solution
"We always want to give our developers the best tools. That's just our philosophy. I have no interest in giving them
anything but the best, I have no interest in wasting their time using subpar tools. Depot hit that sweet spot of being
a drop-in replacement for our manual toil, and gives us an option to evolve in the future."
PlanetScale first heard about Depot years ago when fast Docker builds were the main product. And since Depot's core application database runs on PlanetScale, the two teams already had a shared Slack channel. When PlanetScale was evaluating alternatives to Buildkite and self-hosted runners, three criteria drove the decision toward Depot:
* **Performance and scale**: PlanetScale runs large CI jobs, big Terraform runs, and heavy end-to-end tests, with Vitess and Postgres each kicking off dozens of jobs per commit. Time matters on all of them.
* **A drop-in replacement**: Depot replaced their existing manual work without forcing a rewrite, while giving them a path off GitHub Actions through Depot CI, which they have begun adopting.
* **A vendor still building for the future**: Nick wanted a provider that was innovating rather than standing still. "GitHub Actions is not evolving," he said, "and we like seeing people who are innovating." Planning five years out, he didn't want PlanetScale stuck waiting on it.
The migration started with the workloads that hurt most.
The Vitess test suite's job matrix is large by design: Vitess releases a new version every six months and supports the previous two, so changes that need backporting have to pass tests across each supported version. In practice, a single pull request kicked off 200–400 jobs and consumed roughly 80% of all CI minutes at PlanetScale. On self-hosted runners that volume caused head-of-line blocking: builds stacked up for 20–30 minutes, and a single failure could cost half a day. They had a dedicated runner queue just to contain it.
Nick moved the test suite to Depot. "I just moved everything over to Depot, and that problem completely went away," he said. "We decommissioned the runner queue, and it really just worked, and it made our builds faster and less flaky."
Joe began converting other projects, and the Surfaces team adopted Depot's container builders for their Rails image. Key benefits included:
* **No more runner fleet to manage**: Depot replaces the self-hosted AWS infrastructure for both runners and container builds, removing the spot-instance failures, SSM issues, and per-team queue tuning the infra team had been absorbing.
* **Faster runs across the board**: Many jobs moved to Depot run in roughly half the time they took on self-hosted GitHub Actions runners.
* **Larger, automatic caching**: Depot Cache replaced GitHub's 10 GB Actions cache limit, and Depot's GitHub Actions jobs automatically include the Depot Go cache, which never worked reliably on Buildkite.
* **Deep run observability**: The Depot dashboard shows logs inline with CPU and memory usage for each step and log line, which the team uses for debugging and optimization. Sherlock, Depot's AI assistant, analyzes jobs and surfaces optimization suggestions that Joe takes back to his team.
Joe also pointed to Depot's engineering work as something his team benefits from without having to build it. "You guys have built what we couldn't build without spending a ton of time away from our core business," he said.
Nick summed up the overall change: "It's refreshing to have a provider like this that just works. Everywhere I've worked there have been squabbles or disagreements or annoyances about CI."
## The measurable impact
"I'm already seeing run times cut in half or even better on some of our CI jobs, just by moving to runners. And I'm
excited about what we can do with Depot to speed things up even more."
PlanetScale saw improvements in both build speed and the day-to-day experience of running CI:
* **\~2x faster** runtimes on many jobs moved from self-hosted GitHub Actions runners to Depot.
* **10–12 min to 4 min** on an internal developer-tooling repo, after converting it from Buildkite to GitHub Actions on Depot runners.
* **Half the runtime** on a medium-sized Terraform job moved to Depot runners.
* **Queue contention eliminated** on the Vitess test suites, where a single pull request could kick off 200–400 jobs (roughly 80% of all CI minutes at PlanetScale), builds stacked up for 20–30 minutes from head-of-line blocking, and one failure could cost half a day.
The qualitative change is as important as the numbers. The Vitess test suite is a good example. After moving to Depot, Nick says "I have not thought about it since, nor has the team, and we were thinking about it every day for a while."
Joe saw similar success with the Surfaces team's Rails image, which he and the team's tech lead had worked on speeding up, off and on, for years. "They've been using Depot for three months now, and they just love it. It's been so much faster for them."
## Looking ahead
PlanetScale is expanding its use of Depot CI and Depot's container builds across more workloads, and is especially interested in feeding Depot's run metrics and logs to agents that can identify slow tests, suggest parallelization, and open optimization pull requests automatically.
As AI-driven coding spreads beyond the engineering org, the team is also looking toward finer-grained access controls to let those workflows use Depot while staying separated from security-sensitive repositories.
## For AI Agents
The full site index is at [llms.txt](https://depot.dev/llms.txt). Append `.md` to any documentation, blog, changelog, or customer URL to fetch its markdown source directly.