[pull] master from veggiemonk:master

.gitattributes

@@ -1,2 +1,2 @@
 *.css linguist-vendored
-*.* linguist-language=Markdown
+* linguist-language=Markdown

.github/CODEOWNERS

@@ -1 +1 @@
-*.md @veggiemonk @agebhar1 @dmitrytokarev @gesellix @mashb1t @moshloop @vegasbrianc @noteed
+* @veggiemonk @agebhar1 @dmitrytokarev @gesellix @mashb1t @moshloop @vegasbrianc @noteed

.github/CONTRIBUTING.md

@@ -1,94 +1,90 @@
 # Contributing to awesome-docker
 
-First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
+Thanks for taking the time to contribute.
 
-However, for those individuals who want a bit more guidance on the best way to contribute to the project, read on. This document will cover what we're looking for. By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.
+This repository is a curated list of Docker/container resources plus a Go-based maintenance CLI used by CI. Contributions are welcome for both content and tooling.
 
-We appreciate and recognize [all contributors](https://github.com/veggiemonk/awesome-docker/graphs/contributors).
+Please read and follow the [Code of Conduct](./CODE_OF_CONDUCT.md).
 
-Please note that this project is released with a [Contributor Code of Conduct](https://github.com/veggiemonk/awesome-docker/blob/master/.github/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
+## What We Accept
 
-# Table of Contents
+- New high-quality projects that are **for Docker** (see the test below)
+- Fixes to descriptions, ordering, or categorization
+- Removal of broken, archived, deprecated, or duplicate entries
 
-- [Mission Statement](#mission-statement)
-- [Quality Standards](#quality-standards)
-- [Contribution Guidelines](#contribution-guidelines)
-- [New Collaborators](#new-collaborators)
+## The "for Docker" Test (read this before submitting)
 
-# Mission Statement
+This list is for projects whose purpose is to make working with Docker better.
+It is **not** a directory of "software you can run in a container" — that's most
+software ever written. Before opening a PR, apply this test:
 
-`awesome-docker` is a hand-crafted list for high-quality information about Docker and its resources. It should be related or compatible with Docker or containers. If it's just an image built on top of Docker, the project possibly belongs to other [awesome lists](https://github.com/sindresorhus/awesome). You can check the [awesome-selfhosted list](https://github.com/Kickball/awesome-selfhosted) or the [awesome-sysadmin list](https://github.com/n1trux/awesome-sysadmin) as well.
-If it's a **tutorial or a blog post**, they get outdated really quickly so we don't really put them on the list but if it is on a very advanced and/or specific topic, we will consider it!
-If something is awesome, share it (pull request or [issue](https://github.com/veggiemonk/awesome-docker/issues/new) or [chat](https://gitter.im/veggiemonk/awesome-docker)), let us know why and we will help you!
+> **If you removed the Docker integration, would the project still have a reason to exist?**
+>
+> - **Yes, it would** → it's a general tool that happens to use Docker. **Reject.**
+> - **No, the project is *about* Docker** → it belongs here.
 
-# Quality Standards
+### Examples
 
-Note that we can help you achieve those standards, just try your best and be brave.
-We'll guide you to the best of our abilities.
+| Project shape                                                                       | Verdict       | Why                                                                                                  |
+| ----------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------- |
+| Tool that monitors **containers**, container resources, or container logs           | ✅ Accept     | Its value disappears if you take Docker away.                                                        |
+| Tool that monitors **a host / server / service** and happens to ship as Docker      | ❌ Reject     | Its job is monitoring; Docker is just the delivery vehicle.                                          |
+| Reverse proxy that **auto-configures from Docker labels/events**                    | ✅ Accept     | Tightly coupled to the Docker API.                                                                   |
+| Reverse proxy that just *runs in* Docker and configures from a static YAML file     | ❌ Reject     | Same proxy works fine without Docker.                                                                |
+| Dockerfile linter, image scanner, registry, BuildKit frontend, runtime, SDK         | ✅ Accept     | Object of work is the Docker image, daemon, or socket.                                               |
+| General IaC scanner that **happens to read Dockerfiles** among many formats         | ⚠️ Borderline | Allowed if Docker support is a first-class feature, not an afterthought.                             |
+| "Awesome 150 web apps deployable with `docker run`"                                 | ❌ Reject     | Belongs in `awesome-selfhosted`; Docker is incidental.                                               |
+| Cron / privilege-drop / health-check utility designed for **container init**        | ✅ Accept     | Solves a problem that only exists *because* of how containers are built.                             |
+| Generic KV store / service mesh / cluster scheduler that supports Docker            | ❌ Reject     | Existed before Docker, works without it.                                                             |
+| Tutorial, video, or book whose **subject** is Docker                                | ✅ Accept     | Under Useful Resources / Videos / Where to start.                                                    |
+| Tutorial that uses Docker as a setup step for an unrelated topic                    | ❌ Reject     | Belongs with the unrelated topic.                                                                    |
 
-To be on the list, it would be **nice** if entries adhere to these quality standards:
+### One-sentence sanity check
 
-- It should take less than 20 sec to find what is the project, how to install it and how to use it.
-- Generally useful to the community.
-- A project on GitHub with a well documented `README.md` file and plenty of examples is considered high quality.
-- Clearly stating if an entry is related to (Linux) containers and not to Docker. There is an [awesome list](https://github.com/Friz-zy/awesome-linux-containers) for that.
-- Clearly stating "what is it" i.e. which category it belongs to.
-- Clearly stating "what is it for" i.e. mention a real problem it solves (even a small one). Make it clear for the next person.
-- If it is a **WIP** (work in progress, not safe for production), please mention it. (Remember the time before Docker 1.0 ? ;-) )
-- Always put the link to the GitHub project instead of the website!
+Write the sentence: *"This project exists to ____."*
+If the blank doesn't contain **Docker, container, image, registry, Dockerfile, Compose, Swarm, BuildKit, or OCI** — it probably doesn't belong here.
 
-To be on the list, the project **must** have:
+## README Entry Rules
 
-- How to setup/install the project
-- How to use the project (examples)
+- Use one link per entry.
+- Prefer GitHub project/repository URLs over marketing pages.
+- Keep entries alphabetically sorted within their section (case-insensitive).
+- Keep descriptions concise and concrete: one sentence, lead with the verb.
+- **The description should make the Docker connection obvious.** "Monitor
+  unhealthy containers" is good; "Monitor your services" is not — the latter
+  could be any monitoring tool, and a reviewer can't tell whether the project
+  passes the test above.
+- Use `:yen:` for paid/commercial services.
+- The project has been active in the last 2 years.
+- Do not use `:skull:`; archived/deprecated projects should be removed.
+- Avoid duplicate links and redirect variants.
 
-If your PR is not merged, we will tell you why so that you may be able to improve it.
-But usually, we are pretty relaxed people, so just come and say hi, we'll figure something out together.
+## Local Validation
 
-# Contribution Guidelines
+```bash
+# Build CLI
+make build
 
-## I want to share a project, what should I do?
+# Validate README formatting and content
+make lint
 
-- **Adding to the list:** Submit a pull request or open an [issue](https://github.com/veggiemonk/awesome-docker/issues/new)
-- **Removing from the list:** Submit a pull request or open an [issue](https://github.com/veggiemonk/awesome-docker/issues/new)
-- Changing something else: Submit a pull request or open an [issue](https://github.com/veggiemonk/awesome-docker/issues/new)
-- Don't know what to do: Open an [issue](https://github.com/veggiemonk/awesome-docker/issues/new) or join our [chat](https://gitter.im/veggiemonk/awesome-docker), let us know what's going on.
+# Run code tests (when touching Go code)
+make test
 
-**join the chat:**
+# Optional: full external checks (requires GITHUB_TOKEN)
+./awesome-docker check
+./awesome-docker validate
+```
 
-[![Join the chat at https://gitter.im/veggiemonk/awesome-docker](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/veggiemonk/awesome-docker)
+## Pull Request Expectations
 
-or you can
+- Keep the PR focused to one logical change.
+- Explain what changed and why.
+- If adding entries, include the target category.
+- If removing entries, explain why (archived, broken, duplicate, etc.).
 
-**ping us on Twitter:**
+## Maintainer Notes
 
-* [veggiemonk](https://twitter.com/veggiemonk)
-* [idomyowntricks](https://twitter.com/idomyowntricks)
-* [gesellix](https://twitter.com/gesellix)
-* [dmitrytokarev](https://twitter.com/dmitrytok)
-
-### Rules for Pull Request
-
-- Each item should be limited to one link, no duplicates, no redirection (careful with `http` vs `https`!)
-- The link should be the name of the package or project or website
-- Description should be clear and concise (read it out loud to be sure)
-- Description should follow the link, on the same line
-- Entries are listed alphabetically, please respect the order
-- If you want to add more than one link, please don't do all PR on the exact same line, it usually results in conflicts and your PR cannot be automatically merged...
-
-Please contribute links to packages/projects you have used or are familiar with. This will help ensure high-quality entries.
-
-#### Your commit message will be a [tweet](https://twitter.com/awesome_docker) so write a [good commit message](https://chris.beams.io/posts/git-commit/), keep that in mind :)
-
-# New Collaborators
-
-If you just joined the team of maintainers for this repo, first of all: WELCOME!
-
-If it is your first time maintaining an open source project, read the [best practice guides for maintainers](https://opensource.guide/best-practices/).
-
-Here are the few things you need to know:
-* We don't push directly to the master branch. Every entry **MUST** be reviewed!
-* Each entry should be in accordance to this quality standards and contribution guidelines.
-* To ask a contributor to make a change, just copy paste this message [here](https://github.com/veggiemonk/awesome-docker/pull/289#issuecomment-285608004) and change few things like names and stuff. **The main idea is to help people making great projects.**
-* If something seems weird, i.e. if you don't understand what a project does or the documentation is poor, don't hesitate to (nicely) ask for more explanation (see previous point).
-* Say thank you to people who contribute to this project! It may not seems like much but respect and gratitude are important :D
+- Changes should be reviewed before merge.
+- Prefer helping contributors improve a PR over silently rejecting it.
+- Keep `.github` documentation and workflows aligned with current tooling.

.github/ISSUE_TEMPLATE/add-a-project.md

@@ -0,0 +1,20 @@
+---
+name: Add a project
+about: Suggest a project for the list
+title: "add: [PROJECT] in [SECTION]"
+labels: pending-evaluation
+---
+# IF THE PROJECT JUST RUNS IN DOCKER, AUTOMATICALLY DENIED
+
+- [ ] I HAVE READ .github/CONTRIBUTING.md
+
+Write the sentence: *"This project exists to ____."*
+
+If the blank doesn't contain **Docker, container, image, registry, Dockerfile, Compose, Swarm, BuildKit, or OCI**, it probably doesn't belong here.
+
+```markdown
+[REPO](https://github.com/AUTHOR/REPO) - DESCRIPTION.
+```
+
+
+Note: the project will be added faster if you create a PR (recommended!).

.github/MAINTENANCE.md

@@ -0,0 +1,81 @@
+# Maintenance Guide
+
+This guide describes how maintainers keep the list and automation healthy.
+
+## Automated Workflows
+
+### Pull Requests / Weekly QA (`pull_request.yml`)
+
+- Runs on pull requests and weekly on Saturday.
+- Builds the Go CLI and runs `./awesome-docker validate`.
+
+### Broken Links Report (`broken_links.yml`)
+
+- Runs weekly on Saturday and on manual trigger.
+- Executes `./awesome-docker check`.
+- Opens/updates a `broken-links` issue when problems are found.
+
+### Weekly Health Report (`health_report.yml`)
+
+- Runs weekly on Monday and on manual trigger.
+- Executes `./awesome-docker health` then `./awesome-docker report`.
+- Opens/updates a `health-report` issue.
+
+### Deploy to GitHub Pages (`deploy-pages.yml`)
+
+- Runs on pushes to `master` and manual trigger.
+- Builds website with `./awesome-docker build` and publishes `website/`.
+
+## Day-to-Day Commands
+
+```bash
+# Build CLI
+make build
+
+# README lint/validation
+make lint
+
+# Auto-fix formatting issues
+./awesome-docker lint --fix
+
+# Link checks and health checks (requires GITHUB_TOKEN)
+make check
+make health
+make report
+```
+
+## Content Maintenance Policy
+
+- Remove archived/deprecated projects instead of tagging them.
+- Remove broken links that cannot be fixed.
+- Keep sections alphabetically sorted.
+- Keep descriptions short and actionable.
+
+## Suggested Review Cadence
+
+### Weekly
+
+- Triage open `broken-links` and `health-report` issues.
+- Merge straightforward quality PRs.
+
+### Monthly
+
+- Review sections for stale/duplicate entries.
+- Re-run `check` and `health` manually if needed.
+
+### Quarterly
+
+- Review `.github` docs and templates for drift.
+- Confirm workflows still match repository tooling and policies.
+
+## Contributor Support
+
+When requesting PR changes, be explicit and actionable:
+
+- point to section/order problems,
+- explain why a link should be removed,
+- suggest exact wording when description quality is the issue.
+
+---
+
+Last updated: 2026-02-27

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,51 +1,11 @@
-<!-- Congrats on creating an Awesome Docker entry! 🎉 -->
 
-<!-- **Remember that entries are ordered alphabetically** -->
+# IF THE PROJECT JUST RUNS IN DOCKER, AUTOMATICALLY DENIED
 
-<!-- 
-TLDR: 
- * all entries sorted alphabetically,  
- * If paying service add :heavy_dollar_sign:
- * If WIP add :construction: 
- * clear and short description of the project
- * project MUST have: How to setup/install
- * project MUST have: How to use (examples)
- * we can help you get there :)
--->
+- [ ] I HAVE READ .github/CONTRIBUTING.md
 
-# Quality Standards
+Write the sentence: *"This project exists to ____."*
 
-Note that we can help you achieve those standards, just try your best and be brave.
-We'll guide you to the best of our abilities.
+If the blank doesn't contain **Docker, container, image, registry, Dockerfile, Compose, Swarm, BuildKit, or OCI**, it probably doesn't belong here.
 
-To be on the list, it would be **nice** if entries adhere to these quality standards:
+What changed and why:
 
-- It should take less than 20 sec to find what is the project, how to install it and how to use it.
-- Generally useful to the community.
-- A project on GitHub with a well documented `README.md` file and plenty of examples is considered high quality.
-- Clearly stating if an entry is related to (Linux) containers and not to Docker. There is an [awesome list](https://github.com/Friz-zy/awesome-linux-containers) for that.
-- Clearly stating "what is it" i.e. which category it belongs to.
-- Clearly stating "what is it for" i.e. mention a real problem it solves (even a small one). Make it clear for the next person.
-- If it is a **WIP** (work in progress, not safe for production), please mention it. (Remember the time before Docker 1.0 ? ;-) )
-- Always put the link to the GitHub project instead of the website!
-
-To be on the list, the project **must** have:
-
-- How to setup/install the project
-- How to use the project (examples)
-
-If your PR is not merged, we will tell you why so that you may be able to improve it.
-But usually, we are pretty relaxed people, so just come and say hi, we'll figure something out together.
-
-# Rules for Pull Request
-
-- Each item should be limited to one link, no duplicates, no redirection (careful with `http` vs `https`!)
-- The link should be the name of the package or project or website
-- Description should be clear and concise (read it out loud to be sure)
-- Description should follow the link, on the same line
-- Entries are listed alphabetically, please respect the order
-- If you want to add more than one link, please don't do all PR on the exact same line, it usually results in conflicts and your PR cannot be automatically merged...
-
-Please contribute links to packages/projects you have used or are familiar with. This will help ensure high-quality entries.
-
-#### Your commit message will be a [tweet](https://twitter.com/awesome_docker) so write a [good commit message](https://chris.beams.io/posts/git-commit/), keep that in mind :)

.github/dependabot.yml

@@ -0,0 +1,13 @@
+version: 2
+updates:
+  # Enable version updates for Go modules
+  - package-ecosystem: "gomod"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+
+  # Enable version updates for GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"