immich: remove the PostgreSQL 14 cluster

MariaDB: newest 11.4 patch, and keep Renovate on 11.4

.github/workflows/validate.yaml

@@ -18,7 +18,7 @@ concurrency:
 
 jobs:
   validate:
-    runs-on: ubuntu-24.04
+    runs-on: ubuntu-26.04
     timeout-minutes: 20
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

actual-budget/helm-actual-budget.yaml

@@ -12,7 +12,7 @@ spec:
   project: default
   source:
     repoURL: https://community-charts.github.io/helm-charts
-    targetRevision: 1.8.9
+    targetRevision: 1.9.5
     chart: actualbudget
     helm:
       values: |

apps/templates/authentik-helm.yaml

@@ -103,6 +103,8 @@ spec:
               requests:
                 cpu: 70m
                 memory: 560Mi
+              limits:
+                memory: 1536Mi
             volumes:
               - name: patched-ca-bundle
                 configMap:
@@ -192,6 +194,8 @@ spec:
               requests:
                 cpu: 100m
                 memory: 336Mi
+              limits:
+                memory: 1Gi
             volumes:
               - name: patched-ca-bundle
                 configMap:

apps/templates/cert-manager-helm.yaml

@@ -38,16 +38,22 @@ spec:
           requests:
             cpu: 10m
             memory: 48Mi
+          limits:
+            memory: 128Mi
         cainjector:
           resources:
             requests:
               cpu: 10m
               memory: 80Mi
+            limits:
+              memory: 256Mi
         webhook:
           resources:
             requests:
               cpu: 10m
               memory: 32Mi
+            limits:
+              memory: 128Mi
   syncPolicy:
     syncOptions:
     - CreateNamespace=true

apps/templates/cloudnativepg-helm.yaml

@@ -28,6 +28,8 @@ spec:
           requests:
             cpu: 10m
             memory: 48Mi
+          limits:
+            memory: 128Mi
   destination:
     server: https://kubernetes.default.svc
     namespace: cnpg-system

apps/templates/envoy-gateway-helm.yaml

@@ -12,7 +12,7 @@ spec:
     repoURL: docker.io/envoyproxy
     chart: gateway-helm
     # v1.9 supports Kubernetes 1.33 to 1.36
-    targetRevision: v1.9.2
+    targetRevision: 1.9.3
     helm:
       values: |
         config:

apps/templates/external-secrets-helm.yaml

@@ -24,16 +24,22 @@ spec:
             requests:
               cpu: 20m
               memory: 64Mi
+            limits:
+              memory: 128Mi
           certController:
             resources:
               requests:
                 cpu: 10m
                 memory: 64Mi
+              limits:
+                memory: 128Mi
           webhook:
             resources:
               requests:
                 cpu: 10m
                 memory: 32Mi
+              limits:
+                memory: 128Mi
   destination:
     server: https://kubernetes.default.svc
     namespace: external-secrets

apps/templates/plugin-barman-cloud-helm.yaml

@@ -21,6 +21,8 @@ spec:
           requests:
             cpu: 10m
             memory: 64Mi
+          limits:
+            memory: 128Mi
   destination:
     server: https://kubernetes.default.svc
     namespace: cnpg-system

argocd/overlays/resources.patch.yaml

@@ -1,6 +1,6 @@
 # Requests from what the components used on 2026-10-25 (kubectl top every
-# 5 minutes; highest value plus 10%). No limits until there are daytime
-# numbers, see docs/roadmap.md.
+# 5 minutes; highest value plus 10%). Memory limits at about twice the
+# highest value seen then or on 2026-10-27, rounded up; no CPU limits.
 apiVersion: apps/v1
 kind: StatefulSet
 metadata:
@@ -14,6 +14,8 @@ spec:
             requests:
               cpu: 150m
               memory: 704Mi
+            limits:
+              memory: 2560Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -28,6 +30,8 @@ spec:
             requests:
               cpu: 100m
               memory: 128Mi
+            limits:
+              memory: 512Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -42,6 +46,8 @@ spec:
             requests:
               cpu: 10m
               memory: 64Mi
+            limits:
+              memory: 256Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -56,6 +62,8 @@ spec:
             requests:
               cpu: 20m
               memory: 96Mi
+            limits:
+              memory: 256Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -70,6 +78,8 @@ spec:
             requests:
               cpu: 10m
               memory: 48Mi
