---
title: Upgrades
description: Stack aktualisieren — alles über GitOps
published: true
date: 2026-08-13T22:14:08.333Z
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.