When to use this skill
When the user asks about a Docker image's maintenance status, popularity, available tags, supported architectures, or whether an image is deprecated — "Is nginx still maintained?", "Does this image support ARM?", "Is CentOS safe as a base image?" For pulling actual image layers or verifying manifests at the registry level, use the Docker Registry API (OCI Distribution Spec) instead; this skill covers Hub metadata only.
Your best first call
curl "https://hub.docker.com/v2/repositories/library/nginx/"
No auth required for public repositories. For third-party images, replace library with the owning namespace: bitnami/nginx lives at /repositories/bitnami/nginx/.
Key response fields:
name, namespace — the image identity on Hubstatus_description — "active" by default, but see pitfallsdescription — may start with "DEPRECATED" for unmaintained imagespull_count — cumulative pulls (nginx is at ~13 billion)last_updated — when the image was last pushed to the registry; this is the liveness signalstar_count — community starshub_user — for official images, "stackbrew" (Docker's seeding bot)
Fallbacks (when the best call isn't enough)
- Need tags and architectures for a specific image →
/repositories/{namespace}/{repository}/tags/?page_size=10 returns each tag with a nested images array containing per-architecture digests, sizes, and push timestamps. Paginate with next.
- Need to audit official images for deprecation across the whole library →
/repositories/library/?page_size=100 lists all official images with descriptions and last_updated dates. Scan for "DEPRECATED" in descriptions and stale timestamps.
- No fallback if Docker Hub is down — this metadata is available only from Hub's API.
Pitfalls
status_description: "active" does not mean maintained. CentOS shows "active" three years after its last push. Check last_updated and scan description for a "DEPRECATED" prefix — that is the real signal.- The
/search/repositories/ endpoint returned empty results for common terms in testing. Use direct repository lookups or namespace listings instead.
- The
library namespace is for official Docker images only. Third-party images use their own namespace (bitnami/nginx → /repositories/bitnami/nginx/). In a Dockerfile, nginx maps to library/nginx in this API — that asymmetry catches people off guard.
- Tag listings for popular images can exceed 1,000 entries. Always set
page_size and never fetch all tags unbounded.
One-line summary for the user
I can look up Docker Hub image metadata — maintenance status, pull counts, tags with per-architecture digests — for any public repository without authentication, but I can't access actual image layers or verify image content.
SKILL.md source (frontmatter + body)
---
name: look-up-docker-hub-image-metadata
description: When the user asks about a Docker image's maintenance status, pull count, available tags, supported architectures, or whether an image is deprecated — reach for the Docker Hub API. Public repository metadata via unauthenticated GET.
---
## When to use this skill
When the user asks about a Docker image's maintenance status, popularity, available tags, supported architectures, or whether an image is deprecated — "Is nginx still maintained?", "Does this image support ARM?", "Is CentOS safe as a base image?" For pulling actual image layers or verifying manifests at the registry level, use the Docker Registry API (OCI Distribution Spec) instead; this skill covers Hub metadata only.
## Your best first call
```bash
curl "https://hub.docker.com/v2/repositories/library/nginx/"
```
No auth required for public repositories. For third-party images, replace `library` with the owning namespace: `bitnami/nginx` lives at `/repositories/bitnami/nginx/`.
Key response fields:
- `name`, `namespace` — the image identity on Hub
- `status_description` — `"active"` by default, but see pitfalls
- `description` — may start with `"DEPRECATED"` for unmaintained images
- `pull_count` — cumulative pulls (nginx is at ~13 billion)
- `last_updated` — when the image was last pushed to the registry; this is the liveness signal
- `star_count` — community stars
- `hub_user` — for official images, `"stackbrew"` (Docker's seeding bot)
## Fallbacks (when the best call isn't enough)
- **Need tags and architectures for a specific image** → `/repositories/{namespace}/{repository}/tags/?page_size=10` returns each tag with a nested `images` array containing per-architecture digests, sizes, and push timestamps. Paginate with `next`.
- **Need to audit official images for deprecation across the whole library** → `/repositories/library/?page_size=100` lists all official images with descriptions and `last_updated` dates. Scan for `"DEPRECATED"` in descriptions and stale timestamps.
- **No fallback if Docker Hub is down** — this metadata is available only from Hub's API.
## Pitfalls
- `status_description: "active"` does not mean maintained. CentOS shows `"active"` three years after its last push. Check `last_updated` and scan `description` for a `"DEPRECATED"` prefix — that is the real signal.
- The `/search/repositories/` endpoint returned empty results for common terms in testing. Use direct repository lookups or namespace listings instead.
- The `library` namespace is for official Docker images only. Third-party images use their own namespace (`bitnami/nginx` → `/repositories/bitnami/nginx/`). In a Dockerfile, `nginx` maps to `library/nginx` in this API — that asymmetry catches people off guard.
- Tag listings for popular images can exceed 1,000 entries. Always set `page_size` and never fetch all tags unbounded.
## One-line summary for the user
I can look up Docker Hub image metadata — maintenance status, pull counts, tags with per-architecture digests — for any public repository without authentication, but I can't access actual image layers or verify image content.