GoogleContainerTools

distroless

Starlark2017–2026

GoogleContainerTools / distroless

distroless

🥑 Language focused docker images, minus the operating system.

Explore on GitHub Read Hacker News discussions

67Distinct people

77Mentions

0Explicit recommenders

23.2KGitHub stars

REPOSITORY AT A GLANCE

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, 12:03:30 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 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

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
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

10 sources

ithkuil·Dec 27, 2020

In many cases you don't need 500mb of base image. Minimal "distrofull" images are in the 50mb range. But often you don't really need a real distribution inside your docker image. See https://github.com/GoogleContainerTools/distroless. But distroless is not about one specific tool or base image, it's a paradigm that addresses precisely what you say (without throwing away the whale with the bathwater)

In Run More Stuff in Docker

excieve·Dec 17, 2020

The closest approach to a first class "FROM scratch" is probably distroless[0]. > and a way to configure it to pull only from a local, private registry. One can set up an air-gapped environment with access to a private container registry only. [0] https://github.com/GoogleContainerTools/distroless

In 51% of 4M Docker images have critical vulnerabilities

Garbage·Nov 19, 2020Submission

Distroless: Language focused Docker images, minus the operating system

2 points · Open discussion

theptip·Oct 15, 2020

Further in that direction, https://github.com/GoogleContainerTools/distroless — stripping out as much of the OS code as possible.

In Dockerfile Security Best Practices

minimaxir·Oct 14, 2020

Google's distroless containers are an interesting approach for both security and performance as well, albeit with limited language support: https://github.com/GoogleContainerTools/distroless

In Dockerfile Security Best Practices

mustardo·Jun 16, 2020

My experience with Beanstalk was much the same had the feeling of a lot of hacky Ruby, Python scripts thrown together. Logs in random place, sometimes would get "stuck" Current project uses GCP App Engine "Flexible" which is easier and seems to be built on better foundations than Beanstalk. Build a docker image and run. Although like you we could skip the docker shenanigans and just need a JRE to run our uber .jar (distroless https://github.com/GoogleContainerTools/distroless/tree/mast... makes a basic JVM docker container easy)

In Ask HN: What are your go to SaaS products for startups/MVPs?

lstamour·Feb 28, 2020

Sure thing, but just to clarify a point you might not be making, don't put shells and SSH in your containers: https://github.com/GoogleContainerTools/distroless#why-shoul...

In Using BPF to Transform SSH Sessions into Structured Events

yjftsjthsd-h·Feb 19, 2020

Seems to be a pretty decent overview; covers the usual suspects (multi-stage builds, FROM scratch, non-scratch minmal images, ldd to check libraries), with some nice bits that I'd not seen before (busybox:glibc). I would be curious to see how these base images stack up against Google's "distroless" base images (https://github.com/GoogleContainerTools/distroless). I also appreciate that they call out Alpine's compatibility issues (on account of musl) but still leave it as a thing that can be good if you use it right. (Personally I'm quite fond of Alpine, but I don't bother when using binaries that expect glibc.)

In Reducing Docker Image Size

dr01d·Feb 11, 2020

I would recommend multistage build but with distroless as final. https://github.com/GoogleContainerTools/distroless

In I Was Wrong about Nix

hardwaresofton·Feb 11, 2020

I still don't see the light. I'll try and lay out my reservations, starting with the pain points of the docker image (out of order to coalesce some points): > The package manager’s database is included in the image > Most of the files in the docker image are unrelated to my website’s functionality and are involved with the normal functioning of Linux systems So remove it...? Docker multi-stage builds[0] make this really easy, though I still use separate containers for different times (building, testing, etc), and sometimes even multiple "stages" of containers for languages that take a long time to build (Haskell). > The package manager is included in the image Assuming you don't want the package manager itself, why not just use a scratch[1] or distroless[2] image? Well of course it's harder than one might expect to use those options (dist

Read the rest

roless is actually fine), because of the lie of "statically building" anything on most distros other than alpine, which brings us to the next pain point... > An entire copy of the C library is included in the image (even though the binary was statically linked to specifically avoid this) Using alpine gets you much closer (if not all the way there) to a proper static binary w/ musl libc. You may have to look into things like replacing the use of libnss or certain systemcalls with golang libraries, however[3]. My biggest problem with nix is that it just isn't worth the effort -- The ~5+ paragraphs of nix tools and scripts is just not at all attractive to me personally when I know roughly a day's worth of fiddling to get a proper static build is good enough most of the time. I've heard amazing things about nix, nixops, and all the tools there-in but there just isn't enough pain IMO to warrant completely changing how to do things. Nevermind the fact that disks get cheaper and cheaper, network gets faster and faster, and people are starting to look into pre-emptively sharing container images across meshes of nodes with tools like Dragonfly[4]. Another point that is somewhat related -- if nix is good, guix has to be better on some level (excluding factors like ecosystem) purely because it uses a full-blown language for the config (i.e. terraform vs. pulumi). It doesn't seem like nix will hold enough value before unikernels "arrive", then the problem of taking your distribution along with the program you want to deploy disappears alltogether. [0]: https://docs.docker.com/develop/develop-images/multistage-bu... [1]: https://hub.docker.com/_/scratch/?tab=description [2]: https://github.com/GoogleContainerTools/distroless [3]: https://github.com/golang/go/commit/62f0127d8104d8266d9a3fb5... [4]: https://d7y.io/en-us/docs/userguide/download_files.html

In I Was Wrong about Nix