betrieb/upgrades.md

---
title: Upgrades
description: Stack aktualisieren — alles über GitOps
published: true
date: 2026-08-14T14:34:49.634Z
tags: 
editor: markdown
dateCreated: 2026-08-13T20:27:33.029Z
---

Der Stack wird per **GitOps** aktualisiert — nichts von Hand am Cluster, alles über einen Commit nach git.lab (**nie direkt nach Gitea** pushen).

## ESS-Chart
- Chart-Version in `apps/production/element-server-suite.yaml` (HelmRelease) anheben, committen → Flux zieht die neue Version.
- Vorher das Changelog/Breaking-Changes der ESS-Version prüfen (die Schema-Validierung ist streng — ungültige Werte brechen den Reconcile mit kryptischen Fehlern).

## Einzel-Images (Authentik, coturn, ClamAV, Draupnir, Wiki.js …)
- Image-Tag im jeweiligen Manifest anheben, committen → Flux rollt neu aus.
- Bei DB-Schema-Migrationen (Authentik, Wiki.js): vorher ein aktuelles **Backup** sicherstellen.

## Ablauf
1. Backup-Stand prüfen.
2. Version im Repo anheben, committen, nach git.lab pushen.
3. `flux reconcile` beobachten; Pods + Health prüfen.
4. Bei Problemen: Commit zurückrollen — GitOps macht das Rollback trivial.


## Stack-Anpassungen & Fork-Porting

Beim Upgrade der zugrundeliegenden Element-/Synapse-Versionen müssen **unsere Anpassungen
mit**. Wo sie liegen:

| Komponente | Basis | Änderungen dokumentiert in |
|---|---|---|
| **ThreadNet Web** (Element-Web-Fork) | Element Web/Desktop `1.12.17` | `ThreadNet-Web:docs/axion1337-fork.md` · [/betrieb/element-customization](/betrieb/element-customization) |
| **threadnet-call** (Element-Call-Fork) | Element Call `0.19.2` (via `emmick4/element-call` `livekit`) | `threadnet-call:docs/axion1337-fork.md` · [/betrieb/element-call](/betrieb/element-call) |
| **Synapse & Stack** | ESS `v26.4.0` — **kein** Code-Fork, nur Config/Module | gitops (`synapse-values.yaml`, `clamav_spam_checker.py`, …) + die jeweiligen Betriebsseiten |

**Ablauf beim Element-Upgrade eines Forks:**
1. Ziel-Upstream-Version wählen; das jeweilige `axion1337-fork.md` ist die **Liste dessen,
   was re-appliziert/geportet werden muss**.
2. Rebase/Merge auf die neue Version; die dort genannten **kritischen Dateien** zuerst
   prüfen (dort sitzt die Merge-Reibung).
3. Bauen, Image nach Gitea publizieren, im gitops-Stack die Version anheben (siehe oben).

**Synapse/Stack ist kein Fork:** unsere Eingriffe sind GitOps-Config (Room-Policies,
ClamAV-Modul, Backups, TURN-Rotation …) und wandern mit dem ESS-Chart-Upgrade automatisch
mit — dokumentiert auf den jeweiligen Betriebsseiten, nicht als Code-Diff.


## Wiki.js: Startup-Patch (Zeitzone)

Wiki.js läuft als **Upstream-Image** (`ghcr.io/requarks/wiki:2.5`) — **kein** Code-Fork, keine Build-Pipeline. Unsere eine Anpassung wird als **Startup-Overlay** im Deployment (`apps/production/wikijs.yaml`, Container-`command`) eingespielt: neue OIDC-Nutzer bekommen `timezone: 'Europe/Berlin'` statt des Wiki.js-Defaults `America/New_York`. Wiki.js legt SSO-Nutzer in `processProfile` (`server/models/users.js`) ohne Zeitzone an, sonst greift der DB-Spalten-Default (New York). Der Container `sed`-patcht die Datei vor dem Boot — **idempotent** (grep-Guard) und **fail-open** (Wiki.js startet auch, wenn der Patch nicht greift; neue Nutzer fielen dann auf New York zurück).

⚠️ **Beim Wiki.js-Upgrade prüfen:** Der Patch hängt am Anker `localeCode: WIKI.config.lang.code,` in `users.js`. Ändert sich diese Zeile in einer neueren Version, muss der `sed` im Deployment nachgezogen werden (der ⚠️-Kommentar steht direkt im Manifest). Gleiche Logik wie bei den Element-Forks oben: Upstream-Bump → Patch gegenprüfen → ggf. Anker anpassen. Der `localeCode` selbst kommt bereits aus der Standard-Locale (`de`), nur die Zeitzone braucht den Patch.

## Kadenz & CVE-Bezug

Updates sind zugleich unser wichtigster **CVE-Fix** (siehe [Sicherheit & CVE-Remediation](/betrieb/sicherheit)). Deshalb:
- **Regelmäßig** (Richtwert monatlich) Basis-Images/Charts anheben — nicht warten, bis der Report explodiert.
- **Ad-hoc** bei einer CRITICAL-CVE mit verfügbarem Fix.
- `:latest`-Tags vermeiden (z.B. coturn) — sonst kein reproduzierbarer/scanbarer Stand.
docs: create betrieb/upgrades 2026-08-13 20:27:38 +00:00			`---`
			`title: Upgrades`
			`description: Stack aktualisieren — alles über GitOps`
			`published: true`
