diff --git a/k8s/05-app-deployment.yaml b/k8s/05-app-deployment.yaml
index 226df83..f01a44d 100644
--- a/k8s/05-app-deployment.yaml
+++ b/k8s/05-app-deployment.yaml
@@ -78,12 +78,32 @@ spec:
             initialDelaySeconds: 30
             periodSeconds: 30
             failureThreshold: 5
+          # Bemessen nach dem teuersten Vorgang der Anwendung, dem
+          # Admin-Video-Upload: Node laedt den multipart-Body beim
+          # request.formData() vollstaendig in den Speicher, und die Datei
+          # darf bis zu 100 MB gross sein (MAX_UPLOAD_VIDEO_BYTES in
+          # lib/uploads.ts). Zusammen mit dem Grundverbrauch des
+          # Next.js-Servers sprengte das ein Limit von 512Mi — der Kernel
+          # beendet den Prozess dann mitten im Upload (OOMKilled), und im
+          # Browser kommt davon nur die HTML-Fehlerseite des Reverse-Proxy an
+          # ("Unexpected token '<', "<!DOCTYPE "... is not valid JSON").
+          #
+          # Die Route selbst haelt inzwischen nur noch den Body im Speicher
+          # und streamt alles Weitere ueber die Platte (siehe
+          # app/api/admin/upload-video/route.ts) — 1Gi gibt darueber hinaus
+          # Reserve, damit ein zweiter gleichzeitiger Zugriff den Pod nicht
+          # kippt.
+          #
+          # ffmpeg ist CPU-gebunden: mit nur 100m dauert das Umrechnen ein
+          # Vielfaches und laeuft eher in ein Proxy-Zeitlimit. Bewusst KEIN
+          # CPU-Limit, nur ein hoeherer Request — ein Limit wuerde den
+          # Transcode hart drosseln, auch wenn der Knoten gerade frei ist.
           resources:
             requests:
-              cpu: 100m
-              memory: 256Mi
-            limits:
+              cpu: 500m
               memory: 512Mi
+            limits:
+              memory: 1Gi
       volumes:
         # Platzhalter — die Betreiberin ergaenzt hier ihre eigene
         # Volume-Quelle fuer den Namen "uploads" (z.B. ein PVC, das gegen
diff --git a/k8s/06-ingress.yaml b/k8s/06-ingress.yaml
index 49264fb..402970d 100644
--- a/k8s/06-ingress.yaml
+++ b/k8s/06-ingress.yaml
@@ -27,6 +27,26 @@ metadata:
     # der beiden Limits (100 MB) plus etwas Spielraum fuer den
     # multipart/form-data-Overhead ab.
     nginx.ingress.kubernetes.io/proxy-body-size: "110m"
+    # Ohne diese drei Annotationen wartet ingress-nginx nur 60 Sekunden je
+    # Phase und liefert danach eine eigene HTML-Fehlerseite (504) aus. Der
+    # Video-Upload braucht regelmaessig laenger: erst muessen bis zu 100 MB
+    # ueber die Leitung, danach rechnet ffmpeg das Video fuers Web um (siehe
+    # lib/video-transcode.ts). Im Browser kam davon nur an, dass die Antwort
+    # kein JSON war ("Unexpected token '<', "<!DOCTYPE "... is not valid
+    # JSON") — die Ursache war daraus nicht ablesbar.
+    #
+    # 600s deckt den langsamsten realistischen Fall ab und liegt bewusst
+    # oberhalb des harten ffmpeg-Zeitlimits von 5 Minuten
+    # (TRANSCODE_TIMEOUT_MS in lib/video-transcode.ts): so bricht im Zweifel
+    # die Anwendung selbst mit einer verwertbaren JSON-Meldung ab, statt dass
+    # nginx die Verbindung vorher kappt.
+    #
+    # Achtung: sitzt zusaetzlich ein CDN davor (z.B. Cloudflare), gilt dessen
+    # eigenes Origin-Zeitlimit unabhaengig hiervon weiter — bei Cloudflare
+    # sind das 100 Sekunden (Fehler 524), ebenfalls als HTML-Seite.
+    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
+    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
+    nginx.ingress.kubernetes.io/proxy-connect-timeout: "60"
 spec:
   ingressClassName: nginx
   tls: