JPjppittma·Nov 8, 2023
Bazel has this functionality.
https://github.com/bazelbuild/rules_docker#rust_image
In Ko: Easy Go Containersbazelbuild
rules_docker
Starlark2017–2023
bazelbuild / rules_docker
rules_docker
Rules for building and handling Docker images with Bazel
13Distinct people
18Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
Rules for building and handling Docker images with Bazel
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year18 dated mentions
Observed mentions: 2017-09-02 14:03:33 UTC to 2023-11-08 13:44:20 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
18 sourcesMy company uses Bazel's rules docker to build our images: https://github.com/bazelbuild/rules_docker
They're pretty great and have a lot of the caching and parallelism benefits mentioned in the post for free out of the box, along with determinism (which Docker files don't have because you can run arbitrary shell commands). Our backend stack is also built with Bazel so we get a nice tight integration to build our images that is pretty straightforward.
We've also built some nice tooling around this to automatically put our maven dependencies into different layers using Bazel query and buildozer. Since maven deps don't change often we get a lot of nice caching advantages.
In Crafting container images without DockerfilesDid you mean this one? https://github.com/bazelbuild/rules_docker
I was very interested in this Bazel-based way of building containers but its README page says "it is on minimal life support," which does not inspire confidence. How's your experience using it?
In Speed boost achievement unlocked on Docker Desktop 4.6 for MacHave you considered using Bazel to build an artifact that describes your deployment configuration? This is something that I've been thinking about trying to implement for some time. Essentially I want to have a way to support defining service configurations like this:
service_binary(
name = "foobar",
srcs = ["foobar.jsonnet"],
deps = ["//jsonnet/service.jsonnet"],
images = ["//a:image"],
)
Then make it possible to create a class of `*_test` rules that would start up a bunch of docker containers in the same network topology they would exist in prod, run your test in the same netns, then clean everything up. It could look something like this:
cc_integration_test(
name = "...",
services = ["//a", "//b"],
srcs = ["main.cc"]
)
There's some BazelCon talks about people doing similar stu
Read the rest
ff but not actually open sourcing their code.
P.S. if you use rules_docker please feel free to open a PR to add your company to our README: https://github.com/bazelbuild/rules_docker/#adopters
> service_binary
During the last 3 years I've had the pleasure of using Bazel's rules_docker to generate all my container images (https://github.com/bazelbuild/rules_docker).
In a nutshell, rules_docker is a set of build rules for the Bazel build system (https://bazel.build). What's pretty nice about these rules is that they don't rely on a Docker daemon. They are rules that directly construct image tarballs that you can either load into your local Docker daemon or push to a registry.
What's nice about this approach is that image generation works on any operating system. For example, even on a Mac or Windows system that doesn't have Docker installed, you're able to build Linux containers. They are also fully reproducible, meaning that you often don't need to upload layers when pushing (either because they haven't changed, or because some colleague/CI job
Read the rest
already pushed those layers).
I guess rules_docker works fine for a variety of programming languages. I've mainly used it with Go, though.
You can do very fast builds with both Docker, Gradle, and Bazel all of which support caching. Unfortunately for my use case Docker and Gradle don't have the understanding of the source tree needed for effective caching. Docker's caching is built off of the docker context + previous build layer hashes, gradle's caching is very very poorly thought out but - if you use no code generation (lombok, autovalue, Dagger) - it'll work.
Bazel's caching abilities are by far the best I've ever worked with because it understands the full source tree. It can also cache test executions. There's some tests in my code that make sure I'm calling out to crypto libraries correctly and these tests take >30 seconds to execute but almost never change. With bazel I can feel free to write as many of those integration tests as I want since they will only ever be re
Read the rest
run when something effects them (I.E. I change the version of my crypto library).
> Honestly, while the theory is that you can Dockerize your build and you can do remote caching with Bazel I've never seen anyone do it
Yea, you likely don't want to run bazel within a docker container, you want to build a Docker container within bazel [0]. The performance of this way of doing things is much better. My monorepo has >30 services and `docker-compose up --build` was becoming super slow. To address this I've written bazel_compose [1] to obtain the same workflow docker-compose offers you with bazel as your container build system. It also supports a gradual migration scheme and will build both the Dockerfile AND the bazel version of your container to make sure they both start.
Unfortunately the bazel community is mainly populated with companies who are 100x the size of the average and as such they already cant run all of their services on their dev machines and so they don't see the value of something like this. This version of bazel_compose is out of sync with HEAD @ caper but if you're adventurous I'd recommend checking it out. It has extra features to watch all of the source files using ibazel and will automatically build&restart containers (<<10 seconds in my experience) as you edit and save code.
[0] - https://github.com/bazelbuild/rules_docker
[1] - https://github.com/CaperAi/bazel_compose
It is also possible to build docker images with Bazel and rules_docker [1], which doesn't require docker itself, and can run unprivileged. That said, it is not compatible with Dockerfile (obviously) but you can do some cool things such as compose layers individually into a final image.
1. https://github.com/bazelbuild/rules_docker
In Building Containers Without DockerEach dependency appears as a "repository" so as a bazel target it will look like "@<thing>//some/target:file". Everything refers to a dep by it's workspace/repository name and exports a `repository.bzl` or `workspace.bzl` file that your WORKSPACE file `load()`s and calls a function in.
This is pretty standardized and "recommended" by bazel-federation: https://github.com/bazelbuild/bazel-federation
A good example of how this becomes a massive mess: https://github.com/bazelbuild/rules_docker/blob/master/repos...
In Bazel Build System Support for LLVMIf you want to create container images for an application you wrote yourself in a commonly used programming language (Go, Python), consider using Bazel with rules_docker:
https://github.com/bazelbuild/rules_docker
rules_docker allows you to create byte-for-byte reproducible container images on your system, without even having a Docker daemon installed. So much cleaner to use than 'docker build' once you get the hang of it!
In Dockerfile Security Best PracticesAh my apologies - We use Bazel to build our services, and the output artifacts were then pulled into Nix and deployed as Nix packages. Bazel has _excellent_ support taking the same application code and creating Docker images from them (https://github.com/bazelbuild/rules_docker#language-rules), and the tools available for deploying containers is orders of magnitude more feature-full and higher quality than what you get with Nix today. So we no longer have Nix anywhere in our pipeline, and all of our artifacts are now deployed inside containers.
In What Is Nix?Bazel’s rules_docker (https://github.com/bazelbuild/rules_docker) is also capable of stomping out container images without using a Docker daemon. It also has its own freestanding pusher.
Rulesets like rules_go (https://github.com/bazelbuild/rules_go) also support pretty decent cross compilation, meaning that you can, for example, build Linux containers containing Go microservices on your Mac and push them into a registry immediately. All without running VMs/Docker daemons/... on your Mac.
In Building Containers Without DockerBazel is worth looking into as soon as you have dependency graphs that your language's native build system can't deal with efficiently, or you have multiple languages that have dependencies on each other's artifacts.
A pure Go codebase? Not worth it.
Personally, I use Bazel even for small projects as soon as they involve things like generated code or gRPC.
Yes, there are multiple rulesets for deployments, like rules_k8s[1] and rules_docker[2]. Of course, you can easily build your own custom deployment pipeline.
[1]: https://github.com/bazelbuild/rules_k8s
[2]: https://github.com/bazelbuild/rules_docker
In Evaluating Bazel for building FirefoxBazel can natively build images without Docker.
Bazel has many other benefits too like creating a full dependency build graph and fully reproductible builds.
https://bazel.build/
https://github.com/bazelbuild/rules_docker
In Making containers saferA larger problem is that Docker is nearly inherently unreproducible.
Downloading and installing system packages lists, etc.
For this reason, Google doesn't use Docker at all.
It writes the OCI images more or less directly. https://github.com/bazelbuild/rules_docker
In Simple Dockerfile examples are often broken by defaultShowing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.