+            limits:
+              memory: 128Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -84,6 +94,8 @@ spec:
             requests:
               cpu: 10m
               memory: 48Mi
+            limits:
+              memory: 128Mi
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -98,3 +110,5 @@ spec:
             requests:
               cpu: 10m
               memory: 32Mi
+            limits:
+              memory: 128Mi

authentik/postgresql-backup.yaml

@@ -67,6 +67,8 @@ spec:
       requests:
         cpu: 10m
         memory: 64Mi
+      limits:
+        memory: 512Mi
     env:
       # Newer boto3 adds checksums that S3-compatible stores can reject;
       # the plugin's docs suggest sending them only when required.

authentik/postgresql-cluster.yaml

@@ -6,7 +6,7 @@ spec:
   instances: 1
   # Pinned so a new operator default (PostgreSQL 18 since CNPG 1.26.3) can't
   # start an in-place major upgrade. CNPG filled this in at creation.
-  imageName: ghcr.io/cloudnative-pg/postgresql:17.4
+  imageName: ghcr.io/cloudnative-pg/postgresql:17.11
   primaryUpdateStrategy: unsupervised
   # WAL archiving and base backups to Garage, see postgresql-backup.yaml
   plugins:
@@ -18,6 +18,8 @@ spec:
     requests:
       cpu: 50m
       memory: 256Mi
+    limits:
+      memory: 1Gi
   bootstrap:
     initdb:
       database: authentik

dns/cronjob.yaml

@@ -13,7 +13,7 @@ spec:
       restartPolicy: Never
       containers:
         - name: sync
-          image: python:3.12-alpine
+          image: python:3.15-alpine
           command:
             - sh
             - -c

docs/immich-scouts-online.md

@@ -27,7 +27,9 @@ view, and everything is shared with everyone automatically.
 - **immich has no user groups**; albums are shared per user, as viewer or
   editor. The owner and editors of an album may add users and change
   their roles. Search only covers your own photos and those of partners
-  you show in your timeline.
+  you show in your timeline. People (face recognition) are per user too,
+  and a partner's library doesn't bring its people along; since 3.3 a
+  user can share people with the users in their cluster group.
 
 ## Design
 
@@ -46,7 +48,10 @@ view, and everything is shared with everyone automatically.
   every user into every album of the group account (`fotoupload@`), as
   editor or viewer by quota; the group account's library as a partner of
   everyone, shown in the timeline; album invitations for albums older than
-  a week hidden; sessions of OAuth users older than 30 days ended. Albums
+  a week hidden; sessions of OAuth users older than 30 days ended;
+  everyone in the group account's cluster group with its people shared
+  (names editable by those who may upload, added 2026-10-28, when nobody
+  but the group account could search by face). Albums
   that kaderleden create get the group account as editor first (in the
   database, since the API only lets an album's owner or editors share
   it), so they go to everyone too; names starting with "Privé"/"Prive"

docs/roadmap.md

@@ -26,11 +26,12 @@ docs/longhorn-second-ssd.md:
 - [x] Read `~/iosample.log` on opti1: the worst stretch was not the
   backups but 8.5 hours of Longhorn merging immich-claim's deleted
   snapshots (2026-10-24 14:30-23:15), see docs/upgrade-k8s-1.33.md
