[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-9962":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":28,"readmeContent":29,"aiSummary":30,"trendingCount":16,"starSnapshotCount":16,"syncStatus":31,"lastSyncTime":32,"discoverSource":33},9962,"distroless","GoogleContainerTools\u002Fdistroless","GoogleContainerTools","🥑  Language focused docker images, minus the operating system.  ","",null,"Starlark",22733,1401,198,10,0,12,35,114,52,44.44,"Apache License 2.0",false,"main",[26,27],"bazel","docker","2026-06-12 02:02:15","# \"Distroless\" Container Images.\n\n[![CI Build Status](https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Fdistroless\u002Factions\u002Fworkflows\u002Fci.yaml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Fdistroless\u002Factions\u002Fworkflows\u002Fci.yaml)\n\n\"Distroless\" images contain only your application and its runtime dependencies.\nThey do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.\n\nFor more information, see this [talk](https:\u002F\u002Fswampup2017.sched.com\u002Fevent\u002FA6CW\u002Fdistroless-docker-containerizing-apps-not-vms?iframe=no&w=100%&sidebar=yes&bg=no) ([video](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=lviLZFciDv4)).\n\n## Why should I use distroless images?\n\nRestricting what's in your runtime container to precisely what's necessary for your app is a best practice employed by Google\nand other tech giants that have used containers in production for many years.\nIt improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.\n\nDistroless images are _very small_.\nThe smallest distroless image, `gcr.io\u002Fdistroless\u002Fstatic-debian12`, is around 2 MiB.\nThat's about 50% of the size of `alpine` (~5 MiB), and less than 2% of the size of `debian` (124 MiB).\n\n## How do I use distroless images?\n\nThese images are built using [bazel](https:\u002F\u002Fbazel.build), but they can also be used through other Docker image build tooling.\n\n### What images are available?\n\nThe following images are currently published and updated by the distroless project (see [SUPPORT_POLICY.md](SUPPORT_POLICY.md) for support timelines)\n\nThese images refer to image indexes with references to all supported architectures. Architecture specific images can be directly referenced using an additional architecture suffix on the tag, like `gcr.io\u002Fdistroless\u002Fstatic-debian12:latest-amd64`\n\nAny other tags are considered deprecated and are no longer updated\n\n#### Debian 12\n\n| Image                                 | Tags                                  | Architecture Suffixes             |\n| ------------------------------------- | ------------------------------------- | --------------------------------- |\n| gcr.io\u002Fdistroless\u002Fstatic-debian12     | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le |\n| gcr.io\u002Fdistroless\u002Fbase-debian12       | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le |\n| gcr.io\u002Fdistroless\u002Fbase-nossl-debian12 | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le |\n| gcr.io\u002Fdistroless\u002Fcc-debian12         | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le |\n| gcr.io\u002Fdistroless\u002Fpython3-debian12    | latest, nonroot, debug, debug-nonroot | amd64, arm64                      |\n\n#### Debian 13\n\nDebian 13 distroless images use the debian [UsrMerge](https:\u002F\u002Fwiki.debian.org\u002FUsrMerge) scheme. If you use `rules_distroless` to add packages to an image, set `mergedusr = True` in [`apt.install`](https:\u002F\u002Fregistry.bazel.build\u002Fdocs\u002Frules_distroless#apt_install).\n\n| Image                                 | Tags                                  | Architecture Suffixes                      |\n| ------------------------------------- | ------------------------------------- | ------------------------------------------ |\n| gcr.io\u002Fdistroless\u002Fstatic-debian13     | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le, riscv64 |\n| gcr.io\u002Fdistroless\u002Fbase-debian13       | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le, riscv64 |\n| gcr.io\u002Fdistroless\u002Fbase-nossl-debian13 | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le, riscv64 |\n| gcr.io\u002Fdistroless\u002Fcc-debian13         | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le, riscv64 |\n| gcr.io\u002Fdistroless\u002Fjava-base-debian13  | latest, nonroot, debug, debug-nonroot | amd64, arm64, s390x, ppc64le, riscv64      |\n| gcr.io\u002Fdistroless\u002Fjava17-debian13     | latest, nonroot, debug, debug-nonroot | amd64, arm64, s390x, ppc64le, riscv64      |\n| gcr.io\u002Fdistroless\u002Fjava21-debian13     | latest, nonroot, debug, debug-nonroot | amd64, arm64, s390x, ppc64le, riscv64      |\n| gcr.io\u002Fdistroless\u002Fjava25-debian13     | latest, nonroot, debug, debug-nonroot | amd64, arm64, s390x, ppc64le, riscv64      |\n| gcr.io\u002Fdistroless\u002Fnodejs22-debian13   | latest, nonroot, debug, debug-nonroot | amd64, arm64, arm, s390x, ppc64le          |\n| gcr.io\u002Fdistroless\u002Fnodejs24-debian13   | latest, nonroot, debug, debug-nonroot | amd64, arm64, s390x, ppc64le               |\n| gcr.io\u002Fdistroless\u002Fpython3-debian13    | latest, nonroot, debug, debug-nonroot | amd64, arm64, riscv64                      |\n\n## Why is distroless still using `gcr.io` instead of `pkg.dev`?\n\nDistroless's serving infrastructure has moved to artifact registry but we still use the `gcr.io` domain. Users will get the benefits of the newer infrastructure without changing their builds.\n\n## How do I verify distroless images?\n\nAll distroless images are signed by [cosign](https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign) with ephemeral keys (keyless). We recommend verifying any distroless image you use before building your image. You can verify the keyless signature of any distroless image with:\n\n```sh\ncosign verify $IMAGE_NAME --certificate-oidc-issuer https:\u002F\u002Faccounts.google.com --certificate-identity keyless@distroless.iam.gserviceaccount.com\n```\n\n### Entrypoints\n\nNote that distroless images by default do not contain a shell.\nThat means the Dockerfile `ENTRYPOINT` command, when defined, must be specified in `vector` form, to avoid the container runtime prefixing with a shell.\n\nThis works:\n\n```dockerfile\nENTRYPOINT [\"myapp\"]\n```\n\nBut this does not work:\n\n```dockerfile\nENTRYPOINT \"myapp\"\n```\n\nFor the same reasons, if the entrypoint is set to the empty vector, the CMD command should be specified in `vector` form (see examples below).\nNote that by default static, base and cc images have the empty vector entrypoint. Images with an included language runtime have a language specific default (see: [java](java\u002FREADME.md#usage), [nodejs](nodejs\u002FREADME.md#usage), [python3](python3\u002FREADME.md#usage)).\n\n### Docker\n\nDocker multi-stage builds make using distroless images easy.\nFollow these steps to get started:\n\n- Pick the right base image for your application stack.\n- Write a multi-stage docker file.\n  Note: This requires Docker 17.05 or higher.\n\n  The basic idea is that you'll have one stage to build your application artifacts, and insert them into your runtime distroless image.\n  If you'd like to learn more, please see the documentation on [multi-stage builds](https:\u002F\u002Fdocs.docker.com\u002Fengine\u002Fuserguide\u002Feng-image\u002Fmultistage-build\u002F).\n\n#### Examples with Docker\n\nHere's a quick example for go:\n\n```dockerfile\n# Start by building the application.\nFROM golang:1.18 as build\n\nWORKDIR \u002Fgo\u002Fsrc\u002Fapp\nCOPY . .\n\nRUN go mod download\nRUN CGO_ENABLED=0 go build -o \u002Fgo\u002Fbin\u002Fapp\n\n# Now copy it into our base image.\nFROM gcr.io\u002Fdistroless\u002Fstatic-debian12\nCOPY --from=build \u002Fgo\u002Fbin\u002Fapp \u002F\nCMD [\"\u002Fapp\"]\n```\n\nYou can find other examples here:\n\n- [Java](examples\u002Fjava\u002FDockerfile)\n- [Python 3](examples\u002Fpython3\u002FDockerfile)\n- [Go](examples\u002Fgo\u002FDockerfile)\n- [Node.js](examples\u002Fnodejs\u002FDockerfile)\n- [Rust](examples\u002Frust\u002FDockerfile)\n\nTo run any example, go to the directory for the language and run:\n\n```sh\ndocker build -t myapp .\ndocker run -t myapp\n```\n\nTo run the [Node.js Express example app](examples\u002Fnodejs\u002Fnode-express) and expose the container's ports:\n\n```sh\nnpm install # Install express and its transitive dependencies\ndocker build -t myexpressapp . # Normal build command\ndocker run -p 3000:3000 -t myexpressapp\n```\n\nThis should expose the Express application to your `localhost:3000`\n\n### Bazel\n\nFor full documentation on how to use bazel to generate Container images, see the [bazel-contrib\u002Frules_oci](https:\u002F\u002Fgithub.com\u002Fbazel-contrib\u002Frules_oci) repository.\n\nFor documentation and example on how to create custom container images, see the [GoogleContainerTools\u002Frules_distroless](https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Frules_distroless) repository.\n\nExamples can be found in the [GoogleContainerTools\u002Frules_distroless](https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Frules_distroless\u002Ftree\u002Fmain\u002Fexamples) repository.\n\n#### Examples with Bazel\n\nWe have some examples on how to run some common application stacks in the \u002Fexamples directory.\nSee here for:\n\n- [Java](examples\u002Fjava\u002FBUILD)\n- [Python 3](examples\u002Fpython3\u002FBUILD)\n- [Go](examples\u002Fgo\u002FBUILD)\n- [Node.js](examples\u002Fnodejs\u002FBUILD)\n\nSee here for examples on how to complete some common tasks in your image:\n\n- [Adding and running as a non-root user](examples\u002Fnonroot)\n- [Including Debian Packages](https:\u002F\u002Fregistry.bazel.build\u002Fdocs\u002Frules_distroless#module_extension-apt)\n- [Including CA certificates](https:\u002F\u002Fregistry.bazel.build\u002Fdocs\u002Frules_distroless#rule-cacerts)\n\nSee here for more information on how these images are [built and released](RELEASES.md).\n\n### Base Operating System\n\nDistroless images are based on Debian 12 (bookworm). Images are explicitly tagged with Debian version suffixes (e.g. `-debian12`). Specifying an image without the distribution will currently select `-debian12` images, but that will change in the future to a newer version of Debian. It can be useful to reference the distribution explicitly, to prevent breaking builds when the next Debian version is released.\n\n### Operating System Updates for Security Fixes and CVEs\n\nDistroless tracks the upstream Debian releases, using [Github actions to automatically generate a pull request when there are updates](https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Fdistroless\u002Fblob\u002Fmain\u002F.github\u002Fworkflows\u002Fupdate-deb-package-snapshots.yml).\n\n### Debug Images\n\nDistroless images are minimal and lack shell access. The `:debug` image set for each language provides a busybox shell to enter.\n\nFor example:\n\n```sh\ncd examples\u002Fpython3\u002F\n```\n\nedit the `Dockerfile` to change the final image to `:debug`:\n\n```dockerfile\nFROM gcr.io\u002Fdistroless\u002Fpython3-debian12:debug\nCOPY . \u002Fapp\nWORKDIR \u002Fapp\nCMD [\"hello.py\", \"\u002Fetc\"]\n```\n\nthen build and launch with a shell entrypoint:\n\n```sh\ndocker build -t my_debug_image .\n```\n\n```sh\n$ docker run --entrypoint=sh -ti my_debug_image\n\n\u002Fapp # ls\nBUILD       Dockerfile  hello.py\n```\n\n> Note: If the image you are using already has a tag, for example `gcr.io\u002Fdistroless\u002Fjava17-debian13:nonroot`, use the tag `debug-\u003Cexisting tag>` instead, for example `gcr.io\u002Fdistroless\u002Fjava17-debian13:debug-nonroot`.\n\n> Note: [ldd](http:\u002F\u002Fman7.org\u002Flinux\u002Fman-pages\u002Fman1\u002Fldd.1.html) is not installed in the base image as it's a shell script, you can copy it in or download it.\n\n### Who uses Distroless?\n\n- [Kubernetes](https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fenhancements\u002Fblob\u002Fmaster\u002Fkeps\u002Fsig-release\u002F1729-rebase-images-to-distroless\u002FREADME.md), since v1.15\n- [Knative](https:\u002F\u002Fknative.dev)\n- [Tekton](https:\u002F\u002Ftekton.dev)\n- [Teleport](https:\u002F\u002Fgoteleport.com)\n- [BloodHound](https:\u002F\u002Fgithub.com\u002FSpecterOps\u002FBloodHound) by [SpecterOps](https:\u002F\u002Fspecterops.io\u002F)\n\nIf your project uses Distroless, send a PR to add your project here!\n\n## Community Discussion\n\n- [distroless-users Google Group](https:\u002F\u002Fgroups.google.com\u002Fforum\u002F#!forum\u002Fdistroless-users)\n- [Kubernetes slack #distroless channel](https:\u002F\u002Fslack.k8s.io\u002F)\n","Distroless项目提供了一种仅包含应用程序及其运行时依赖的精简Docker镜像，去除了操作系统中的多余组件如包管理器和shell。其核心功能在于通过最小化镜像内容来提高安全性、减少潜在漏洞，并且极大程度地减小了镜像大小，例如最小型的静态Debian 12镜像只有约2MiB。这些特性使得Distroless特别适合于需要高度安全性和性能优化的应用部署场景中使用，尤其是在容器化应用而非虚拟机的环境中。支持多种架构并通过Bazel构建，同时也兼容其他Docker构建工具链。",2,"2026-06-11 03:25:49","top_topic"]