Merge pull request 'feat: umami 3.1.0 + filebrowser v2.63.13 (root)' (#4) from feat/umami-v3-filebrowser-root into main

This commit was merged in pull request #4.
This commit is contained in:
2026-06-06 12:17:21 +00:00
2 changed files with 10 additions and 15 deletions
+1 -9
View File
@@ -187,15 +187,7 @@ spec:
cpu: "50m"
containers:
- name: umami
# NOTE: pinned to the exact image SHA the working 120d-old pod
# is on. v1.38.0 (the latest postgresql-vX.Y.Z) tries to apply
# migration `02_add_event_data` which requires an `event` table
# that this DB doesn't have -- the DB schema is older than v1
# numbered migrations expect. Until we plan a proper migration
# (likely to umami v3.x, which is what the dashboard `→ 3.1`
# hint suggests), this stays SHA-pinned so Renovate doesn't
# touch it and pod restarts don't roll the version forward.
image: ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9bd33b7a278e9342a88e0bdac812416c9f9e4361
image: ghcr.io/umami-software/umami:3.1.0
ports:
- containerPort: 3000
env:
+9 -6
View File
@@ -105,14 +105,17 @@ spec:
labels:
app: filebrowser
spec:
# filebrowser v2.63.13 (debian default) runs as a non-root UID by default
# and can't write to PVC files left by the previous v2-alpine image (which
# ran as root). Force root explicitly so the existing PVC contents are
# readable + writable. (The alternative -- chown the PVC then drop perms --
# needs a one-shot initContainer; not worth the moving parts here.)
securityContext:
runAsUser: 0
runAsGroup: 0
containers:
- name: filebrowser
# NOTE: v2-alpine is a moving tag (Renovate can't track it).
# Pinning to v2.63.13 (debian-based default) broke the PVC permissions
# (the image runs as a non-root UID and can't write to files left
# by the alpine variant). A clean re-pin needs either an initContainer
# to chown the PVC, or a fsGroup on the pod spec. Revisit when time permits.
image: filebrowser/filebrowser:v2-alpine
image: filebrowser/filebrowser:v2.63.13
ports:
- containerPort: 8080
volumeMounts: