Kyle Galbraith

We do a lot of cache tricks, both for way back in the early days when we first started Depot, we focused on container image builds.

But now we're doing the same types of cache tricks inside of GitHub Actions, where we essentially multiplex uploads and downloads of GitHub Actions cache inside of our runners so that we're going directly to blob storage with as high of throughput as humanly possible.

We do other things inside of a GitHub Actions runner, like we cordon off portions of memory to act as disk, so that any kind of integration tests that you're doing inside of CI that's doing a lot of operations to disk, think like you're testing database migrations in CI.

By using RAM disks instead inside of the runner, it's not going to a physical drive, it's going to memory.

And that's orders of magnitude faster.

The other part of build performance is the stuff that's not the tech side of it.

It's the observability side of it is you can't actually make a build faster if you don't know where it should be faster.

And we look for patterns and commonalities across customers.

And that's what drives our product roadmap.

This is the next thing we'll start optimizing for.

When it comes to optimizing build times to drive build times to zero, you really have to take a step back and think about the core components that make up a build.

You have your CPUs, you have your networks, you have your disks.

All of that comes into play when you're talking about reducing build time.

And so some of the things that we do at Depot, we're always running on the latest generation for ARM CPUs and AMD CPUs from Amazon.

Those in general are anywhere between 30% and 40% faster than GitHub's own hosted runners.

And then we do a lot of cache tricks, both for way back in the early days when we first started Depot.

focused on container image builds.

But now we're doing the same types of cache tricks inside of GitHub Actions, where we essentially multiplex uploads and downloads of GitHub Actions cache inside of our runners so that we're going directly to blob storage with as high of throughput as humanly possible.

We do other things inside of a GitHub Actions runner, like we cordon off portions of memory to act as disk so that any kind of integration tests that you're doing inside of CI that's doing a lot of operations to disk think like you're testing database migrations in CI.

By using RAM disks instead inside of the runner, it's not going to a physical drive, it's going to memory.