Hey HN! We’re Kyle and Jacob and we are excited to show you Depot (<a href="https://depot.dev" rel="nofollow">https://depot.dev</a>) and get your feedback!
Depot is a hosted Docker container build service, providing fully managed remote builds from CI and from your terminal. We support both Intel and Arm builds natively.<p>As application and platform engineers, we have experienced the challenge of keeping Docker container build times fast. From optimizing and reoptimizing Dockerfiles, to implementing layer caching in CI, to running & maintaining custom runners for multi-platform images.<p>Still today, there are limitations with the available tools. CI runners are ephemeral, and saving and loading cache tarballs is slow. CI providers are resource constrained, with limited CPUs and disk space to dedicate to fast builds. And with the increasing popularity of Arm devices like M1, Graviton, etc, building multi-platform images requires slow emulation or self-hosted infrastructure.<p>We created Depot to directly address those limitations. Depot provides managed VMs running BuildKit, the backing build engine for Docker. Each VM includes 4 CPUs, 8GB of memory, and a persistent 50GB SSD cache disk. We launch both native Intel and native Arm machines, on Fly.io for Intel builds and AWS for Arm.<p>We have built a depot CLI that embeds the Docker buildx build library, implementing the same CLI flags, so developers can send their builds to Depot VMs just by replacing `docker buildx build` with `depot build`. We also have a depot/build-push-action GitHub Action that can be swapped for docker/build-push-action in CI.<p>The combination of native CPUs, fast networks, and persistent disks significantly lowers build time — we’ve seen speedups of 2-3x on optimized projects, and as much as a 12x speedup with some of our customers.<p>We believe that today we are the only hosted CI or build service offering the ability to natively build multi-platform Docker images (--platform linux/amd64,linux/arm64) without emulation.<p>We are still early though, and would love your feedback.<p>You can sign up without a credit card at <a href="https://depot.dev/sign-up" rel="nofollow">https://depot.dev/sign-up</a> to access a free project with thirty days of unlimited build minutes to try it out.
congrats on launching Kyle and Jacob (hi Kyle!)<p>wondering what kinds of projects are/are not suitable for this. the only context i have is from working at open source devtool companies that provide docker builds for people to pull down. might speed up the release process slightly. i suspect my company <a href="https://github.com/airbytehq/airbyte/" rel="nofollow">https://github.com/airbytehq/airbyte/</a> could benefit. but is it also useful for internal usage?
Congrats on the launch. Apple Silicon really threw a wrench in Docker local development workflows, and this feels like a natural solution.<p>Does docker compose work with this?
When people use a service like this do they bake test runs into the build? Typically in CI I might build and then run tests, but with this service my resulting docker image is in the depot environment.<p>Do I build and then download the image to run it? Or do I have this a bit backwards and this is for build-only use-cases?
I've been using Depot since the early days (I don't know Kyle or Jacob, just stumbled across it)<p>It's superb. It's a drop-in replacement for `docker build` on my M1 Macbook and on GitHub Actions. I really like that they use OIDC for auth in the latter, so I don't have to provision credentials. Of course I also like that builds are 3-4x faster.<p>I have to admit though that the pricing model doesn't make a whole lot of sense to me. It's $25/mo/project, but what's to stop me from using one project for multiple, unrelated Docker images? It's a relatively small cost for saving me time, but it's still big enough that I have slight hesitation to spin up more projects.
This sounds cool. At my current job we do multi-arch builds in GCP Cloud Build using `docker buildx`. The native `amd64` builds take like 15 minutes and the `arm64` component takes well over an hour with occasional time outs. We use the `--cache-to/--cache-from` to speed up repeated builds. If we can't wait the hour+ for the emulation build to run, we have a `seed-mac-arm64.sh` script that a developer (i.e., me) can run on their M1 mac to do the `arm64` half of the build, which is then picked up by GCP Cloud Build. It's a small pain, but helps us in a pinch.<p>This solution sounds far easier!
Any comments on how this would be better than Google Clouds build service? I can do 'gcloud builds submit .` right now and build containers pretty easily in the cloud with this service currently.
Considering that GitHub actions provide no arm64 runners at this stage, this could be extremely useful for some of my projects.<p>So when I build a project on GitHub actions, I simply add a `platforms: linux/amd64,linux/arm64` line to the Docker build & push action. This takes care of pushing the multi-arch build to GHCR for me. Would it be as straightforward in Depot as well? Or would modifying the image manifest be my only option?
> We believe that today we are the only hosted CI or build service offering the ability to natively build multi-platform Docker images<p>Dagger.io, by the originators of docker, can do this too, though it is not well documented. They have not yet enable public signups either by the looks of it.<p>Pretty sure I've seen some other BuildKit frontends that do as well, the space blew up this year with several startups
Hey Kyle and Jacob. Congratulations on launching this and I was really excited because we were looking for something just like this. But as it stands this would be too expensive for our organization. We have a bunch of small (micro?) services and having to pay 25$ for each seems too excessive.<p>But maybe I'm misunderstanding the pricing?
container builds for services, compiled/packaged components you want to spin up somewhere, often the Dockerfile is very simple, use some base image, add config and your binary or packaged artifact (jars, minified JS etc) and done.<p>Often the complexity is (or should be) in the shared base not the individual images you build per commit or PR merge.. for those simple images using something like Jib (bazel can do it too..) where it just constructs the image in user land by adding files to the tarball. I imagine this works for arm binaries from x64 too as long as you can cross compile.. how do you feel about these libraries that make simple images waaay more accessible? No docker required.
How does this compare to nixpacks? I've heard good things but admittedly haven't dug in too far yet.<p><a href="https://nixpacks.com/docs/how-it-works" rel="nofollow">https://nixpacks.com/docs/how-it-works</a>
I am curious if it will help our builds; they are pretty slow, even to the point we have all kinds of tricks to speed them up. Thanks for trying to fix this upfront anyway.
I see you currently have CI integrations for CircleCI, GitHub Actions, Google Cloud Build, and Travis CI. Could I use this in my Bitbucket Pipelines? If so, how?