# Depot build-push-action and depot build in GitHub Actions

> Use Depot Docker builds in GitHub Actions with depot/build-push-action, depot/setup-action, and depot/bake-action. OIDC or DEPOT_TOKEN auth, project id, and permissions, per Depot docs.

Source: https://latchkey.dev/learn/compare-runners/depot-build-push-action-setup  
Updated: 2026-07-02

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.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## The verdict

For Depot Docker builds in CI, use depot/build-push-action (or depot build via depot/setup-action), authenticate with OIDC where possible (contents: read, id-token: write) or DEPOT_TOKEN, and pass your project id. See depot.dev/docs/container-builds/integrations/github-actions. If your runner pain is flaky re-runs, a self-healing runner like Latchkey is complementary.

## FAQ

### What is the difference between depot/build-push-action and docker/build-push-action?

Per Depot's docs, depot/build-push-action implements the same inputs and outputs as docker/build-push-action but uses the Depot CLI to run the build on Depot's remote builders.

### How do I authenticate Depot builds in GitHub Actions?

OIDC is recommended (with permissions contents: read and id-token: write); otherwise set DEPOT_TOKEN. Verify at depot.dev/docs/container-builds/integrations/github-actions.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt