Hi. Yes, we fully intend to open up access to the build tool here. The build file you see is a new format that we've built to be able to do reproducible builds. It's a new frontend on top of buildkit so you can use it with docker build. The team is currently working hard to provide access to this tooling which will enable you to create, build and modify the images in your environment. We just need a couple more days for this to be available.
You do not need a custom buildkit frontend to do reproducible builds with any modern container build system, including docker.
Vanilla docker/buildkit works just fine as we use it in Stagex with just makefiles and Containerfiles which makes it super easy for anyone to reproduce our images with identical digests, and audit the process. The only thing non default we do to docker is have it use the containerd backend that comes with docker distributions since that allows for deterministic digests without pushing to a registry. This lets us have the same digests across all registries.
Additionally our images are actually container native meaning they are "from scratch" all the way down avoiding any trust in upstream build systems like Debian or Alpine or any of their non deterministic package management schemes or their single-point-of-failure trust in individual maintainers.
We will also be moving to LLVM native builds shortly removing a lot of the complexity with multi-arch images for build systems. Easily cross compile all the things from one image.
Honestly we would not at all be mad if Docker just white labeled these as official images as our goal is just to move the internet away from risky and difficult to audit supply chains as opposed to the "last mile" supply chain integrity that is the norm in all other solutions today.
Hi, I work at Docker. Really appreciate the thoughtful discussion here. We’re excited to make Hardened Images free and open because we believe secure-by-default should be the starting point for every developer, not something you bolt on later.
A big part of this for us is transparency. That’s why every image ships with VEX statements, extensive attestations, and all the metadata you need to actually understand what you’re running. We want this to be a trustworthy foundation, not just a thinner base image.
We’re also extending this philosophy beyond base images into other content like MCP servers and related components, because the more of the stack that is verifiable and hardened by default, the better it is for the ecosystem.
A few people in the thread asked how this is sustainable. The short answer is that we do offer an enterprise tier for companies that need things like contractual continuous patching SLAs, regulated-industry variants (FIPS, etc.), and secure customizations with full provenance and attestations. Those things carry very real ongoing costs, so keeping them in Enterprise allows us to make the entire hardened catalog free for the community.
Glad to see the conversation happening here. We hope this helps teams ship software with a stronger security posture and a bit more confidence.
This is a new format that we've built to be able to do reproducible builds. It's a new frontend on top of buildkit so you can use it with docker build. The team is currently working hard to provide access to this tooling which will enable you to create, build and modify the images in your environment. We just need a couple more days for this to be available.
Don't you personally feel disgust mentioning AI stuff?
Yeah, I realize it is mandatory to mention AI today in every piece of communication of any company; but on a personal level, isn't that something that requires a bit of dying every time?
Hi all, Tushar from Docker here. We’re sorry about the impact our current outage is having on many of you. Yes, this is related to the ongoing AWS incident and we’re working closely with AWS on getting our services restored. We’ll provide regular updates on dockerstatus.com .
We know how critical Docker Hub and services are to millions of developers, and we’re sorry for the pain this is causing. Thank you for your patience as we work to resolve this incident. We’ll publish a post-mortem in the next few days once this incident is fully resolved and we have a remediation plan.
Part of me hopes that we find out that Dynamo DB (which sounds like was the root of the cascading failures) is shipped in a Docker image which is hosted on Docker Hub :-D