docs: update betrieb/upgrades 2026-08-14 14:34:53 +00:00			`date: 2026-08-14T14:34:49.634Z`
docs: create betrieb/upgrades 2026-08-13 20:27:38 +00:00			`tags:`
			`editor: markdown`
			`dateCreated: 2026-08-13T20:27:33.029Z`
			`---`

			`Der Stack wird per GitOps aktualisiert — nichts von Hand am Cluster, alles über einen Commit nach git.lab (nie direkt nach Gitea pushen).`

			`## ESS-Chart`
			- Chart-Version in `apps/production/element-server-suite.yaml` (HelmRelease) anheben, committen → Flux zieht die neue Version.
			`- Vorher das Changelog/Breaking-Changes der ESS-Version prüfen (die Schema-Validierung ist streng — ungültige Werte brechen den Reconcile mit kryptischen Fehlern).`

			`## Einzel-Images (Authentik, coturn, ClamAV, Draupnir, Wiki.js …)`
			`- Image-Tag im jeweiligen Manifest anheben, committen → Flux rollt neu aus.`
			`- Bei DB-Schema-Migrationen (Authentik, Wiki.js): vorher ein aktuelles Backup sicherstellen.`

			`## Ablauf`
			`1. Backup-Stand prüfen.`
			`2. Version im Repo anheben, committen, nach git.lab pushen.`
			3. `flux reconcile` beobachten; Pods + Health prüfen.
			`4. Bei Problemen: Commit zurückrollen — GitOps macht das Rollback trivial.`
docs: update betrieb/upgrades 2026-08-13 22:14:12 +00:00

			`## Stack-Anpassungen & Fork-Porting`

			`Beim Upgrade der zugrundeliegenden Element-/Synapse-Versionen müssen **unsere Anpassungen`
			`mit**. Wo sie liegen:`

			`\| Komponente \| Basis \| Änderungen dokumentiert in \|`
			`\|---\|---\|---\|`
			\| ThreadNet Web (Element-Web-Fork) \| Element Web/Desktop `1.12.17` \| `ThreadNet-Web:docs/axion1337-fork.md` · [/betrieb/element-customization](/betrieb/element-customization) \|
			\| threadnet-call (Element-Call-Fork) \| Element Call `0.19.2` (via `emmick4/element-call` `livekit`) \| `threadnet-call:docs/axion1337-fork.md` · [/betrieb/element-call](/betrieb/element-call) \|
			\| Synapse & Stack \| ESS `v26.4.0` — kein Code-Fork, nur Config/Module \| gitops (`synapse-values.yaml`, `clamav_spam_checker.py`, …) + die jeweiligen Betriebsseiten \|

			`Ablauf beim Element-Upgrade eines Forks:`
			1. Ziel-Upstream-Version wählen; das jeweilige `axion1337-fork.md` ist die **Liste dessen,
			`was re-appliziert/geportet werden muss**.`
			`2. Rebase/Merge auf die neue Version; die dort genannten kritischen Dateien zuerst`
			`prüfen (dort sitzt die Merge-Reibung).`
			`3. Bauen, Image nach Gitea publizieren, im gitops-Stack die Version anheben (siehe oben).`

			`Synapse/Stack ist kein Fork: unsere Eingriffe sind GitOps-Config (Room-Policies,`
			`ClamAV-Modul, Backups, TURN-Rotation …) und wandern mit dem ESS-Chart-Upgrade automatisch`
			`mit — dokumentiert auf den jeweiligen Betriebsseiten, nicht als Code-Diff.`
docs: update betrieb/upgrades 2026-08-14 04:58:12 +00:00

docs: update betrieb/upgrades 2026-08-14 14:34:53 +00:00			`## Wiki.js: Startup-Patch (Zeitzone)`

			Wiki.js läuft als Upstream-Image (`ghcr.io/requarks/wiki:2.5`) — kein Code-Fork, keine Build-Pipeline. Unsere eine Anpassung wird als Startup-Overlay im Deployment (`apps/production/wikijs.yaml`, Container-`command`) eingespielt: neue OIDC-Nutzer bekommen `timezone: 'Europe/Berlin'` statt des Wiki.js-Defaults `America/New_York`. Wiki.js legt SSO-Nutzer in `processProfile` (`server/models/users.js`) ohne Zeitzone an, sonst greift der DB-Spalten-Default (New York). Der Container `sed`-patcht die Datei vor dem Boot — idempotent (grep-Guard) und fail-open (Wiki.js startet auch, wenn der Patch nicht greift; neue Nutzer fielen dann auf New York zurück).

			⚠️ Beim Wiki.js-Upgrade prüfen: Der Patch hängt am Anker `localeCode: WIKI.config.lang.code,` in `users.js`. Ändert sich diese Zeile in einer neueren Version, muss der `sed` im Deployment nachgezogen werden (der ⚠️-Kommentar steht direkt im Manifest). Gleiche Logik wie bei den Element-Forks oben: Upstream-Bump → Patch gegenprüfen → ggf. Anker anpassen. Der `localeCode` selbst kommt bereits aus der Standard-Locale (`de`), nur die Zeitzone braucht den Patch.

docs: update betrieb/upgrades 2026-08-14 04:58:12 +00:00			`## Kadenz & CVE-Bezug`

			`Updates sind zugleich unser wichtigster CVE-Fix (siehe [Sicherheit & CVE-Remediation](/betrieb/sicherheit)). Deshalb:`
			`- Regelmäßig (Richtwert monatlich) Basis-Images/Charts anheben — nicht warten, bis der Report explodiert.`
			`- Ad-hoc bei einer CRITICAL-CVE mit verfügbarem Fix.`
			- `:latest`-Tags vermeiden (z.B. coturn) — sonst kein reproduzierbarer/scanbarer Stand.