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.

Launch HN: Depot (YC W23) – Fast Docker Builds in the Cloud

224 pointsby jacobwgabout 2 years ago
Hey HN! We’re Kyle and Jacob, the founders of Depot (<a href="https:&#x2F;&#x2F;depot.dev">https:&#x2F;&#x2F;depot.dev</a>), a hosted container build service that builds Docker images up to 20x faster than existing CI providers. We run fully managed Intel and Arm builders in AWS, accessible directly from CI and from your terminal.<p>Building Docker images in CI today is slow. CI runners are ephemeral, so they must save and load the cache for every build. They have constrained resources, with limited CPUs, memory, and disk space. And they do not support native Arm or multi-platform container builds, and instead require emulation.<p>Over 4 years of working together, we spent countless hours optimizing and reoptimizing Dockerfiles, managing layer caching in CI, and maintaining custom runners for multi-platform images. We were working around the limitation of multi-platform builds inside of GitHub Actions via QEMU emulation when we thought &quot;wouldn&#x27;t it be nice if someone just offered both an Intel and Arm builder for Docker images without having to run all that infrastructure ourselves&quot;. Around January of 2022 we started working on Depot, designed as the service we wished we could use ourselves.<p>Depot provides managed VMs running BuildKit, the backing build engine for Docker. Each VM includes 16 CPUs, 32GB of memory, and a persistent 50GB SSD cache disk that is automatically available across builds—no saving or loading of layer cache over the network. We launch both native Intel and native Arm machines inside of AWS. This combination of native CPUs, fast networks, and persistent disks significantly lowers build time — we’ve seen speedups ranging from 2x all the way to 20x. We have customers with builds that took three hours before that now take less than ten minutes.<p>We believe that today we are the fastest hosted build service for Docker images, and the only hosted build service offering the ability to natively build multi-platform Docker images without emulation.<p>We did a Show HN last September: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33011072" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33011072</a>. Since then, we have added the ability to use Depot in your own AWS account; added support for Buildx bake; increased supported build parallelism; launched an eu-central-1 region; switched to a new mTLS backend for better build performance; simplified pricing and added a free tier; and got accepted into YC W23!<p>Depot is a drop-in replacement for `docker buildx build`, so anywhere you are running `docker build` today, you replace it with `depot build` and get faster builds. Our CLI is wrapping the Buildx library, so any parameters you pass to your Docker builds today are fully compatible with Depot. We also have a number of integrations that match Docker integrations inside of CI providers like GitHub Actions.<p>We’re soon launching a public API to programmatically build Docker images for companies that need to securely build Docker images on behalf of their customers.<p>You can sign up at <a href="https:&#x2F;&#x2F;depot.dev&#x2F;sign-up">https:&#x2F;&#x2F;depot.dev&#x2F;sign-up</a>, and we have a free tier of 60 build minutes per month. We would love your feedback and look forward to your comments!

32 comments

fidgewidgeabout 2 years ago
Congrats on hitting the front page. As someone perhaps one step away from your target market, can you please explain how the value prop here really works? You charge $49&#x2F;month for 50GB of disk cache, 32GB of RAM and 16 vCPUs along with a bit of custom tooling on top. For 44 EUR&#x2F;month I can get a dedicated Hetzner machine with a terabyte of disk, 64 GB of RAM and 6 dedicated cores (12 with SMT), and no user or project limits. Because it has so much more disk and RAM, and because builds tend to be disk&#x2F;ram&#x2F;bandwidth limited, performance is probably competitive.<p>You say that this is meant to solve problems with CI being ephemeral. Maybe I&#x27;m old fashioned, but my own CI cluster uses dedicated hardware and nothing is ephemeral. It could also use dedicated VMs and the same thing would apply. We run TeamCity and the agents are persistent, builds run in dedicated workspaces so caching is natural and easy. This doesn&#x27;t cost very much.<p>When you add more features then I can see there&#x27;s some value there (SBOM etc) but then again, surely such features are more easily done by standalone tools rather than having to rent infrastructure from you.
评论 #34901651 未加载
评论 #34909908 未加载
rubenfiszelabout 2 years ago
We&#x27;ve been very happy customer at <a href="https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill">https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill</a>, all of our docker builds are on depot and it replaced our fleet of github runners on hetzner :)
评论 #34898657 未加载
ashishbabout 2 years ago
Docker builds are not slow if you do them properly<p>1. Add layers properly, so that, the most changing code appears towards bottom.<p>2. Use a builder pattern where you build in one image and then copy the output binary into the second image (<a href="https:&#x2F;&#x2F;ashishb.net&#x2F;tech&#x2F;docker-101-a-basic-web-server-displaying-hello-world&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ashishb.net&#x2F;tech&#x2F;docker-101-a-basic-web-server-displ...</a>)<p>3. Use Docker layer caching on GitHub Actions or your favorite CI(<a href="https:&#x2F;&#x2F;evilmartians.com&#x2F;chronicles&#x2F;build-images-on-github-actions-with-docker-layer-caching" rel="nofollow">https:&#x2F;&#x2F;evilmartians.com&#x2F;chronicles&#x2F;build-images-on-github-a...</a>)<p>IMHO, hadolint is a good docker linter but there is no tool in the market that helps people optimize docker images.
评论 #34905875 未加载
paulgbabout 2 years ago
Congrats on the launch!<p>We&#x27;ve been using Depot with Plane (<a href="https:&#x2F;&#x2F;plane.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;plane.dev&#x2F;</a>). Prior to depot, I had to disable arm64 builds because they slowed the build down so much (30m+) on GitHub&#x27;s machines. With Depot, we get arm64 and amd64 images in ~2m.
abatiloabout 2 years ago
I&#x27;ve had a few chats with Kyle and Jacob over the last few months.<p>They&#x27;re incredibly knowledgeable about the subject and are making amazing strides for build speeds. I&#x27;d encourage anyone who doesn&#x27;t believe these results and benchmarks to just try it out. They&#x27;re completely real and it&#x27;s delightful.
MuffinFlavoredabout 2 years ago
Congrats on the launch!<p>Sorry to ask this silly question, but since your team is an expert in the &quot;fast Docker images&quot; 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&#x2F;Docker image)? Is that what Depot is doing at a high level? Was this considered?<p>&gt; Our CLI is wrapping the Buildx library<p>I&#x27;m surprised you&#x27;re able to build Docker images faster than Docker using their code&#x2F;libraries?
评论 #34899214 未加载
评论 #34899132 未加载
moabuaboudabout 2 years ago
We, at <a href="https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces">https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces</a>, had been using Depot.<p>Before depot we faced extreme slow builds for ARM-based images on github machines. However, using Depot helped us reduce the image build time from 2 hours (with an emulator) to just 3 minutes.<p>Emulator: <a href="https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces&#x2F;actions&#x2F;runs&#x2F;3913516949">https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces&#x2F;actions&#x2F;runs&#x2F;39...</a>,<p>Depot: <a href="https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces&#x2F;actions&#x2F;runs&#x2F;4007791613&#x2F;jobs&#x2F;6881116229">https:&#x2F;&#x2F;github.com&#x2F;activepieces&#x2F;activepieces&#x2F;actions&#x2F;runs&#x2F;40...</a>.
评论 #34916547 未加载
评论 #34903557 未加载
jensneuseabout 2 years ago
It&#x27;s great to see others invest in fast CI as well! Amazing product, quite similar to our stack. We&#x27;re using Firecracker (fly.io Machines) and Podman to build docker containers. Our baseline is 13 seconds to deploy a change, including git clone and docker push (4s usually). Here&#x27;s a link to a short video: <a href="https:&#x2F;&#x2F;wundergraph.com&#x2F;blog&#x2F;wundergraph_cloud_announcement#ship-code-in-as-little-as-13-seconds,-enabling-more-than-just-rapid-iteration" rel="nofollow">https:&#x2F;&#x2F;wundergraph.com&#x2F;blog&#x2F;wundergraph_cloud_announcement#...</a><p>We&#x27;re soon going to post a blog on how we&#x27;ve built this pipeline. Lots on interesting details to share on how to make docker builds fast.
评论 #34904049 未加载
mnapoliabout 2 years ago
Happy Depot user here, our builds are now 10 to 20 times faster: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;matthieunapoli&#x2F;status&#x2F;1620090744408244224" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;matthieunapoli&#x2F;status&#x2F;162009074440824422...</a>
mmastracabout 2 years ago
If ARM continues to take off, this will be a pretty useful tool. I&#x27;m building Rust native binaries for one of my projects using buildx, but it&#x27;s 1) way too slow using buildx emulation and 2) way too slow to build on the Pi itself.<p>In the end I created a hacky build process where I use a single container to build both the x64 and ARM versions serially, and then create multi-arch containers in a separate step. It was very painful to get the right native libraries installed, and it&#x27;s not terribly easy to build these two platforms in parallel.<p>In short, having access to real ARM builders would be great, and persistent disks would probably boost my build performance quite a bit.<p>The dockerfile that I had to use: <a href="https:&#x2F;&#x2F;github.com&#x2F;mmastrac&#x2F;progscrape&#x2F;blob&#x2F;master&#x2F;Dockerfile">https:&#x2F;&#x2F;github.com&#x2F;mmastrac&#x2F;progscrape&#x2F;blob&#x2F;master&#x2F;Dockerfil...</a><p>Example build run (~20 mins): <a href="https:&#x2F;&#x2F;github.com&#x2F;mmastrac&#x2F;progscrape&#x2F;actions&#x2F;runs&#x2F;4228529821&#x2F;jobs&#x2F;7344065110">https:&#x2F;&#x2F;github.com&#x2F;mmastrac&#x2F;progscrape&#x2F;actions&#x2F;runs&#x2F;42285298...</a>
评论 #34898634 未加载
lxeabout 2 years ago
&gt; Building Docker images in CI today is slow. CI runners are ephemeral, so they must save and load the cache for every build.<p>&gt;...persistent disks significantly lowers build time<p>Does this mean your solution places specific caches, like bazel, node_modules, .yarn, and other intermediary artifacts onto a shared volume and reuses them among jobs?
评论 #34900417 未加载
评论 #34900330 未加载
caleblloydabout 2 years ago
Satisfied Depot customer here! Jacob was super responsive when I had questions about how to integrate with &quot;docker buildx bake&quot;. The product works great, it has cut our Docker image build times from 15 minutes previously on GitHub Actions down to 3 minutes on Depot.
markdrew74about 2 years ago
This has been an amazing tool and has been speeding up our builds. What is normally a long process is done in seconds. We wait more time for the repo (sideyes at bitbucket) than for depot! Great work Kyle and Jacob!
amitizleabout 2 years ago
Congrats on the launch.<p>We&#x27;ve been using Depot for the past two months, and without changing anything the builds became faster (compared to our CI).<p>Good luck Depot team and keep up the good work!
chasemgrayabout 2 years ago
Been using this for several months now and it&#x27;s helped improve our build pipelines significantly! We are planning to integrate it with more of our tooling soon.
cultofmetatronabout 2 years ago
OMG, you guys came at a good time. My entire team was having a cathartic groanfest over how slow the build phase of our CI had been getting. just sent this to our devops guy to try this out and see if it improves things. our CI builds typically take around 8-12 minutes. would love to cut that down
评论 #34907308 未加载
121wattsabout 2 years ago
Congrats y’all! Great bunch of humans building cool things.
DAlperinabout 2 years ago
This is super cool! Do you have any plans to support on-demand image building like the now defunct <a href="https:&#x2F;&#x2F;ctr.run" rel="nofollow">https:&#x2F;&#x2F;ctr.run</a>? It seems like with your speed it&#x27;s kind of a perfect match.
评论 #34902939 未加载
qrushabout 2 years ago
Big fans of Depot here at Wistia, keep it up!!
neuronexmachinaabout 2 years ago
Do you have a timeline for supporting Google Cloud and their Arm-based Tau VMs?
评论 #34902885 未加载
评论 #34912683 未加载
kashnoteabout 2 years ago
This looks interesting! Congrats on the launch. Question, though, why is it asking for credit card information for the free tier? Would be nice to try it first without giving my card info.
评论 #34900029 未加载
评论 #34899938 未加载
jiggawattsabout 2 years ago
AFAIK most orgs that use something like Azure DevOps pipelines for builds will deploy a VM Scale Set Agent Pool with the runner image. This provides layer caching and incremental builds. Ref: <a href="https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;azure&#x2F;devops&#x2F;pipelines&#x2F;agents&#x2F;scale-set-agents?view=azure-devops" rel="nofollow">https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;azure&#x2F;devops&#x2F;pipelines&#x2F;age...</a><p>What’s the advantage of your platform over this?
评论 #34903997 未加载
Serow225about 2 years ago
Any chance of offering GitHub Runners as a tweak of the underlying “hard parts”? I’ve had really good luck with this type of offering from BuildJet, except that they don’t offer any ability to have persistent volume between runners. So all of our builds are fast _except_ the ones that build containers, but it’s too much of a pain to have some stuff in GitHub Actions with 3rd party hosted runner and then a totally different system for container builds&#x2F;test workflows.
评论 #34911904 未加载
nodesocketabout 2 years ago
Congratulations on the launch. I am currently using GitHub actions and docker&#x2F;setup-qemu-action@master. Then just call docker buildx with the platform arg. This works, except the builds do take a while since it’s running on Intel emulated arm64 (Microsoft booo).<p>What happens when GitHub adds native arm support though? Seems like a big value add of your service is immediately displaced and additionally can use self-hosted runners with GitHub to solve caching.
评论 #34899442 未加载
mynameisvladabout 2 years ago
I saw this while checking out Moon yesterday and looked great. I spun up my own GH runner because arm64 builds were taking up so much time and eating into my credit.<p>But the pricing hurts for people that need more than 60 minutes of build time (which is pretty easy to go through in one month) but would be using it for personal projects like myself.<p>I could certainly see myself paying X&#x2F;min over 60, but $49+5c&#x2F;min for personal stuff is a hard no.
评论 #34899760 未加载
eatonphilabout 2 years ago
&gt; And they do not support native Arm or multi-platform container builds<p>What&#x27;s the issue with <a href="https:&#x2F;&#x2F;docs.docker.com&#x2F;build&#x2F;building&#x2F;multi-platform&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.docker.com&#x2F;build&#x2F;building&#x2F;multi-platform&#x2F;</a>? I only just learned about this today but I&#x27;ve already got it building cross-platform images correctly in Github Actions.
评论 #34900248 未加载
评论 #34900326 未加载
user3939382about 2 years ago
My immediate reaction is, does this offer a feature incentive to use this when I already have this in AWS CodePipeline+CodeBuild?
评论 #34899440 未加载
mxcrbnabout 2 years ago
Thanks guys for building depot, it makes things easier and faster for us (aws graviton users)
programmarchyabout 2 years ago
Sounds like this could solve the woes I’ve been having building x86 images on my M1. Docker emulation via qemu is still really buggy.
评论 #34901560 未加载
mrwnmonmabout 2 years ago
Lovely design... but on my 14&#x27; laptop, the page literally takes the whole screen.
whatsuabout 2 years ago
I registered using google auth and still have to confirm my email, is that correct?
vigneshaabout 2 years ago
Congrats on the launch,