v1.5.1-rc.6
Full Changelog: v1.5.1-rc.5...v1.5.1-rc.6
[1.5.1-rc.6] — 2026-07-05
Fixed
- Home Assistant-style PEP 440 nightly tags (and other lossy version formats) no longer masquerade as a stable "suggested pin". Tag suggestions for
latest/untagged containers relied onsemver.coerce()as a last-resort parser, which silently drops any suffix it doesn't understand — a PEP 440 dev/post release (2026.8.0.dev202607050315,1.2.3.post1), an OS-variant suffix (3.11-bullseye), or a hyphenated CalVer date (2024-01-15) all coerced down to a baremajor.minor.patchand got offered as "stable". Suggestions now reject any candidate tag that required this lossy coercion unless the raw tag is itself a bare numeric version (optionallyv-prefixed, 1-3 dot-separated groups) that provably lost nothing. The containers table also now renders the suggested-tag hint through the existingSuggestedTagBadgecomponent (labeled "Suggested" with a tooltip) instead of an unlabeled raw string next to the Digest/NEW badges. (#473) - "Click to copy" did nothing and logged a TypeError on deployments served over plain HTTP (the common self-hosted LAN setup), because the browser Clipboard API only exists in secure contexts. Copying now falls back to the legacy execCommand technique when the API is missing or rejects, covers the log viewer's Copy button too, and shows a "Copy failed" state instead of failing silently when no copy mechanism works at all. (#472)
- An open tooltip whose text changed — like the copy button's "Copied" confirmation — stayed stuck on the old text until you moved the mouse away and back. Clicking to copy hid the tooltip outright, so the "Copied"/"Copy failed" state never appeared until a re-hover. Tooltips now update their text in place while open, reposition themselves for the new content, and reappear immediately if the pointer never left. (#472)
- Three call sites bound a second tooltip directly onto a copyable tag's root element (the containers table's digest-delta tooltip and two spots in the dashboard's recent-updates widget), so it silently clobbered the tag's own copy-state tooltip — duplicate listeners and, after the content-change re-show above, occasional spurious re-shows while hovering. The informative text now flows into the tag's own tooltip via a new
idleTooltipprop instead of stacking a second directive on the same element. (#472)
Warning
Upgrade notes: behavioral changes, please read before updating. Three security-hardening fixes that change runtime behavior first shipped in 1.4.6 and carry through the entire 1.5 line. Anyone updating from a release older than 1.4.6 is affected, whatever version you land on (1.4.6, any 1.5.x, or later), because these changes sit across the 1.4.6 boundary rather than in one specific version. These are not deprecations: there is no compatibility shim or grace period, so a previously-working deployment can change behavior on upgrade.
- OIDC login now requires
authorization_endpointin your provider's discovery metadata. The authorization-redirect allowlist no longer falls back to a broad same-origin match. Mainstream identity providers (Keycloak, Authentik, Authelia, Okta, Google, Entra/Azure AD, Zitadel, …) publish this field and are unaffected. If your/.well-known/openid-configurationdoes not advertiseauthorization_endpoint, OIDC sign-in will now fail closed — make sure the discovery document exposes it. - Unauthenticated rate-limit buckets now key on the TCP peer address instead of
X-Forwarded-For. Behind a reverse proxy (nginx / Traefik / Caddy), all unauthenticated clients now share a single bucket (the proxy's address), regardless ofDD_SERVER_TRUSTPROXY. Internet-facing or multi-user instances may begin to see unexpected429 Too Many Requestson unauthenticated endpoints. Authenticated requests are keyed per session and are unaffected. - HTTP-trigger
proxyURLs must now use thehttp://orhttps://scheme. Any other scheme (e.g.socks5://) is rejected at config load. Such values were previously accepted but only ever treated as an HTTP proxy — switch to anhttp(s)://proxy URL.