aidlc-docs/features/react-frontend/audit.md

@@ -576,3 +576,15 @@
 **Context**: Post-workflow follow-up (feature already marked Complete); addresses the "Analytics/uptime dashboard" open item from `production-readiness-checklist.md`. Work done on `feature/analytics_uptime_dashboard`. `pnpm run build`, `pnpm run lint`, and `pnpm run test` to be verified before committing.
 
 ---
+
+## Post-Completion Follow-up: Umami Moved to a Dedicated `umami` User (Podman Isolation Pattern)
+
+**Timestamp**: 2026-07-25T21:20:00Z
+
+**User Input**: "Ja, ik wil wel meer de kant op gaan van de verschillende self-hosted services als losse users. Maakt mij flexibeler als ik later meer wil ookal is een raspberry pi beperkt in rekenkracht" (confirming, after a prior explanation, the preference for a dedicated Linux user per self-hosted service instead of a shared folder under the existing user account).
+
+**AI Response**: "Reworked `operations/monitoring/umami-setup.md` to run Umami under a new dedicated `umami` Linux user instead of the existing main user account: added a new "Waarom een dedicated user" section explaining the rootless-Podman isolation rationale, and a new step 0 covering `useradd --create-home`, verifying/adding a subuid/subgid range (`/etc/subuid`/`/etc/subgid`), and `loginctl enable-linger umami` so rootless Podman services keep running without an active login. Updated step 1 (container setup) and step 2 (systemd auto-start) to run as the `umami` user (`sudo -iu umami`), with paths now under `/home/umami/umami/`. Extended the outstanding manual steps list with the new user-creation step, and added a closing note documenting this as a reusable pattern for future self-hosted services on the same or other Pi's."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, refining the Umami deployment approach before it has been executed on the Pi. Documentation-only change (no code/build impact).
+
+---

aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md

@@ -5,15 +5,65 @@ webserver-Pi (Pi Main, `192.168.1.103`) met Podman, en bereikbaar te maken via
 `analytics.slpsoftware.nl`. Dit vult het "Analytics/uptime dashboard" open item uit
 `operations/production-readiness-checklist.md` in voor het analytics-gedeelte.
 
+Umami draait onder een **eigen dedicated Linux-user** (`umami`) in plaats van onder het
+bestaande hoofdaccount, zodat elke self-hosted service (nu en in de toekomst) netjes
+geïsoleerd blijft — zie "Waarom een dedicated user" hieronder. Dit patroon kan hergebruikt
+worden voor volgende self-hosted diensten op dezelfde Pi('s).
+
 ## Vereisten
-- Podman is al aanwezig op de Pi (bevestigd door de gebruiker).
+- Podman is al aanwezig op de Pi (bevestigd door de gebruiker) — systeembreed geïnstalleerd,
-- `podman-compose` geïnstalleerd: `pip3 install --user podman-compose` (of via de package
+  dus beschikbaar voor elke user, ook een nieuw aangemaakte.
-  manager van je distro, indien beschikbaar).
+- `podman-compose` geïnstalleerd voor de `umami`-user: `pip3 install --user podman-compose`
+  (of via de package manager van je distro, indien beschikbaar) — zie stap 0 hieronder.
 - DNS: een A-record voor `analytics.slpsoftware.nl` dat naar het publieke IP van de
   reverse-proxy-Pi wijst (dezelfde Pi die ook `test.slpsoftware.nl` afhandelt).
 
-## 1. Umami + database opzetten (op de webserver-Pi)
+## Waarom een dedicated user
-1. Maak een map aan, bv. `~/umami/`, en kopieer daarin:
+Podman zelf hoeft niet per user geïnstalleerd te worden (het is een systeembreed pakket),
+maar rootless Podman-containers erven wél de rechten van de user die ze start. Door Umami
+onder een eigen `umami`-user te draaien in plaats van je eigen hoofdaccount:
+- kan een kwetsbaarheid in de Umami-container (zelfs bij een container-escape binnen de
+  rootless-namespace) geen bestanden van je persoonlijke account lezen/schrijven;
+- houd je containerstorage, systemd user-services en logs van verschillende self-hosted
+  diensten netjes gescheiden per user, ook als je Pi qua rekenkracht beperkt is;
+- kun je dit patroon straks 1-op-1 hergebruiken voor een volgende self-hosted dienst (bv.
+  een eigen `uptime`-user, `git`-user, etc.), zonder dat diensten elkaars bestanden kunnen
+  benaderen.
+
+## 0. Dedicated `umami`-user aanmaken (op de webserver-Pi)
+1. Maak de user aan (zonder wachtwoord-login is prima, we loggen in via `sudo -iu umami` of
+   `su - umami`):
+   ```bash
+   sudo useradd --create-home --shell /bin/bash umami
+   sudo passwd -l umami   # login met wachtwoord blokkeren, sudo -iu blijft werken
+   ```
+2. Controleer dat er een subuid/subgid-range is toegewezen (nodig voor rootless Podman).
+   Op de meeste moderne distributies (incl. Raspberry Pi OS) gebeurt dit automatisch bij
+   `useradd`:
+   ```bash
+   grep umami /etc/subuid /etc/subgid
+   ```
+   Zie je geen output, voeg dan handmatig een range toe (pas de startwaarde aan als die al
+   in gebruik is door een andere user):
+   ```bash
+   sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 umami
+   ```
+3. Zorg dat de `umami`-sessie blijft "linger-en", zodat rootless Podman-services ook
+   actief blijven zonder dat de user is ingelogd (nodig voor stap 2 hieronder):
+   ```bash
+   sudo loginctl enable-linger umami
+   ```
+4. Log in als de nieuwe user om de rest van de setup uit te voeren:
+   ```bash
+   sudo -iu umami
+   ```
+
+## 1. Umami + database opzetten (als de `umami`-user, op de webserver-Pi)
+0. Installeer `podman-compose` voor deze user, indien nog niet systeembreed aanwezig:
+   ```bash
+   pip3 install --user podman-compose
+   ```
+1. Maak een map aan, bv. `~/umami/` (dit is nu `/home/umami/umami/`), en kopieer daarin:
    - `operations/deployment/umami/podman-compose.yml.example` → `~/umami/podman-compose.yml`
    - `operations/deployment/umami/.env.example` → `~/umami/.env`
 2. Vul in `~/umami/.env` een echte `POSTGRES_PASSWORD` en `APP_SECRET` in (bv. via
@@ -31,13 +81,12 @@ webserver-Pi (Pi Main, `192.168.1.103`) met Podman, en bereikbaar te maken via
 
 ## 2. Automatisch starten na reboot (systemd user service)
 Podman-compose start niet vanzelf op na een herstart van de Pi, tenzij je dit expliciet
-instelt. Omdat rootless Podman hier al gebruikt wordt, is een systemd **user**-service de
+instelt. Omdat rootless Podman hier al gebruikt wordt, is een systemd **user**-service —
-eenvoudigste aanpak:
+gekoppeld aan de `umami`-user — de eenvoudigste aanpak. De `loginctl enable-linger umami`
+uit stap 0.3 is hiervoor al gezet, dus deze service blijft ook draaien zonder dat de
+`umami`-user zelf is ingelogd.
 
-1. Zorg dat de gebruiker-sessie blijft "linger-en" na uitloggen/reboot:
+1. Log in (of blijf ingelogd) als de `umami`-user: `sudo -iu umami`.
-   ```bash
-   sudo loginctl enable-linger $(whoami)
-   ```
 2. Maak `~/.config/systemd/user/umami.service` aan:
    ```ini
    [Unit]
@@ -53,7 +102,7 @@ eenvoudigste aanpak:
    [Install]
    WantedBy=default.target
    ```
-3. Activeer en start de service:
+3. Activeer en start de service (nog steeds als de `umami`-user):
    ```bash
    systemctl --user daemon-reload
    systemctl --user enable --now umami.service
@@ -102,9 +151,19 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
 `.env.example`) én verwijder tijdelijk de `import.meta.env.DEV`-check.
 
 ## Openstaande handmatige stappen
-- [ ] `podman-compose up -d` daadwerkelijk draaien op Pi Main.
+- [ ] Dedicated `umami`-user aanmaken op Pi Main (incl. subuid/subgid-check en `loginctl enable-linger`).
-- [ ] Systemd user-service instellen voor auto-start na reboot.
+- [ ] `podman-compose up -d` daadwerkelijk draaien als de `umami`-user op Pi Main.
+- [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot.
 - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
 - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.
 - [ ] Website aanmaken in Umami en het Website ID overnemen.
 - [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen.
+
+## Vervolgstappen voor toekomstige self-hosted diensten
+Dit dedicated-user-patroon (stap 0 hierboven) is bewust generiek gehouden zodat het
+hergebruikt kan worden: een volgende self-hosted dienst op dezelfde of een andere Pi kan
+op dezelfde manier zijn eigen user krijgen (bv. `useradd --create-home`, subuid/subgid
+controleren, `loginctl enable-linger <user>`, eigen `~/.config/systemd/user/<dienst>.service`),
+zodat diensten onderling geïsoleerd blijven zonder dat dit ten koste gaat van de
+al beperkte rekenkracht van een Raspberry Pi (rootless Podman zelf blijft immers
+systeembreed gedeeld, alleen de user-context verandert per dienst).