Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yep, so Depot runs BuildKit, so the same workflows work there, just with a remote builder. You can do one of three things:

1. Just build the image — in CI that would test that the image built successfully, and the build cache would be ready for future builds. So for instance if you ran a build on a branch, but only pushed the image on the main branch workflow, the second run could just re-use the cache.

2. Build and push the image to a registry — from there you could do anything with the image in the registry (pull it from any workflow, deploy it, etc)

3. Build and pull the image to the local Docker daemon. In CI, that might be ideal for integration testing the container, like you mention.

You can also use option (2) for integration testing the container, which is especially useful with multi-platform images. Docker doesn't (yet) support storing multi-platform images locally, but it will pull the correct platform from the registry.

tl;dr — Depot supports the same options as `docker buildx build`, where you can push, pull, or just build the image depending on your needs




Another unusual alternative is to model your test running _as_ a Docker build. It's what I ended up doing in Trellis, which supports Depot as a runner (https://github.com/charliermarsh/trellis): running the linter check is modeled as "build the image, then add a `cargo clippy` RUN command as the last layer".


you could use multi stage builds here too so you don't have to carry around the linter, not a bad idea




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: