diff --git a/DEPLOYMENT.md b/DEPLOYMENT.md
index efb76d2..c43b519 100644
--- a/DEPLOYMENT.md
+++ b/DEPLOYMENT.md
@@ -1,17 +1,19 @@
 # Deployment mit Docker
 
-Dieser Guide beschreibt, wie die App (bisher auf Vercel deployed, siehe
-`vercel.json`) stattdessen als Docker-Container auf einem beliebigen Server
-läuft.
+Dieser Guide beschreibt, wie die App als Docker-Container auf einem eigenen
+Linux-Server läuft.
 
 ## Was wird containerisiert – und was nicht
 
 - **Containerisiert:** nur die Next.js-App selbst (`Dockerfile`).
-- **Nicht containerisiert:** Supabase (Datenbank + Auth). Die App verbindet
-  sich per URL/Key zu einem bestehenden Supabase-Projekt (Cloud oder
-  selbst gehostet) – das bleibt unverändert. `supabase/` in diesem Repo ist
-  nur die lokale Dev-/Migrations-Umgebung (`supabase start`), kein Teil des
-  Deployments.
+- **Nicht containerisiert:** die Datenbank. Die App verbindet sich über
+  `DATABASE_URL` zu einem beliebigen PostgreSQL ab 15 — heute ein
+  Supabase-Projekt, genauso möglich sind Azure Flexible Server, RDS,
+  Cloud SQL oder eigenes Blech. `supabase/` in diesem Repo ist die
+  Migrations- und Entwicklungsumgebung, kein Teil des Deployments.
+- **Ebenfalls nicht containerisiert:** die Anmeldung. Sie läuft über
+  Microsoft Entra ID; die App hält nur das Sitzungscookie (Auth.js). Es gibt
+  keinen Anmeldedienst, der mit ausgerollt werden müsste.
 - **Ersetzt:** der Vercel-Cron-Job aus `vercel.json` (täglich 03:00 Uhr,
   ruft `/api/cron/apply-pending-changes` auf, um fällige Versetzungen/
   Beförderungen/Karenz/Reorg-Änderungen zu übernehmen). Da es außerhalb von
@@ -83,11 +85,13 @@ docker compose up -d --build
 ```
 
 Alternative für CI/CD (Image einmal bauen, überall pullen): Image in einer
-Registry (GHCR, Docker Hub, …) bauen und pushen, auf dem Server nur
+Registry bauen und pushen, auf dem Server nur
 `docker compose pull && docker compose up -d` ausführen. Dafür in
-`docker-compose.yml` zusätzlich `image: <registry>/<name>:<tag>` setzen und
-den Build in der CI-Pipeline mit den `--build-arg`-Werten für
-`NEXT_PUBLIC_*` laufen lassen.
+`docker-compose.yml` zusätzlich `image: <registry>/<name>:<tag>` setzen.
+
+Build-Argumente braucht es dabei **keine**: das Abbild enthält keine
+umgebungsabhängigen Werte mehr, alles kommt zur Laufzeit aus `.env`.
+Dasselbe Abbild läuft damit in Test und Produktion.
 
 ## 4. Reverse Proxy + HTTPS