---
created: 2026-08-11
title: Compose-Datei auf dem Testserver ist eine handgepflegte Kopie und driftet vom Repository ab
area: infra
severity: major
trigger: bevor eine zweite Installation (Kunde oder Produktivsystem) aufgesetzt wird
files:
  - docker-compose.yml
  - docker-compose.prod.yml
  - /opt/tessera/docker-compose.yml (auf 192.168.13.12, nicht im Repository)
---

## Problem

`/opt/tessera` auf dem Testserver (192.168.13.12) ist **keine** Git-Arbeitskopie —
dort liegt eine von Hand gepflegte `docker-compose.yml`. Der Deploy-Weg holt nur
die Images aus der Registry; Aenderungen an den Compose-Dateien im Repository
kommen dort nie an.

Am 2026-08-11 konkret aufgefallen: Der umbenannte Verschluesselungsschluessel
(`TESSERA_ENCRYPTION_KEY`, Commit f574884) wurde in die `.env` auf dem Server
eingetragen, kam aber nicht im Container an, weil die dortige Compose-Datei die
Variable gar nicht durchreicht. Die Anwendung fiel deshalb auf den alten Namen
zurueck und protokollierte die Veraltet-Warnung. Behoben durch eine
Hand-Aenderung an der Server-Datei — was das Problem genau wiederholt.

Zweiter, wichtigerer Effekt: die im selben Zug eingebaute Absicherung "Stack
startet nicht ohne Schluessel" (Commit 7bda56d) greift auf alpha **nicht**, weil
sie nur in der Repository-Datei steht. Beide Dateien laufen seit dem 2026-08-11
inhaltlich auseinander, und niemand merkt es, bis etwas nicht tut.

Fuer eine Kundeninstallation heisst das: aufgesetzt wird nach dem Repository,
alpha laeuft nach seiner eigenen Kopie. Was auf alpha funktioniert, ist damit
kein Beleg dafuer, dass die ausgelieferte Konfiguration funktioniert — und
genau dafuer ist ein Testsystem da.

## Solution

Noch offen, drei denkbare Wege — Entscheidung gehoert vor die Umsetzung:

1. **`/opt/tessera` zur Arbeitskopie machen.** `git clone`, danach zieht ein
   `git pull` Compose-Datei und Deploy-Anleitung mit. Einfachster Weg, aber der
   Server braucht dann Lesezugriff auf das Repository, und lokale Anpassungen
   (die es geben mag) muessen vorher sichtbar gemacht werden.
2. **Compose-Datei als Artefakt ausliefern.** Die CI legt die passende Datei zu
   jedem Image-Build ab, der Server holt sie zusammen mit den Images. Sauberste
   Trennung, meiste Arbeit.
3. **Unterschiede bewusst machen.** Die Server-Datei bleibt handgepflegt, aber
   ein Abgleich-Skript meldet Abweichungen zur Repository-Version. Loest das
   Problem nicht, macht es aber sichtbar.

Vor der Entscheidung zu klaeren: **warum** die Datei dort ueberhaupt von Hand
gepflegt wird. Moeglicherweise enthaelt sie Anpassungen, die im Repository
fehlen (Ports, Netzwerke, Volumes fuer den konkreten Host) — die muessten dann
erst ins Repository, sonst bricht Weg 1 oder 2 den laufenden Betrieb.

Eine Sicherung der aktuellen Server-Datei liegt als
`/opt/tessera/docker-compose.yml.bak.20260811` daneben.