Switching from the third-party OIDC-capable jellyseerr fork to the
mainline successor project (Seerr - the combined Overseerr+Jellyseerr
team rebrand, v3.0.0 / Feb 2026 onward). Mainline now has native OIDC
support so the custom preview-OIDC build isn't needed.
- Image : docker.io/fallenbagel/jellyseerr:preview-OIDC
-> ghcr.io/seerr-team/seerr:v3.3.0 (Jun 2, 2026)
- Migration: automatic on first start per docs.seerr.dev/migration-guide;
existing sqlite db + settings.json in /app/config are
directly compatible. v3.1.x added CVE-2026-40175 fix +
auth-related security patches, so v3.3.0 is the right
floor anyway.
- Backup : ~/seerr-backups/seerr-config-20260606-153633.tar.gz on
dooplex (covers db.sqlite3 + settings.json + logs).
Rollback = revert image + restore tarball into the PVC.
Worth verifying after rollout:
- Pod becomes Ready (readiness probe path /api/v1/status -- should
still exist in seerr).
- Authentik OIDC sign-in still works. If the custom build used
different config keys than mainline seerr expects, OIDC may need
re-configuration in the seerr UI (Authentik side unchanged).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
codewithcj changed sparkyfitness versioning on 2026-06-01:
- Old (through v0.16.6.3 / 2026-05-24): vMAJOR.MINOR.PATCH.BUILD
- New (from v0.16.7 / 2026-06-01) : vMAJOR.MINOR.PATCH
Our version-checker regex was `^v\d+\.\d+\.\d+\.\d+$` (4 segments
only), so the new v0.16.7 / v0.16.8 tags were invisible to it. The
"newest matching" became an arbitrarily-chosen old 4-segment tag
(v0.16.5.9 in the latest scan), which then showed up as an "upgrade
to an older version" -- nonsense, but predictable given the filter.
Two changes:
1. Bump both `codewithcj/sparkyfitness` (frontend) and
`codewithcj/sparkyfitness_server` (backend) from v0.16.6.3 to
v0.16.8 (the actual upstream latest).
2. Loosen the regex to `^v\d+\.\d+\.\d+(\.\d+)?$` so it matches
both the legacy 4-segment form and the new 3-segment form.
Once everything's on 3-segment we can tighten it again if we
want, but the current form is harmless.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous PR deleted the umami packageRule but left a stray closing
brace after it, which broke the embedded config.json. ArgoCD applied
the manifest as a string (it's a ConfigMap; k8s doesn't validate the
JSON inside data), so the live ConfigMap also has the invalid JSON --
next Renovate run would fail to parse the config.
Removing the orphan brace restores valid JSON. Verified `json.loads`
parses to 3 customManagers + 7 packageRules.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three coordinated changes, all surfaced by the question "will Renovate
track the manually-bumped packages going forward":
1) Delete `felhom-system/` directory (4 files).
These were never the source of truth -- the `felhom` ArgoCD app
pulls from `felhom.eu`, path `manifests`. The copies in this repo
fell out of sync over time and were misleading. Renovate was about
to start opening DEAD PRs against them (the customManager below
targeted `felhom-system/umami.yaml`). Removing the directory is the
cleanest fix; manual bumps for the real felhom-system manifests go
into the felhom.eu repo.
2) Fix plex inline `# renovate:` comment in helm/plex/values.yaml.
It referenced `datasource=custom.plex` but no such customDatasource
exists in the config -- Renovate would silently skip plex. Switched
to the standard docker datasource with regex versioning that parses
`1.X.Y.Z-<hash>` (4 segments + git short-hash suffix, same pattern
approach as servarr and termix).
3) Remove the now-obsolete umami customManager + packageRule.
The customManager was for the `postgresql-vX.Y.Z` tag form we've
abandoned -- the real felhom.eu deployment is on `3.1.0` (plain
semver). The packageRule disabled the kubernetes manager for the
umami image to silence its failure on `postgresql-vX.Y.Z`; not
needed since the default versioning handles `3.X.Y` fine. (Moot
anyway since Renovate doesn't watch felhom.eu -- but cleanup
reduces config noise.)
After this PR, Renovate's effective tracking:
- servarr (sonarr/radarr/prowlarr) -> YES (customManager)
- plex -> YES (inline comment, docker)
- termix -> YES (customManager)
- umami / filebrowser in felhom.eu -> NO (different repo, manual)
- all standard semver/named tags in homelab-manifests -> YES (defaults)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- sonarr version-4.0.16.2944 -> version-4.0.17.2952 (patch within 4.0.x)
- radarr×2 version-6.0.4.10291 -> version-6.1.1.10360 (minor within 6.x)
- prowlarr version-2.3.0.5236 -> version-2.3.5.5327 (patch within 2.3.x)
- plex 1.43.0.10467-... -> 1.43.2.10687-... (patch within 1.43.x)
All four were stuck because of tag-format issues that I addressed in
PR #82 (servarr customManager) / PR #83. Renovate isn't auto-creating
the PRs yet (DH rate-limit), so doing them manually so version-checker
clears.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Renovate can't propose updates for moving tags (the tag string never
changes; the registry just points it at a different image). These three
were pinned to moving variants:
felhom-system/webpage.yaml : filebrowser/filebrowser:v2-alpine
felhom-system/umami.yaml : ghcr.io/umami-software/umami:postgresql-latest
tandoor-system/tandoor.yaml: vabene1111/recipes:2.6
Pin each to the current actual version per Viktor's call:
- filebrowser -> v2.63.13 (matches the other 4 filebrowser pinnings
in the repo; dropped the `-alpine` variant so Renovate can group
them via the existing default datasource path)
- umami -> postgresql-v1.38.0 (current upstream postgresql
variant latest; tracked via new customManager below)
- recipes -> 2.6.9 (current actual semver of the 2.6 series)
For umami, the `postgresql-vX.Y.Z` tag pattern is rejected by Renovate's
default docker versioning pre-check (same failure class as termix +
linuxserver servarr). Added a customManager regex + packageRule disable
pair so Renovate can track future `postgresql-vX.Y.Z` updates via regex
versioning. filebrowser and recipes use standard semver `X.Y.Z` after
the re-pin and need no special handling.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Several images were showing as outdated in version-checker / unhandled by
Renovate. Each had a distinct cause; this PR fixes the auto-tractable ones.
1) admin-system/renovate.yaml: bump `app.kubernetes.io/version` labels
`43.197.0 -> 43.209.3` (3 occurrences) to match the live image.
Renovate's own self-update PR bumped the image tag but left the
labels stale; the version-checker widget appears to read the label.
Long-term, this label will drift again on each self-update -- worth
a customManager later if it becomes a recurring annoyance.
2) admin-system/renovate.yaml: add a customManager + packageRule pair
for linuxserver servarr apps. Tag pattern is `version-X.Y.Z.B`
(4 segments + `version-` prefix) which the kubernetes manager's
default docker versioning rejects at the pre-check, same failure
class as termix. Regex versioning parses the prefixed 4-segment
form; the same customManager handles prowlarr/radarr/sonarr (depName
captured from the regex). kubernetes-manager extraction for these
three depnames is disabled via packageRule so the dashboard isn't
cluttered with the failing fallback.
3) nextcloud-system/nextcloud.yaml: add
`match-regex.version-checker.io/nextcloud: '^\d+\.\d+\.\d+-apache$'`
so version-checker doesn't treat the bare `33.0.5` server tag as a
newer version of our `33.0.5-apache` image. The widget was showing
`33.0.5-apache -> 33.0.5` -- false positive; image is already current.
4) helm/plex/values.yaml: tighten the version-checker regex from
`^\d+\.\d+\.\d+\.\d+-.*$` to `^\d+\.\d+\.\d+\.\d+-[a-f0-9]+$` so
per-arch tags (`-armhf`, `-arm64`, ...) are excluded. The widget
was showing an `-armhf` tag as "newer" than our x86_64 install.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pi-hole 2026.05.0 bundles FTL v6.6.2 which imports six upstream dnsmasq
security fixes, covering all publicly disclosed CVEs against the
dnsmasq 2.92/2.93 line. Per the upstream release notes the fixes are
"minimal, self-contained changes to the embedded dnsmasq sources. No
FTL-side configuration or API changes; users should see no observable
behavior change beyond the closed vulnerabilities."
Override the chart's default image.tag in helm/pihole/values.yaml (no
chart version bump). The pihole ArgoCD app is intentionally MANUAL
sync per Viktor's call -- after merge, sync the pihole app from the
ArgoCD UI to roll the pod over.
https://github.com/pi-hole/docker-pi-hole/releases/tag/2026.05.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Renovate's `Pending Approval` checkbox for the termix v2 major was ticked
on Dashboard #6, but the manual Renovate runs that should have processed
it both aborted on Docker Hub's authenticated rate-limit:
HTTP 429: You have reached your pull rate limit as 'kisfenyo'
The free DH plan caps authenticated pulls at 100/6h; with ~270 deps in
this repo and the multiple runs we've done today, we've exhausted it.
Renovate's behavior on a host 429 is to abort the entire repository run
(`result: external-host-error`), so no further work — including ticked
dashboard approvals — gets done until the quota window resets.
Rather than wait ~3-4 hours, this PR does the bump by hand. Upstream
ghcr.io/lukegus/termix:release-2.3.2 is verified present (Termix-SSH
GitHub Release of 2026-06-04). Termix is stateless (host/cred config
stored in PocketBase but compatible across release-1 and release-2),
so the rollout should be a straightforward image swap.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Renovate PR #76 (merged 2026-06-06 10:48) bumped ghcr.io/immich-app/postgres
from `16-vectorchord0.3.0` to `17-vectorchord0.3.0`. PostgreSQL major
upgrades require pg_upgrade or pg_dump/restore — the new server binary
refuses to open a data directory initialized by the previous major:
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 16,
which is not compatible with this version 17.6
Both immich-postgres and immich-server (depends on Postgres) went into
CrashLoopBackOff. PVC still holds the v16 datadir.
This PR:
1. Reverts ghcr.io/immich-app/postgres back to `16-vectorchord0.3.0`
so immich recovers immediately.
2. Adds a packageRule with `dependencyDashboardApproval: true` covering
`postgres`, `postgis/postgis`, and `ghcr.io/immich-app/postgres`.
Any update to these images is now held on the Dashboard's "Pending
Approval" section -- Renovate won't even open a PR until the user
explicitly ticks the box. Forces the migration plan to be made
BEFORE the change reaches main.
This is the same recovery pattern we just used for meilisearch (PR #77)
-- a class of stateful images where the on-disk format isn't
forward-compatible across version bumps.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Renovate PR #32 (merged 2026-06-06 09:30) bumped getmeili/meilisearch
from v1.11.3 to v1.45.2 under the default-allow + 3-day stability rule.
Meilisearch's on-disk index format is NOT forward-compatible across
that range; wanderer-meilisearch went into CrashLoopBackOff with:
Error: Your database version (1.11.3) is incompatible with your
current engine version (1.45.2).
The PVC still holds the v1.11.x index, so the safest immediate recovery
is reverting the image tag. Wanderer's search starts working again the
moment the pod comes up on v1.11.3.
To prevent recurrence, add a packageRule that holds ALL meilisearch
updates behind the dashboard's "Pending Approval" checkbox via
`dependencyDashboardApproval: true`. PRs won't be opened until the
user explicitly approves them on the dashboard, so the version bump
can be planned around the documented dump/restore migration path
(https://www.meilisearch.com/docs/learn/update_and_migration/updating).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Verified with the GitHub Releases API for Termix-SSH/Termix that the
actual `tag_name` field is `release-X.Y.Z-tag` (with a `-tag` suffix),
even though the release `name` is `release-X.Y.Z`. Renovate's
github-releases datasource keys off `tag_name`, so the regex versioning
correctly rejects all candidates as invalid:
INFO: Found no results from datasource that look like a version
(dependency=Termix-SSH/Termix)
The docker image at ghcr.io/lukegus/termix uses the short form
(`release-X.Y.Z`, no suffix), which is what the manifest also has.
Fix: add `extractVersionTemplate: ^(?<version>release-\d+\.\d+\.\d+)`
which Renovate applies to each candidate from the datasource BEFORE
the versioning regex sees it. tag_names `release-2.3.2-tag` become
`release-2.3.2`, the regex versioning parses them, comparison works,
and Renovate writes the short form back to the manifest -- which is
the correct tag at the ghcr.io registry.
(extractVersion is NOT applied to currentValue, but currentValue already
is in the short form, so no normalization needed there.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Third attempt. Debug run confirmed `loose` + `extractVersion` STILL produces:
DEBUG: Dependency Termix-SSH/Termix has unsupported/unversioned value
release-1.11.0 (versioning=loose)
DEBUG: Skipping Termix-SSH/Termix because no currentDigest or pinDigests
`extractVersion` is only applied to CANDIDATE versions (from the datasource),
not to currentValue. Renovate's pre-validation runs the raw `release-1.11.0`
through `loose`, which can't parse it (the `release-` prefix breaks semver
detection), so Renovate falls back to digest-only and gives up.
`regex` versioning is the only mode that parses the prefixed value directly
(no extractVersion needed) — Renovate's regex.matches() accepts `release-1.11.0`
because the rule's pattern captures the whole tag. github-releases datasource
returns the upstream `release-X.Y.Z` tag_names which the same regex parses.
No conversion needed; the new tag written back to the manifest is the same
`release-X.Y.Z` form, valid in the ghcr.io/lukegus/termix registry.
Removes extractVersionTemplate (no longer needed).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous attempt (inline `# renovate:` comment in termix.yaml) silently
did nothing -- after merge + manual run, the dashboard's
`termix-system/termix.yaml (2)` was the resource count (Deployment +
Ingress), not detected updates. No PRs opened, no termix branches, no
queue entries anywhere.
Root cause: Renovate's `kubernetes` manager does NOT process inline
`# renovate:` comments. Those work for dockerfile/flux/helmfile/github-
actions/helm-values/etc., but kubernetes is missing from that list.
Correct fix: a `customManagers.regex` entry that extracts termix's image
directly with the right datasource/versioning/extractVersion set at
EXTRACTION time -- before any docker-version pre-check can reject the
prefixed tag. Plus a packageRule disabling the kubernetes manager for
termix so it doesn't silently skip the dep and clutter the dashboard.
Changes:
- admin-system/renovate.yaml:
* enabledManagers += "custom.regex"
* customManagers: termix.yaml regex extraction -> github-releases
datasource on Termix-SSH/Termix with `extractVersion=^release-(?<version>.+)$`
* packageRules: disable kubernetes manager for ghcr.io/lukegus/termix
- termix-system/termix.yaml: drop the useless inline comment, leave a
NOTE explaining where the actual config lives.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Debug-level dry-run revealed why the previous packageRule approach
(`datasource: github-releases` + `packageName: Termix-SSH/Termix` +
`versioning: regex:^release-...`) silently did nothing:
DEBUG: Dependency ghcr.io/lukegus/termix has unsupported/unversioned
value release-1.11.0 (versioning=docker)
DEBUG: Skipping ghcr.io/lukegus/termix because no currentDigest or
pinDigests
The kubernetes manager extracts the image with the default versioning
(=docker), runs an EARLY currentValue pre-check, fails on `release-1.11.0`,
falls back to digest-based updates, and gives up -- all BEFORE the
packageRule's `versioning` override has a chance to apply. Same failure
class as the earlier `extractVersion` attempt.
Renovate's documented fix for this exact case is an inline manifest
comment that applies overrides at extraction time:
# renovate: datasource=github-releases depName=Termix-SSH/Termix \
# versioning=loose extractVersion=^release-(?<version>.+)$
image: ghcr.io/lukegus/termix:release-1.11.0
With extractVersion stripping the `release-` prefix at extraction, the
loose semver parser handles the resulting `1.11.0` / `2.3.2` fine.
github-releases datasource gives Renovate real upstream timestamps so
the 3-day stability gate works normally. Removing the now-superseded
packageRule keeps the config clean (6 rules instead of 7).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
26 items sat in dashboard "Rate-Limited" after the first default-allow
run (Sat 02:00); at 8 PRs/run + 1 run/week the backlog would take ~3
weeks to drain. Doubling to 16/16 cuts that to ~2 runs while still
leaving headroom (the dashboard "Pending Approval" majors and ghcr.io
"Pending Status Checks" don't count against this limit anyway).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Privacy-focused, client-side PDF toolkit deployed into the office-system
namespace alongside OnlyOffice. Stateless (no DB/PVC); nginx-internal
ingress with HU geo-restriction and letsencrypt-prod TLS. Auto-synced by
the existing `office` ArgoCD Application.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Was Sun 04:00; now Sat 02:00 so Renovate's wave lands at the start of
the weekend instead of the end. If an auto-merged update breaks
something, Viktor has the full weekend to troubleshoot.
`0 2 * * 6` = Saturday 02:00 in Europe/Budapest (the CronJob already
sets timeZone, so this is wall-clock local).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
"description": "termix: docker image tag is `release-X.Y.Z` but the upstream GitHub release tag_name is `release-X.Y.Z-tag` (different from the release name). regex versioning parses currentValue (no -tag); extractVersion strips the -tag suffix from candidate tag_names so they normalize to the same shape Renovate writes back to the manifest.",
"description": "linuxserver servarr apps (prowlarr, radarr, sonarr) use tag pattern `version-X.Y.Z.B` (4 segments + `version-` prefix). The kubernetes manager's default docker versioning rejects them at the pre-check (same failure class as termix), so no PRs ever open. Use regex versioning to parse the prefixed 4-segment form; depName is captured from the regex so the same customManager handles all three apps.",
"description": "All apps: 3-day stability gate before any PR opens",
@@ -90,17 +115,40 @@ data:
],
"automerge": false
},
{
"description": "termix: use github-releases as datasource (ghcr.io OCI manifest for this image lacks the release timestamp Renovate needs for the stability gate; GitHub Releases at Termix-SSH/Termix expose proper timestamps so the 3-day gate works as intended). regex versioning parses the release-X.Y.Z prefix. Renovate still writes the new tag to the same ghcr.io/lukegus/termix image (the registry hosts every release).",
"description": "meilisearch: every version bump can require an index format migration via dump/restore (see https://www.meilisearch.com/docs/learn/update_and_migration/updating). PR #32 (v1.11.3 -> v1.45.2) on 2026-06-06 broke wanderer with `Your database version (1.11.3) is incompatible with your current engine version (1.45.2)`. Hold ALL meilisearch updates behind dashboard approval so the migration is planned before the PR even opens.",
"matchPackageNames": ["getmeili/meilisearch"],
"dependencyDashboardApproval": true
},
{
"description": "Postgres-family images: a major bump (e.g. 16 -> 17) requires pg_upgrade or dump/restore — the new server binary refuses to open the old data directory (`database files are incompatible with server`). PR #76 (immich-app/postgres 16 -> 17) on 2026-06-06 crashlooped immich-postgres and immich-server. Renovate's docker versioning treats these custom tag formats inconsistently, so don't trust the major/minor classification: hold ALL updates for these images behind explicit dashboard approval. Includes vanilla postgres, postgis/postgis (where the tag prefix IS the pg major), and ghcr.io/immich-app/postgres (custom `N-vectorchordX.Y.Z` form).",
"matchPackageNames": [
"postgres",
"postgis/postgis",
"ghcr.io/immich-app/postgres"
],
"dependencyDashboardApproval": true
},
{
"description": "termix: kubernetes manager would extract the image with versioning=docker and silently skip it (release-1.11.0 fails the docker pre-check). Disable that extraction; customManagers above does the real work via github-releases.",
"matchManagers": ["kubernetes"],
"matchPackageNames": ["ghcr.io/lukegus/termix"],
"enabled": false
},
{
"description": "linuxserver servarr apps: same disable pattern as termix. The customManager above handles extraction with the right versioning; turn off the default kubernetes-manager extraction so it doesn't silently skip + clutter the dashboard.",
"matchManagers": ["kubernetes"],
"matchPackageNames": [
"linuxserver/prowlarr",
"linuxserver/radarr",
"linuxserver/sonarr"
],
"enabled": false
}
],
"labels": ["renovate"]
@@ -114,9 +162,11 @@ metadata:
labels:
app.kubernetes.io/instance:renovate
app.kubernetes.io/name:renovate
app.kubernetes.io/version:"43.197.0"
app.kubernetes.io/version:"43.209.3"
spec:
schedule:"0 4 * * 0"
# Sat 02:00 Europe/Budapest — leaves the full weekend for troubleshooting
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.