v1.72.0 — metrics, API tokens, image-age gate, phone cards

Three of the most-requested things across the tools I've been reading, built together because they only make sense together.

Container cards on a phone

Below 700px a five-column table is a compromise even inside a scroll container: you swipe sideways to find the buttons, and the columns that matter are the ones off-screen. Each container is a card instead — everything on one screen, actions sized for a finger.

Built from the same locals as the table row, in the same function. A row and a card that drift apart is the failure this project has already had twice: the Web UI's own copy of the link chain, then the container page's copy of the label rules. One place computes the state; two places only lay it out.

Don't be the guinea pig

MIN_IMAGE_AGE_DAYS=7
# or per container
docksentry.min-age=7

Hold auto-updates back until the image has been public for N days. Two independent reasons people ask for this, and the second is what makes it more than a preference: risk deferral — let someone else find the broken release — and supply chain, since a compromised image is usually noticed within days, so not being first to pull it is a real defence. It was the one gap in a safety chain that already has approval gates, semver caps, health-gated rollback, update windows and maintenance mode.

The auto path only. Pressing the button yourself always works — this governs what happens while nobody is watching. And it defers rather than discards: the update stays pending and applies by itself on a later tick once the image has aged.

Fails open when the registry exposes no build date. A gate cannot judge what it cannot see, and failing closed would silently stop updates for a large share of images — exactly the trap UPDATE_POLICY fell into, where a safety setting quietly did nothing while the operator believed otherwise.

/metrics, and the tokens it needs

API_TOKENS=prom:xxx,grafana:yyy

/metrics in Prometheus format and GET /api/status as JSON. Both report what is pending — per host and per container — not just that the process is alive. The motive that generalises best, from the projects surveyed: people who will not allow unattended updates run the tool in report-only mode, and for them the metric is the product.

Tokens land with it rather than after it, because the endpoint is unusable without them. A scraper cannot log in, and handing it the shared Web UI password would give a monitoring job the ability to stop containers.

• Named, so one can be revoked without disturbing the other
• Compared in constant time — a plain == leaks a secret's length and prefix through timing
• Consulted for exactly two GET paths, so a token cannot reach anything that changes state. POST /api/update with a valid token answers 401
• A token that is presented and wrong is rejected rather than falling through to the password check. On an instance with no WEB_PASSWORD that check answers 200, so a revoked token would have appeared to keep working and you would have believed you had cut access

?token= works alongside the Bearer header, because several scrapers cannot set headers and refusing them pushes people towards leaving the endpoint open instead. The query string does land in access logs; that is the trade, said out loud rather than hidden.

The output validates clean under promtool — which is how docksentry_containers_total got caught before shipping: _total is reserved for counters and that is a gauge.

Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.