What makes `postgres` on Docker Hub a Docker Official Image, and how do the publisher tiers differ?

### The name already tells you something A Docker image reference is `registry/namespace/repository:tag`. When you type `docker pull postgres`, the client fills in the defaults and pulls `docker.io/library/postgres:latest`. That `library` namespace is not a convention anybody can join — it is reserved by Docker for the **Docker Official Images** programme. This is why Official Images are the only images on Docker Hub you can pull by a bare, single-word name, and why the presence or absence of a slash in an image reference is the fastest trust signal available at the command line. `postgres` and `someuser/postgres` are two completely unrelated repositories, and a candidate who thinks the second is just a mirror of the first has missed the point. ### The tiers, in order of how much has been checked **Docker Official Images.** A curated set covering databases, web servers, caches, language runtimes and base distributions. Their Dockerfiles, entrypoint scripts and documentation live in public repositories, are reviewed by a dedicated maintainer team rather than merely uploaded, and follow shared conventions across the whole set: a documented list of environment variables, a `docker-entrypoint.sh` that turns those variables into configuration, an initialization hook directory for stateful services, and a consistent tag-variant naming scheme (a Debian release name such as `-bookworm`, or `-alpine` for the Alpine-based build). They are also rebuilt when the base they are built on is refreshed, so a given tag is not frozen forever. Upstream projects usually participate, but the packaging is reviewed by the programme. **Verified Publisher.** Published by the company that owns the software, under an account Docker has verified. The badge is an *identity* attestation: this really is that vendor's account, not a lookalike. It says nothing about whether the image follows the Official Images conventions — many do not, and the environment-variable contract, the user it runs as, and the data directory can be entirely different. **Sponsored Open Source.** The same identity attestation applied to an open-source project accepted into the programme, publishing under its own namespace. **Everything else.** Any account can push any image. Nobody reviews it, the Dockerfile may not be published anywhere, the repository may be abandoned, and the name may be a typosquat one character away from something popular. Pull counts and stars are a popularity measure, not a review. ### What a tier is not A badge is provenance, not a safety certificate. It does not mean the image has no known vulnerabilities, does not mean it packages the newest upstream release, does not mean it runs as a non-root user, and does not tell you what its entrypoint script will do on first start. Package freshness and scanning are separate disciplines with their own tooling; the trust tier answers only *who stands behind this artefact and was the packaging reviewed*. ### What to actually check before you run somebody else's image 1. **The repository documentation.** Which environment variables are required, which are read only on first start, which ports it listens on, where it writes data, and what it does with arguments you pass after the image name. 2. **The entrypoint.** For an Official Image you can read `docker-entrypoint.sh` in the public repository; that script, not the daemon, implements most of the image's behaviour. 3. **The user it runs as.** Some images drop privileges internally, some run everything as root, and that changes the ownership of anything they write into a mounted directory. 4. **The variant tag.** `-alpine` and `-bookworm` style suffixes select which distribution the image was assembled on, which decides which C library and which debugging tools exist inside it. 5. **Whether your organisation already mirrors it internally,** which most do for availability and rate-limit reasons. ### Why it bites in practice The failure mode is rarely dramatic. A team wiring up a subscription-billing cron adds a cache to their compose stack, types a community `someuser/redis-alpine` because it appeared in a blog post, and now depends on an image whose last push was 19 months ago, whose Dockerfile nobody can read, and whose entrypoint ignores the environment variables the real image documents. Nothing breaks on day one; it breaks the first time somebody needs to change a setting or explain the artefact to an auditor. Preferring the reserved-namespace image, or the vendor's own verified repository, costs nothing at the time and removes an entire class of later argument.