-- [ ] From 2026-10-27, if immich runs without problems: delete
-  `immich/postgresql-cluster.yaml` (the PG14 cluster still runs, 20 GiB),
-  the Longhorn snapshots and backups `immich-pg14-pre-vchord` and
-  `immich-pg17-pre-v3`, and both dumps in `~` on opti1. PostgreSQL 14
-  reaches end of life on 2026-11-12
+- [x] From 2026-10-27, if immich runs without problems: delete
+  `immich/postgresql-cluster.yaml` (the PG14 cluster, 20 GiB), the
+  Longhorn snapshots and backups `immich-pg14-pre-vchord` and
+  `immich-pg17-pre-v3`, and both dumps in `~` on opti1. Done 2026-10-28
+  (PR #61), with the PG14 volume's other Longhorn backups.
+  `immich-pg17-pre-v3` only ever was a snapshot
 - [ ] The upgrade's dqlite and backend copies in `/root/` on opti1
   (`backend-*.tar`, `dqlite-pre-*`)
 - [ ] Log in to immich as a jeugdlid (quota 0)
@@ -341,8 +342,13 @@ Counted 2026-10-25 over the 73 running containers:
   requested. Still without requests: Longhorn (22 containers, its chart),
   the Vault servers, the LDAP outpost, immich's PG14 cluster and three in
   kube-system
-- [ ] Memory limits, once there are daytime numbers: the night ones miss
-  immich's machine learning at work (it idles at 234Mi)
+- [x] Memory limits: PR #58, for everything that got requests in #33.
+  About twice the highest memory from `kubectl top` every 5 minutes from
+  2026-10-26 22:29 to 2026-10-27 21:55 UTC or the night of #33, rounded
+  up; no CPU limits. No OOM kills that day. immich's machine learning
+  sat idle all day (240Mi), so on 2026-10-28 a test image went through
+  CLIP, face recognition and OCR inside the container: 884Mi with all
+  three loaded, limit 2Gi
 - [x] WordPress (scoutingmbg.nl) was OOMKilled at 08:27:59 UTC on
   2026-10-25, its third restart: a crawler asked for 88 pages and assets
   within a few seconds (normally ~6 a minute), Apache started a PHP worker
@@ -503,7 +509,7 @@ critical / high:
 
 | Image | Crit | High | What to do |
 |---|---|---|---|
-| tensorchord/cloudnative-pgvecto.rs:14-v0.2.1 | 38 | 342 | immich's old PG14 cluster; goes with the cleanup from 2026-10-27 |
+| tensorchord/cloudnative-pgvecto.rs:14-v0.2.1 | 38 | 342 | immich's old PG14 cluster; deleted 2026-10-28 |
 | cloudnative-pg/postgresql:17.4 | 27 | 260 | authentik's database, a Debian 11 image. Renovate now offers 17.7; a `17.x-standard-trixie` image is more current |
 | tensorchord/cloudnative-vectorchord:17.11-1.1.1 | 17 | 136 | immich's database; look for a newer tag |
 | longhornio/longhorn-instance-manager:v1.7.3 | 11 | 159 | still serves 16 volumes, see below |
@@ -514,7 +520,7 @@ critical / high:
 | rubenhensen/bolletjestrui:main-10268f1 | 5 | 76 | rebuild on a current base image |
 | coredns/coredns:1.10.1 | 5 | 70 | see below |
 | dexidp/dex:v2.45.1, argocd v3.5.6, redis 8.2.3 | 4, 1, 2 | | come with Argo CD |
-| mariadb:11.4.5 | 4 | 65 | the newest 11.4 patch; Renovate now covers it |
+| mariadb:11.4.5 | 4 | 65 | 11.4.13 since PR #60; Renovate stays on 11.4 (it offered 11.8, PR #42) |
 | calico v3.29.3 | 2-3 | ~50 | comes with microk8s |
 | goauthentik ldap / server 2026.8.5 | 3, 1 | 74, 65 | the next authentik patch |
 

docs/upgrade-k8s-1.33.md

@@ -169,8 +169,9 @@ pgvecto.rs. Done 2026-10-24, about an hour of immich downtime:
   v2.4.1 refused to start (it only accepts VectorChord <0.6); v2.5.0 and up
   accept <2, so immich went to v2.7.5, the last 2.x. It rebuilt both
   indexes as `vchordrq` in about 1.5 minutes
-- [ ] After a few days without problems: delete the old cluster
+- [x] After a few days without problems: delete the old cluster
   (`immich/postgresql-cluster.yaml`), the snapshot/backup and the dump.
+  Done 2026-10-28 (PR #61), with the PG14 volume's Longhorn backups.
   Rolling back means reverting the old volume to the snapshot, since its
   embeddings are now `real[]` without pgvecto.rs
 - [x] immich 3.x: v2.7.5 → v3.3.5 with chart 0.10.3 → 0.13.4 on
@@ -189,8 +190,8 @@ pgvecto.rs. Done 2026-10-24, about an hour of immich downtime:
   (v3.3.0), for faster ML with less memory; numerically the same models,
   so no jobs to rerun. The model cache is an emptyDir, so the one-off
   preparation repeats on every restart
-- [ ] After a few days without problems: delete the `immich-pg17-pre-v3`
-  snapshot and dump together with the PG14 leftovers above
+- [x] After a few days without problems: delete the `immich-pg17-pre-v3`
+  snapshot and dump together with the PG14 leftovers above (2026-10-28)
 
 ## k8s-dqlite write stalls (found 2026-10-22)
 

freshrss/freshrss-deployment.yaml

@@ -23,7 +23,7 @@ spec:
         io.kompose.service: freshrss
     spec:
       initContainers:
-        - image: alpine/git:v2.52.0
+        - image: alpine/git:v2.54.0
           name: git
           command:
           - git
@@ -74,7 +74,7 @@ spec:
               value: Europe/Amsterdam
           # 1.30.3 ships PHP 8.4.27, which fixes CVE-2026-109618 and
           # CVE-2026-109619.
-          image: freshrss/freshrss:1.30.3
+          image: freshrss/freshrss:1.30.4
           name: freshrss
           ports:
             - containerPort: 80
@@ -83,6 +83,8 @@ spec:
             requests:
               cpu: 50m
               memory: 176Mi
+            limits:
+              memory: 512Mi
           # TCP, because mod_auth_openidc answers 401 to anything that isn't a
           # browser.
           readinessProbe:

gitea/gitea-deployment.yaml

@@ -54,6 +54,8 @@ spec:
             requests:
               cpu: 20m
               memory: 336Mi
+            limits:
+              memory: 1Gi
           # /api/healthz checks the database and the cache.
           readinessProbe:
             httpGet:

immich/helm-immich.yaml

@@ -67,6 +67,8 @@ spec:
                       requests:
                         cpu: 10m
                         memory: 64Mi
+                      limits:
+                        memory: 256Mi
                     image:
                       repository: docker.io/valkey/valkey
                       tag: 9.1.2-alpine@sha256:48332870af354a799964c0012ae1194a0bf2bf894eb508f945810596dc2d8d11
@@ -93,6 +95,8 @@ spec:
                       requests:
                         cpu: 100m
                         memory: 1280Mi
+                      limits:
+                        memory: 3Gi
                     # Node trusts its built-in roots, which still include the
                     # ones above the compromised eMudhra intermediates. Use
                     # patched-ca-bundle through OpenSSL until Node ships a fix.
@@ -117,12 +121,14 @@ spec:
                     image:
                       repository: ghcr.io/immich-app/immich-machine-learning
                       pullPolicy: IfNotPresent
-                    # Idle at night (234Mi); the models take over a GiB when
-                    # it works.
+                    # Idle at 240Mi; 884Mi with CLIP, face recognition and
+                    # OCR loaded (2026-10-28, a test image through each).
                     resources:
                       requests:
                         cpu: 50m
                         memory: 1Gi
+                      limits:
+                        memory: 2Gi
                     env:
                       TRANSFORMERS_CACHE: /cache
                       HF_XET_CACHE: /cache/huggingface-xet

immich/postgresql-backup.yaml

@@ -71,6 +71,8 @@ spec:
       requests:
         cpu: 10m
         memory: 64Mi
+      limits:
+        memory: 512Mi
     env:
       # Newer boto3 adds checksums that S3-compatible stores can reject;
       # the plugin's docs suggest sending them only when required.

immich/postgresql-cluster-17.yaml

@@ -13,6 +13,8 @@ spec:
     requests:
       cpu: 20m
       memory: 320Mi
+    limits:
+      memory: 1Gi
 
   postgresql:
     shared_preload_libraries:
@@ -27,7 +29,10 @@ spec:
 
   # Filled once from the PostgreSQL 14 cluster (immich-postgres) after its
   # embedding columns were turned into real[] and pgvecto.rs was dropped,
-  # see docs/upgrade-k8s-1.33.md.
+  # see docs/upgrade-k8s-1.33.md. That cluster is gone since 2026-10-28, so
+  # creating this Cluster again fails here, on purpose: an empty database
+  # would start immich with an empty library. Restore from Garage instead
+  # (bootstrap.recovery, see postgresql-backup.yaml).
   bootstrap:
     initdb:
       database: immich

immich/postgresql-cluster.yaml

@@ -1,28 +0,0 @@
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: immich-postgres
-  namespace: immich
-spec:
-  instances: 1
-
-  # Use TensorChord's CNPG-compatible image with pgvecto.rs v0.2.1
-  imageName: ghcr.io/tensorchord/cloudnative-pgvecto.rs:14-v0.2.1
-
-  postgresql:
-    shared_preload_libraries:
-      - "vectors.so"
-
-  bootstrap:
-    initdb:
-      database: immich
-      owner: immich
-      postInitSQL:
-        - CREATE EXTENSION IF NOT EXISTS vectors;
-        - CREATE EXTENSION IF NOT EXISTS cube;
-        - CREATE EXTENSION IF NOT EXISTS earthdistance CASCADE;
-        - ALTER USER immich WITH SUPERUSER;
-
-  storage:
-    size: 20Gi
-    storageClass: longhorn

immich/share-sync.yaml

@@ -8,6 +8,10 @@
 # - the group account's library is shared as a partner and shown in
 #   everyone's timeline, so search covers it (immich only searches your own
 #   and your timeline partners' photos);
+# - everyone is put in the group account's cluster group and gets its
+#   people (person sharing, immich 3.3): people are per user, and a partner
+#   library doesn't bring its people along. Those who may upload can name
+#   them, for everyone;
 # - the invitation notifications for albums older than a week are hidden,
 #   or a new member would get one per album;
 # - sessions of OAuth users older than SESSION_MAX_AGE_DAYS are ended, so
@@ -15,8 +19,11 @@
 #   Online.
 # Albums and partners go through the API. Joining other people's albums
 # (the API only lets an album's owner or editors share it), the timeline
-# flag (which only the receiving user can set), the notifications and the
-# sessions go straight to the database.
+# flag and the cluster group (which only the receiving user can set or
+# accept), sharing the people (the API wants person.update, which the
+# group's key lacks, and with password login off nobody can log in as the
+# group to add it), the notifications and the sessions go straight to the
+# database.
 apiVersion: v1
 kind: ConfigMap
 metadata:
@@ -24,6 +31,7 @@ metadata:
   namespace: immich
 data:
   sync.py: |
+    import collections
     import json
     import os
     import subprocess
@@ -129,6 +137,62 @@ data:
         'UPDATE partner SET "inTimeline" = true WHERE "sharedById" = :\'group\' AND NOT "inTimeline"',
         group=group_id,
     )
+    # What accepting an invitation to the group account's cluster group does
+    # (ClusterGroupService.acceptRequest): the person groups only the member
+    # has people in move along. Members with people in groups that others
+    # also have people in are left alone; that only happens after sharing.
+    for (email,) in sql(
+        """
+        BEGIN;
+        CREATE TEMP TABLE moving ON COMMIT DROP AS
+        SELECT u.id FROM "user" u, "user" g
+        WHERE g.id = :'group' AND u.id = ANY (:'members'::uuid[])
+          AND u."clusterGroupId" <> g."clusterGroupId"
+          AND NOT EXISTS (
+            SELECT 1 FROM person p
+            JOIN person o ON o."personGroupId" = p."personGroupId" AND o."ownerId" <> p."ownerId"
+            WHERE p."ownerId" = u.id
+          );
+        UPDATE person_group SET "clusterGroupId" = (SELECT "clusterGroupId" FROM "user" WHERE id = :'group')
+        WHERE id IN (SELECT p."personGroupId" FROM person p JOIN moving m ON m.id = p."ownerId");
+        DELETE FROM cluster_group_request
+        WHERE "userId" IN (SELECT id FROM moving)
+          AND "clusterGroupId" = (SELECT "clusterGroupId" FROM "user" WHERE id = :'group');
+        UPDATE "user" SET "clusterGroupId" = (SELECT "clusterGroupId" FROM "user" WHERE id = :'group')
+        WHERE id IN (SELECT id FROM moving)
+        RETURNING email;
+        COMMIT;
+        """,
+        group=group_id,
+        members="{" + ",".join(members) + "}",
+    ):
+        print(f"put {email} in the group's cluster group", flush=True)
+    # What PUT /people/users does for the group account: its people, with
+    # their names, in every member's people list and search filters. Write
+    # access (naming people, for everyone) for those who may upload.
+    shared = sql(
+        """
+        INSERT INTO person_user ("personGroupId", "sharedById", "sharedWithId", role)
+        SELECT p."personGroupId", p."ownerId", m.id, m.role::person_user_role_enum
+        FROM person p
+        JOIN "user" g ON g.id = p."ownerId"
+        CROSS JOIN unnest(:'ids'::uuid[], :'roles'::text[]) AS m(id, role)
+        JOIN "user" u ON u.id = m.id AND u."clusterGroupId" = g."clusterGroupId"
+        WHERE p."ownerId" = :'group' AND NOT p."isHidden"
+          AND NOT EXISTS (
+            SELECT 1 FROM person_user pu
+            WHERE pu."personGroupId" = p."personGroupId" AND pu."sharedById" = p."ownerId"
+              AND pu."sharedWithId" = m.id AND pu.role = m.role::person_user_role_enum
+          )
+        ON CONFLICT ("personGroupId", "sharedById", "sharedWithId") DO UPDATE SET role = EXCLUDED.role
+        RETURNING "sharedWithId", role
+        """,
+        group=group_id,
+        ids="{" + ",".join(wanted) + "}",
+        roles="{" + ",".join("read" if role == "viewer" else "write" for role in wanted.values()) + "}",
+    )
+    for (uid, role), count in sorted(collections.Counter(map(tuple, shared)).items()):
+        print(f"share {count} people with {members[uid]} ({role})", flush=True)
     sql(
         """
         UPDATE notification SET "deletedAt" = now()

mariadb-operator/operator-crds-helm.yaml

@@ -13,7 +13,7 @@ spec:
   source:
     chart: mariadb-operator-crds
     repoURL: https://mariadb-operator.github.io/mariadb-operator
-    targetRevision: 25.10.4
+    targetRevision: 26.10.2
   syncPolicy:
     automated:
       prune: true

mariadb-operator/operator-helm.yaml

@@ -13,13 +13,15 @@ spec:
   source:
     chart: mariadb-operator
     repoURL: https://mariadb-operator.github.io/mariadb-operator
-    targetRevision: 25.10.4
+    targetRevision: 26.10.2
     helm:
       values: |
         resources:
           requests:
             cpu: 10m
             memory: 48Mi
+          limits:
+            memory: 128Mi
         metrics:
           enabled: true
           serviceMonitor:
@@ -29,6 +31,8 @@ spec:
             requests:
               cpu: 10m
               memory: 32Mi
+            limits:
+              memory: 128Mi
           serviceMonitor:
             enabled: false
         certController:
@@ -36,6 +40,8 @@ spec:
             requests:
               cpu: 10m
               memory: 32Mi
+            limits:
+              memory: 128Mi
           serviceMonitor:
             enabled: false
   syncPolicy:

mbgwp/mariadb-cluster.yaml

@@ -8,7 +8,7 @@ spec:
     name: mbgwp-mariadb-credentials
     key: root-password
 
-  image: mariadb:11.4.5
+  image: mariadb:11.4.13
   imagePullPolicy: IfNotPresent
 
   port: 3306

renovate.json

@@ -82,14 +82,20 @@
       "description": "A PostgreSQL major upgrade needs pg_upgrade or a dump, not a tag bump",
       "matchDepNames": [
         "ghcr.io/cloudnative-pg/postgresql",
-        "ghcr.io/tensorchord/cloudnative-vectorchord",
-        "ghcr.io/tensorchord/cloudnative-pgvecto.rs"
+        "ghcr.io/tensorchord/cloudnative-vectorchord"
       ],
       "matchUpdateTypes": [
         "major"
       ],
       "enabled": false
     },
+    {
+      "description": "MariaDB goes from one LTS to the next by hand, after a dump: there is no way back. 11.4 has community support until May 2029, longer than 11.8 (June 2028); the next step is 12.3 (June 2029). Within 11.4 the patches come through",
+      "matchDepNames": [
+        "mariadb"
+      ],
+      "allowedVersions": "<11.5"
+    },
     {
       "description": "Patch updates of apps that hold little state and are easy to roll back, and of CI's tools, merge themselves once CI passes: three days after the release, in the evening or at the weekend, when the cluster can be reached. Not the databases, operators, Vault, authentik, Longhorn, Velero, immich, Gitea or WordPress. Renovate merges itself; the repo has no branch protection for GitHub's auto-merge to wait on",
       "matchFileNames": [

serpbear/serpbear-deployment.yaml

@@ -60,6 +60,8 @@ spec:
             requests:
               cpu: 10m
               memory: 160Mi
+            limits:
+              memory: 512Mi
           readinessProbe:
             httpGet:
               path: /login

vault/overrides.yaml

@@ -7,6 +7,8 @@ injector:
       requests:
          cpu: 10m
          memory: 32Mi
+      limits:
+         memory: 128Mi
    # The chart's default anti-affinity forbids two injector pods on one
    # node, so on this single node a rolling update can never start the new
    # pod while the old one runs. Recreate removes the old pod first, which

velero/velero-helm.yaml

@@ -71,6 +71,8 @@ spec:
             requests:
               cpu: 10m
               memory: 64Mi
+            limits:
+              memory: 128Mi
         # 512Mi got the server OOMKilled 314 times, including halfway
         # through a backup of ~14.7k items.
         resources: