Blog

Follow our API test suite from one CI job to seven with Depot Test Splitting. Historical timings balance the work, cutting our measured run from 7m39s to 1m37s.

Speeding up CI isn't one heroic refactor, it's a hunt for the next bottleneck, and for most teams the first one is the test suite. Here's how to attack it with parallelism, sharding, prebuilt images, and a job-density rule that keeps wider sharding from quietly torching your bill.

Most CI jobs run as one long serial script even when half the work doesn't depend on the other half. You can run independent steps in parallel for faster CI. We'll compare two ways to do it: shell backgrounding and Depot CI's parallel steps.

With agents writing the initial fuzz harness, the hardest part of getting fuzzing into CI is basically gone. This is the setup I landed on: cargo fuzz, a GitHub Actions matrix job to fan work across multiple runners, and Actions cache to keep the corpus growing between runs.

Depot CI runs GitHub Actions workflows on Depot infrastructure, and migrating is pretty seamless. Here's a walkthrough of moving an app's CI over, from installing the CLI to digging into logs.

The old CI debugging loop goes: edit YAML, commit, push, wait, squint at logs, repeat. Depot CI replaces that with a local loop you can actually control, from running workflows against uncommitted changes to SSHing into the runner mid-job.

Slow Docker builds are annoying and disrupt your flow. This guide shows practical techniques to optimize your Dockerfile, from simple instruction reordering to advanced caching strategies, with real measurements from a production-like Node.js application.

When graceful shutdown is an afterthought, it's one of the most common sources of production bugs. When servers restart, work gets dropped, state gets lost, and you end up chasing weird behavior at startup. Here's how to use contexts and WaitGroups to implement clean shutdowns that don't lose work or corrupt state.

Ever wondered when Docker reuses cached layers and when it rebuilds from scratch? This guide breaks down the mechanics of how caching works, how cache invalidation cascades through your builds, and how different instructions affect the cache.

Not every self-hosted runner failure is actually a runner problem. GitHub Actions and third-party actions often expect environmental features that GitHub-hosted runners provide by default. When your setup differs, you may get cryptic errors that point to the wrong cause. Here are three real support cases where the symptoms looked like runner issues but weren't.