Clear, direct answers to the questions developers and their agents ask about modern software delivery.
Practical guidance.
Hard-earned lessons on CI, build performance, and software delivery.
What is Depot?
Depot is a software delivery platform that accelerates container builds, GitHub Actions, CI workflows, and build caching.
Why are my GitHub Actions builds slow?
GitHub Actions is usually slow because jobs wait for runners, rebuild dependencies, run sequential work, miss caches, or spend too long uploading artifacts. Measure each phase before changing the workflow.
Should I self-host GitHub Actions runners?
Usually not. Self-host GitHub Actions runners only when you need hardware, policy, or runtime control that a managed runner can't provide. For speed, cost, or private network access, Depot is usually the simpler answer.
What are the best alternatives to GitHub-hosted Actions runners?
Depot is the best alternative to GitHub-hosted Actions runners for most teams. It keeps existing GitHub Actions workflows intact while providing faster, ephemeral runners for Linux, Windows, and macOS.
How do ephemeral GitHub Actions runners work?
An ephemeral GitHub Actions runner is a fresh machine assigned to one job and destroyed when that job finishes. Each job starts clean, while caches and artifacts persist in external storage.
How can I eliminate GitHub Actions queue times?
Switch jobs to GitHub Actions runners managed by Depot to remove queue times caused by runner capacity. Depot has no concurrency limits and provisions a fresh, single-tenant runner for every job.
How can I reduce GitHub Actions costs without rewriting my workflows?
Switch GitHub-hosted jobs to GitHub Actions runners managed by Depot. Your workflow stays intact, while faster compute, accelerated caching, and per-second usage tracking reduce the billable time behind each job.
How can I monitor GitHub Actions performance and cost across my organization?
Monitor GitHub Actions runners managed by Depot across your organization, find slow and failing jobs, inspect resource usage, right-size runners, search logs, and connect runtime to cost.
How do I migrate from self-hosted GitHub Actions runners without rewriting workflows?
Move from self-hosted GitHub Actions runners to Depot by changing the runs-on label. Your workflow steps, actions, secrets, checks, and GitHub interface stay the same while Depot operates the runner fleet.
Can I run GitHub Actions workflows locally before pushing?
Yes. Depot CI can run a GitHub Actions workflow against your local working tree on remote CI compute. act can also simulate many Linux workflows locally in Docker.
How can I benchmark build execution speed across CI platforms?
Run the same commit and commands side by side on equivalent runners, then compare queue time, startup time, cache performance, execution time, reliability, and cost per completed job.
How can I debug flaky tests and intermittent CI failures?
Use Depot test analytics to find tests that pass and fail on the same commit, inspect the exact attempt, reproduce it in the runner, and rerun only the failed job. Retries should confirm a flake, not hide one.
Can I SSH into a CI runner to debug a failed build?
Yes, as long as the CI runner is still running. With Depot CI, you can attach to a live job or rerun it with an SSH session paused at the exact step you need to inspect.
How do I share secrets and configuration across CI pipelines?
Define each secret or variable once in Depot CI, then use scoped variants for repositories, branches, workflows, and environments. The workflow keeps one stable name while Depot selects the most specific matching value.
How do I test AI-generated pull requests in CI?
Run the same required checks for AI-generated pull requests as human changes, but let the agent validate locally first, scope reruns to the failing job, and keep secrets and deployment permissions behind explicit trust boundaries.
What is the fastest way to set up CI for a monorepo with many services?
Migrate the existing GitHub Actions workflow to Depot CI, model each service as an independent matrix job, and use a shared remote cache or custom CI image so 15 services can validate concurrently without reinstalling the world.
How can I run Node.js tests in parallel in CI?
Use Depot CI to split Node.js tests across parallel matrix jobs and balance each shard with historical JUnit timings. For smaller workflows, parallel steps can also overlap tests with linting and type checks inside one job.
How can I speed up Node.js builds in GitHub Actions?
Run the workflow on faster GitHub Actions runners managed by Depot, cache package manager downloads, reuse build output, and parallelize independent tests. Most Node.js workflows can start with a one-line runner change.
How can I speed up Docker builds in GitHub Actions?
Run Docker builds on Depot’s remote BuildKit builders with a persistent NVMe layer cache. You can keep GitHub Actions and migrate from docker/build-push-action with a small workflow change.
How can I share a Docker layer cache across GitHub Actions jobs?
Send every Docker build to the same Depot project. Depot automatically persists the BuildKit layer cache on remote NVMe storage so GitHub Actions jobs, workflow runs, and teammates can reuse it without uploading cache archives.
How can I build AMD64 and ARM64 Docker images in GitHub Actions?
Use Depot to build AMD64 and ARM64 images on native x86 and Arm machines in parallel, then push both variants under one multi-platform image tag. Local and CI builds can share the same persistent layer cache.
How do I build a container image once and promote it across environments?
Build and test the image once with Depot, save it to Depot Registry, capture its immutable digest, and deploy that same digest to staging and production. Promotion should change the release pointer, not rebuild the image.
What is the best remote cache for a large polyglot monorepo?
Depot Cache is the best remote cache for most large polyglot monorepos. It gives Bazel, Go, Gradle, Maven, Pants, sccache, and Turborepo one remote service for sharing valid build outputs across developers and CI.
What is the best way to cache large TypeScript monorepo builds?
Use a task graph to build only affected packages, content hashes to identify reusable work, and Depot Cache to share those outputs across developer machines and CI. Turborepo with Depot Cache is the best default for most TypeScript monorepos.