# awesome-docker stopped being a README and became a Go program > The best-known Docker awesome list now ships a command line tool, a terminal interface, a link checker that talks to the GitHub API, and a generated static site, all derived from a single README. Its only tagged release is from 2015, which tells you nothing about whether it is maintained. **veggiemonk/awesome-docker** — :whale: A curated list of Docker resources and projects - Repository: https://github.com/veggiemonk/awesome-docker - Website: https://average.joe.dev/awesome-docker/ - Stars: 36,939 · Forks: 3,378 - Language: Unknown - License: Apache-2.0 - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/veggiemonk-awesome-docker ## The Go module is the surprise, and it is recent If you have used this list you probably remember a markdown file, and the repository still is one, but it is no longer only that. There is a go.mod declaring the module github.com/veggiemonk/awesome-docker on Go 1.26.3, and the dependency list says what the tool is. Cobra is there for the command line, githubv4 for the GitHub GraphQL API, goldmark for markdown, yaml for configuration, oauth2 for authentication, and two Charm packages, bubbletea and lipgloss, which together are the standard way to build an interactive terminal interface. So the repository now contains a command line program with a TUI mode, built from cmd/, internal/ and scripts/ directories, with golangci and markdownlint configuration and an index.html at the root. The project description still reads as a curated list, which means the most important thing about this repository is not stated in its description. ## One README is the input to the site, the checks and the report The Makefile makes the data flow legible, because it names the inputs and outputs for each target rather than hiding them in a script. The website is generated from the README plus a template, with the output path written out as website/index.html. The health report is generated from the README plus a separate exclusion file, with a cache at config/health_cache.yaml and two report formats, HEALTH_REPORT.md and HEALTH_REPORT.json. The declared dependency lists confirm it: the build depends on the Go sources, the website depends on README.md and the template, and the health targets depend on README.md and the exclude file. The practical consequence for a contributor is narrow but useful. Editing the README is the only edit that matters, and everything a reader sees elsewhere in the repository is a build artefact of that one file, so a pull request that changes a link changes the site and the health report too. ## Link checking costs a GitHub token, and there is a guard target for it The check target validates links and the help text says it uses GITHUB_TOKEN when set, which tells you the checking is not a plain HTTP crawl. The GraphQL dependency is the reason: querying the GitHub API is how you learn whether a linked repository still exists, whether it has been archived, when it was last pushed, and how many stars it has. That is a much stronger check than following an HTTP request and watching for a 404, and it is also the reason there is a target named guard-github-token, which exists to stop a token being committed. The tradeoff is that a maintained list of this kind depends on a third-party API and on a rate limit. The health cache exists precisely because of that, so a run that hits the ceiling can serve the previous result rather than failing. If you are reading a health report, a cached entry is weaker evidence than a fresh one, and the repository does not appear to mark which is which in the output. ## The inclusion rule is a value-proposition test, not a usage test Most lists of this kind accumulate anything that runs in a container, and this one explicitly refuses to. The stated requirement is that the project has to be for Docker, not just using Docker, and the rule of thumb makes the test concrete: if removing the Docker integration would not kill the project's value proposition, it does not belong in the list. That is a genuinely strict filter and it explains the shape of the Engine and Runtime section, which lists containerd, cri-o, runc, youki written in Rust implementing the OCI runtime specification, gVisor as an application kernel for containers, podman, LXC, and a Docker-compatible container CLI for macOS built on Apple's Containerization framework. None of those merely runs inside Docker. The cost of the rule is equally real, though: a project that only recently became container-native may be absent for years, and the list will never be a complete index of containerised software. ## The only release is from 2015, and the README was edited last month The version history is the most misleading thing about the repository, and it is worth resolving explicitly. There is one release listed, v0.8, with the release title given as Stable release, dated 2015-08-07. The repository is not archived and the last push was on 2026-09-12, and the Go module, the TUI dependencies, the health report and the generated site all postdate that tag by years. So the tag describes a state of the project that no longer exists, and a reader who checks releases to judge maintenance will conclude the project is a decade stale when the file it is named for is being edited monthly. The correct signals here are the push history on the default branch, which is master, and the contents of the README. Neither the tag nor the repository description, which still calls this a curated list, is a reliable guide to what is in the tree. ## No payment for placement, and no relationship to Docker the company Three disclaimers sit near the top and together they define what the list is and is not. The creators and maintainers receive no form of payment to accept a change made by any contributor. The page is not an official Docker product in any way. And the stated goal is to index open-source projects rather than to advertise for profit. Those statements together mean the list cannot be read as an endorsement, and the distinction matters more than it might appear, because the Projects section opens with the official projects, naming Moby, Docker Hub, Docker Compose and Docker Registry, which readers may take as a recommendation. The inclusion rule helps here, since a project must be for Docker rather than merely using it, and the official tooling qualifies on that basis. What the disclaimers do not cover is staleness, which is a separate problem and is the one the health tooling was built to address. ## The table of contents is the better documentation of the ecosystem The structure says more about where the Docker world is than any individual entry. The Projects half runs from engine and runtime through building images, split into builder, base images, Dockerfile and linter, then image lifecycle with registry, registry CLI, image scanning and SBOM, and supply chain as its own category. Running containers covers composition, orchestration, deployment and platforms, and garbage collection as a named concern, which tells you the list assumes long-lived hosts rather than ephemeral CI. Then networking and proxies, storage and data, observability, security, user interfaces broken into desktop, terminal, web and IDE integrations, developer workflow from API client through CI/CD, development environment, serverless, testing and wrappers, and finally in-container tooling. Roughly half the document is not a project list at all but learning resources: where to start, a separate Windows starting point, books, awesome lists, demos, Raspberry Pi and ARM, security articles, videos, and communities grouped by language. ## Conclusion Adopt this list as a map of the Docker ecosystem, and treat the CLI as the better way to consume it if you want the entries checked rather than merely listed. Do not judge it by its release tag, which is eleven years old and predates the Go rewrite, and do not use it as a procurement shortlist without following the links, because the project's own rule admits entries whose projects may have changed direction since they were added. Verify first that a given entry still exists and still belongs, which is what the health report is for, and read the contribution rule before assuming a project is missing by accident. ## FAQ ### What is the rule for a project to be listed in awesome-docker? The project has to be for Docker, not just use Docker. The stated rule of thumb is that if removing the Docker integration would not kill the project's value proposition, it does not belong in the list. ### How do I contribute a link to awesome-docker? Read the contribution document first, then edit the README, which is the only source the site, the health report and the checks are generated from. The maintainers state they receive no payment to accept a change from a contributor. ### What does the awesome-docker command line tool do? It is a Go program with a Cobra command line and a terminal interface built on bubbletea and lipgloss. Its checks query the GitHub GraphQL API, and its make targets build the binary, lint the README, check links, and generate both a website and a health report in markdown and JSON. ### Is awesome-docker still maintained? The repository is not archived and the last push was on 2026-09-12, and the Go rewrite postdates the only release tag, v0.8 from 2015-08-07. Judge it by the branch history rather than the tag, which describes a state the project left behind years ago. ## Sources - [Official documentation](https://average.joe.dev/awesome-docker/) - [Official README](https://github.com/veggiemonk/awesome-docker#readme) - [Project repository](https://github.com/veggiemonk/awesome-docker) - [Release notes](https://github.com/veggiemonk/awesome-docker/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/veggiemonk-awesome-docker