TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Show HN: Accelerated Docker builds on your local machine with Depot (YC W23)

64 pointsby jacobwgalmost 2 years ago
Hello HN! We just launched a new feature we built at Depot that accelerates Docker image builds on your local machine in a team environment, and we wanted to share some of the details with you all.<p>The launch blog post: https:&#x2F;&#x2F;depot.dev&#x2F;blog&#x2F;local-builds<p>Depot is a hosted container build service - we run fully managed Intel and Arm remote build machines in AWS, with large instance sizes and SSD cache disks. The machines run BuildKit, the build engine that powers Docker, so generally anything you can `docker build`, you can also `depot build`.<p>Most people use Depot in CI, and you could also run `depot build` from your local machine as well. That would perform the build using the remote builder, with associated fast hardware and extra fast datacenter network speeds.<p>But then to download the container back to your local machine, BuildKit would transfer the <i>entire</i> container back for every build, including base image layers, since BuildKit wasn’t aware of what layers already existed on your device.<p>The new release fixes this! To make it work, we replaced the BuildKit `--load` by making the Depot CLI itself serve the Docker registry API on a local port, then asking Docker to pull the image from that localhost registry. The CLI in turn intercepts the requests for layers and fetches them directly using BuildKit’s content API.<p>This means Docker only asks for the layers it needs! This actually speeds up both local builds, where you only need to download changed layers, as well as CI where it can skip building an expensive tarball of the whole image every time!<p>We ran into one major obstacle when first testing: the machine running the Docker daemon might not be the same machine running the `depot build` command. Notably, CircleCI has a remote Docker daemon, where asking it to pull from localhost does not reach the CLI’s temporary registry.<p>For this, we built a &quot;helper&quot; container that the CLI launches to run the HTTP server portion of the temporary registry - since it’s launched as a container, it does run on the same machine as the Docker daemon, and localhost is reachable. The Depot CLI then communicates with the helper container over stdio, receiving requests for layers and sending their contents back using a custom simple transport protocol.<p>This makes everything very efficient! One cool part about the remote build machines: you can share cache with anyone on your team who has access to the same project. This means that if your teammate already built all or part of the container, your build just reuses the result. This means that, in addition to using the fast remote builders instead of your local device, you can actually have cache hits on code you haven’t personally built yet.<p>We’d love for you to check it out, and are happy to answer any questions you have about technical details!<p>https:&#x2F;&#x2F;depot.dev&#x2F;docs&#x2F;guides&#x2F;local-development

16 comments

paulgbalmost 2 years ago
We have been happily using Depot for months now to build <a href="https:&#x2F;&#x2F;plane.dev" rel="nofollow">https:&#x2F;&#x2F;plane.dev</a>. Prior to finding Depot, we basically gave up on building an M1 image from a GitHub action.<p>(btw, I always get suspicious when a Show HN post has a lot of praise in the comments, but I swear the Depot folks did not ask me to post anything and I only saw the post because I was checking HN)
评论 #36049983 未加载
aidosalmost 2 years ago
Just to echo the other comments- really impressed with both Depot and the team. I decided to kick the tyres on it last week and suddenly found myself replacing all our production docker builds with it by the end of the day. Felt like my Tailscale experience in terms of onboarding.<p>Totally seamless integration and it solves a very real issue that I’ve had with docker caching across our environments. We tried with the docker s3 cache originally but it didn’t really work in practice. Depot is the answer.<p>When I ran into an issue last week, the guys had responded and scheduled a call within minutes.<p>Depot are a team I’m happy to back with a product I’m very happy to pay for.
0xbadcafebeealmost 2 years ago
Hey Depot peeps, I like the idea of faster builds, but that&#x27;s not what I really need. I need easier builds.<p>Making a simple container with a simple app is easy. The devil&#x27;s in the details. What if you want to pull from a private registry using temporary credentials tied to a specific user, then use <i>different</i> temporary credentials during the build to pull packages from a different private package repository, <i>persist</i> the package cache across different container builds, then push the images to a <i>different</i> remote registry with more temporary credentials, with multi-stage builds, without capturing secrets in the container or persisting environment variables or files specific to the credentials?<p>Now what if you wanted to do all that in a random K8s pod?<p>Yes, of course there are ways to do this, I&#x27;ve pretty much done it all. But I&#x27;ve spent a huge amount of time to figure out each and every step. I&#x27;ve seen dozens of people take the same amount of time to figure it all out, often taking years to truly gather up all the knowledge. You know what would be great? If I didn&#x27;t have to do that. If somebody just said <i>&quot;Here, Product X does everything you will ever want. The docs explain everything. Now you have 600 hours of your life back.&quot;</i>, I would say Take. My. Money. I don&#x27;t even necessarily need a product, if someone could just write down how to do it, so I don&#x27;t have to bang my shins for days to get one thing to work.<p>Fast builds are nice because I can run more builds, but easier builds are nicer because more people can work on containers faster.
评论 #36051043 未加载
FBISurveillancealmost 2 years ago
A happy paying customer. Depot is great and their docker drop-in replacement GitHub Actions are working perfectly, highly recommended. Thanks folks!
chen-andersalmost 2 years ago
Super cool - we&#x27;ve been using Depot in our CI pipelines since Feb and it&#x27;s allowed us to focus on shipping &#x2F; keeping our CI infrastructure simpler. Kyle and Jacob have been super-responsive whenever we&#x27;ve encountered issues.
poulpialmost 2 years ago
Nice!<p>Our docker builds are getting slow despite using kaniko, does depot has a better caching than kaniko?<p>How so?
评论 #36046650 未加载
pugzalmost 2 years ago
I&#x27;ve been using Depot for a while and I&#x27;m a fan. It has made our (GitHub Actions) builds a lot faster because the cache is always warm. It also helps a lot when building amd64 images from my arm64 Macbook - that&#x27;s excruciatingly slow if I just run `docker build`.<p>My only complaint is more about GHA - I wish there was an easier way to build multiple unrelated images at the same time in a single GHA job. Running `depot build &amp;` to background things is a bit fiddly when it comes to interleaved console output, exit codes, etc.
jmeyer2kalmost 2 years ago
So helpful to have a persistent Docker cache across builds. We sped up our Docker builds by 40-50% on average which directly contributes to speeding up our iteration speed. Excited to try the new local option - probably will be awesome for local testing of Docker builds!
kmcquadealmost 2 years ago
Depot is freaking awesome. Sped up two of our Docker image builds from 11 minutes to 1-1.5 minutes and the drop-in Docker build replacement in GitHub Actions was super easy. Can&#x27;t imagine our CI&#x2F;CD system without it.
dsiddharthalmost 2 years ago
We&#x27;re using Depot at Hathora, and it&#x27;s enabled us to focus on our platform development instead of worrying about CI&#x2F;build pipelines. We&#x27;re very happy with the speed improvements we&#x27;re noticing.
revskillalmost 2 years ago
I expect a blog post to deeply explain what does &quot;docker layer&quot; mean and what&#x27;s the best practice to optimize the Dockerfile.
评论 #36053213 未加载
neeh0almost 2 years ago
Why not just using nix build system for that, it can create docker images for years now with a great speed.
评论 #36088660 未加载
rubenfiszelalmost 2 years ago
Happy customer here too at windmill.dev :)
arjun810almost 2 years ago
We’ve also been happily using Depot.
davidjfelixalmost 2 years ago
Awesome work!
NWMathersonalmost 2 years ago
Cool post guys.