Project · 2021–2026
Docker images: gh and dind-buildx
Small images that other teams run in their CI pipelines, rebuilt automatically as upstream releases ship.
Usage
Snapshot. Docker Hub pull counts, lifetime, as of Oct 14, 2026. Docker Hub publishes only a running total per image, and every uncached pull counts, including CI jobs, so one team can account for many pulls.
| Image | Pulls | On Docker Hub since |
|---|---|---|
| maniator/gh | 749,293 | May 2021 |
| maniator/dind-buildx | 65,082 | June 2021 |
| maniator/docker-with-buildx | 33,593 | July 2021 |
Projects that run it
Public projects whose own CI or release tooling runs maniator/gh, each checked in the project’s repository on . Star counts are from the same day.
- NVIDIA Megatron-LM (18,151 stars): the CI job that approves its merge gate runs in the image.
- MockServer (4,989 stars): the default GitHub CLI image in its release scripts, pinned to v2.62.0.
- PingCAP’s CI for TiDB Operator (20 stars): a Prow presubmit job, pinned to v2.100.0.
- CircleCI’s container runner Helm chart (11 stars): the gh executor in its CircleCI config.
A GitHub code search on found 93 public repositories that reference maniator/gh, including the four above. That is a lower bound on references, and it does not count active users: the search sees only indexed default branches. The downstream usage report has the method and its limits.
Most of those repositories are small: 51 of the 93 have no GitHub stars. Of the five with 100 or more, Megatron-LM and MockServer run the image themselves; the other three carry vendored copies of Megatron-LM’s CI files. Stars measure interest in each project; they say nothing about how much the image is used.
maniator/gh: the GitHub CLI in a container
A minimal Alpine image that runs the GitHub CLI anywhere Docker runs, which is handy in pipelines that already work in containers. It ships for amd64, arm64, arm/v7 and arm/v6.
Run it
docker run -it --rm -v ${HOME}:/root -v $(pwd):/gh \
-e GITHUB_TOKEN=<token> maniator/gh <command>Staying current without breaking pins
A nightly build publishes each new GitHub CLI release. The tags are layered so people can choose how much changes under them: latest and rolling v2 / v2.x tags always move to the newest build on a patched base, while exact vX.Y.Z tags stay fixed. Once a week the most recent few exact tags are rebuilt on the patched base, so pinned users still get security fixes; older exact tags are deliberately left frozen, so setups pinned for reproducibility never have their operating system swapped underneath them.
The Dockerfile downloads the GitHub CLI built for the target platform rather than the build machine, mapping Docker’s platform names to the CLI’s release names, so the multi-architecture images ship the right binary.
maniator/dind-buildx: Docker with buildx built in
Docker-in-Docker with the buildx plugin already installed, so pipelines can run any docker buildx command in a container. It is published under two names, maniator/dind-buildx and maniator/docker-with-buildx, plus the GitHub Container Registry.
Run it
docker run --rm \
-e DOCKER_TLS_CERTDIR=/certs \
-v /var/run/docker.sock:/var/run/docker.sock \
-v $(pwd):$(pwd) -w $(pwd) maniator/dind-buildx build .A nightly job looks up the newest stable Docker Engine and buildx releases and tags the image with both versions, for example docker_29.9.0-buildx_0.38.0. The buildx binary is stripped of debug symbols to keep the image small.
How the images are kept healthy
- TrivyScans the images for known vulnerabilities
- hadolint and ShellCheckLint the Dockerfiles and build scripts
- OpenVEXDocuments remaining upstream CVEs and their status for maniator/gh