Congrats on the launch!

Sorry to ask this silly question, but since your team is an expert in the "fast Docker images" area, could somebody avoid the traditional `docker build` with say NixOS or Bazel and achieve the same results as Depot (aka, fast building with the output being an OCI/Docker image)? Is that what Depot is doing at a high level? Was this considered?

> Our CLI is wrapping the Buildx library

I'm surprised you're able to build Docker images faster than Docker using their code/libraries?

> I'm surprised you're able to build Docker images faster than Docker using their code/libraries?

It's not a code/library problem. Knowing what Buildkit options to use is the easy part. It's almost entirely a storage infrastructure and networking problem as it has huge implications on whether or not you'll be able to easily cache build layers.

> It's almost entirely a storage infrastructure and networking problem as it has huge implications on whether or not you'll be able to easily cache build layers.

On a single machine, would NixOS/Bazel handle this better than Dockerfile/Docker/BuildKit?

Potentially - if Nix or Bazel has already built the binaries, and just needs to construct an OCI-compliant image tarball with them, that can be quite quick, similar to a Dockerfile with only COPY instructions. Nix and Bazel can also give you deterministic / reproducible images that take more effort to construct with Dockerfiles.

I've also seen people use Nix or Bazel inside their Dockerfile, like ultimately the build has to execute somewhere, be that inside or outside a Dockerfile.

FYI, the nix2container [1] project (author here) aims to speedup the standard Nix container workflow (dockerTools.buildImage) by basically skipping the tarball step: it directly streams non already pushed layers.

[1] https://github.com/nlewo/nix2container