requirements.txt stand durchgehend auf ">=", die gebaute Version hing also am
Kalendertag statt am Repo. Genau daran ist der letzte Deploy gescheitert.
Jetzt exakt die Versionen, gegen die die Suite grün ist und die produktiv
laufen — Updates werden damit zu einer bewussten Änderung mit CI-Lauf.
Django bleibt auf 6.1: dorthin ist die Instanz ohnehin schon gedriftet, es
läuft, und 4.2 LTS ist seit April 2026 aus dem Support.
Dabei ist aufgefallen, dass Django 5.1 STATICFILES_STORAGE entfernt hat. Die
Einstellung stand noch da und wurde stillschweigend ignoriert, womit
whitenoise auf StaticFilesStorage zurückfiel und Assets unkomprimiert
auslieferte — app.js mit 251 KB statt 62 KB bei jedem kalten Laden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der erste Rebuild seit dem 17.08. zog gunicorn 26.2.0, dessen ggevent.py
packaging.version importiert, während das Paket selbst überhaupt keine
Dependencies deklariert ("Requires:" ist leer). Damit fehlte packaging im
Image und gunicorn brach beim Start ab:
Error: class uri 'gevent' invalid or not found
ModuleNotFoundError: No module named 'packaging'
Beides wandert nach requirements.txt, und das Dockerfile installiert
gunicorn nicht mehr ungepinnt nebenher — sonst kann der nächste Rebuild den
Worker wieder unter uns austauschen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SSE connections for radio streams were blocking sync gunicorn workers,
leaving the app unresponsive. Switching to gevent with 4 workers and
a higher timeout fixes concurrent SSE + normal request handling.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
