TOtosh·Dec 19, 2018Submission
4 points · Open discussionGoogleContainerTools
distroless
Starlark2017–2026
GoogleContainerTools / distroless
distroless
🥑 Language focused docker images, minus the operating system.
67Distinct people
77Mentions
0Explicit recommenders
23.2KGitHub stars
What to know before exploring
What it is
🥑 Language focused docker images, minus the operating system.
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
- googlecontainertools/jib · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:01:40 AM 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 year77 dated mentions
Observed mentions: 2017-06-09 19:58:42 UTC to 2026-08-26 14:20:43 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
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 | 5 | 3 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 9 | 4 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
9 sourcesDistroless: Language focused docker images, minus the operating system
1 points · Open discussionThere’s also google cloud’s distroless project: https://github.com/GoogleContainerTools/distroless
We’ve used the Node.js containers in production and investigated the other languages, but never deployed them. We did have some issues with devops not being able to log into the running containers, but always found a solution that I believe in the end was a better long term pattern for ops.
In Show HN: Smallest Node.js Docker imagesLanguage focused docker images, minus the operating system
2 points · Open discussionBuilding in a container gives you the portability benefit of having tools installed in a container.
But not building in your productiom container makes it smaller.
Dockerfiles can actually do both, via "mutli-stage builds". You can build in one container and in the same Dockerfiles copy files from that build container to your final container.
Some take a really extreme stance where the production container has nothing superfluous, not even a shell.
https://github.com/GoogleContainerTools/distroless
In Introducing Jib — Build Java Docker images betterAnother option for even smaller images is to use distroless: https://github.com/GoogleContainerTools/distroless#examples-...
In How to start a Go project in 2018- We've published libraries to interact with the registry without docker or the docker CLI, which we use in these projects
https://github.com/google/go-containerregistry
https://github.com/google/containerregistry
- Our team has built something exactly like you're describing https://github.com/GoogleCloudPlatform/distroless
Dockerfiles without RUN commands are technically more correct: reproducible, much easier to inspect. However, its quite limiting for the existing corpus of Dockerfiles.
I like to think of kaniko as the (pull) + build + push decoupling of the docker monolith. Other tools, like cri-o, have implemented the complement (pull + run).
Disclaimer: I work on kaniko and some of these other tools at Google
In Kaniko: Build container images in Kubernetes> The ca.crt is there because it triggers desired behavior - e.g. that you can connect to services over SSL without errors. Test that instead.
Awesome example here! We have a test that uses container-structure-test to do exactly this over here: https://github.com/GoogleCloudPlatform/distroless/blob/1ea91...
You can mix and match between tests that check file contents and tests that actually run commands inside the container and make assertions based on their output.
In Container Structure Tests: Unit Tests for Docker Images