[Feature] support backup or CDN docker registers

[LeeNX]

What would you like Docksentry to do?
Please could we possible support multiple docker registers?

Why is this useful?
The SRE inside of me, really does not want to be locked out or rate limited by things like Docker Hub pull request limits or even a register outage.

Possible implementation (optional)
If we could some how mark containers that have secondary docker registries, like ghcr.io for dockSentry or local docker CDN proxy (I have not looked into this, but I think GitHub do this for GitHub actions), the updates and image pulling could be used against these too for requests.

ie: docker pull ghcr.io/amayer1983/docksentry:latest
vs docker pull amayer1983/docksentry:latest

I am guessing a label that has the backup URL that could be used?

I am also thinking there is a bunch of places this could really go wrong and each registry might have different API interfaces, which could be big ask in the long run.

Your setup

• Docksentry version: v1.18.12
• Notification channels used: Telegram / Webhook
• Deployment: Docker Compose / Podman Compose

[amayer1983]

@LeeNX strong SRE instinct — and a legitimately hard ask. Let me lay out where I stand:

The clean version of this is a real architecture change, not a per-container env flag:

• Per-container fallback_registry label or config
• Pull-retry logic in _update_standalone() and _update_compose() that handles "primary 429-rate-limited → try fallback → fall back to primary on next try"
• Tag-equivalence across registries (ghcr.io/foo/bar:v1.2.3 == docker.io/foo/bar:v1.2.3?) — sometimes yes, sometimes the maintainer publishes only to one
• Digest comparison cross-registry — same image, different SHA depending on whether registry re-signed it

Today's partial answer: we already support arbitrary registries via DOCKER_REGISTRY + DOCKER_USERNAME + DOCKER_PASSWORD (v1.18.1), so you can already run a host-wide docker login ghcr.io and have Docksentry use ghcr as a primary registry. What's missing is the automatic fallback logic.

Lighter near-term mitigation that helps the rate-limit case:

• Authenticated Docker Hub pulls (already supported) → 200 pulls/6h instead of 100/6h anonymous
• Local registry proxy (regctl, Harbor, Sonatype Nexus) → cache pulls on your network

I'm labelling this roadmap + leaving open as a v2.x candidate. If the rate-limit ever bites enough users we'll move it up. For now, does the authenticated-pull workaround cover your immediate concern? That's a 5-minute env change (DOCKER_USERNAME + DOCKER_PASSWORD).