Depot build-push-action and depot build in GitHub Actions
Depot's Docker build product plugs into GitHub Actions with a drop-in action. Here is the documented setup: the actions, authentication, and the project id.
Depot's remote Docker builds run through GitHub Actions using Depot's own actions, which mirror the standard Docker actions but route through the Depot CLI. This is distinct from Depot's runners. Attributed to depot.dev/docs/container-builds/integrations/github-actions.
The actions Depot provides
- depot/build-push-action implements the same inputs and outputs as docker/build-push-action but uses the Depot CLI.
- depot/setup-action installs the CLI so you can run depot build --project <id> --push directly.
- depot/bake-action builds multiple images from HCL, JSON, or Docker Compose files.
Authentication: OIDC or DEPOT_TOKEN
Per Depot's docs, OIDC is the recommended authentication method for GitHub Actions: you configure a trust relationship in Depot project Settings selecting GitHub as the provider, and the job exchanges an OIDC token for a temporary Depot token. If you cannot use OIDC, pass a project or organization token via the DEPOT_TOKEN environment variable or the token input.
Permissions and project id
OIDC token exchange requires the workflow to declare permissions: contents: read and id-token: write. Reference your Depot project with the project: <your-depot-project-id> input (or --project on the CLI). Per Depot's docs, these are the pieces that let a build run without static secrets.
When the real problem is flaky failures, not setup
If your Depot jobs are picked up and fast but still fail intermittently on out-of-memory kills, disk-full errors, or registry timeouts, no runner-speed tuning removes that class of failure. Latchkey is also a drop-in managed runner reached by a runs-on label swap, but it is built around self-healing CI: it detects, diagnoses, fixes, and retries transient and mechanical failures automatically, and lists $0.0025/min at 2 vCPU against the $0.006/min GitHub Actions rate. If troubleshooting keeps landing on flaky re-runs, it is worth piloting one workflow on Latchkey next to Depot and comparing.
How to evaluate a managed runner honestly
Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.
- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.