diff --git a/install-notes/000-installation-index.md b/install-notes/000-installation-index.md
index 069f3b0..509299e 100644
--- a/install-notes/000-installation-index.md
+++ b/install-notes/000-installation-index.md
@@ -17,3 +17,5 @@
 - [015 - Initiales PostgreSQL-Datenbankschema und Migrationen](015-initiales-postgresql-datenbankschema-und-migrationen.md)
 
 - [016 - Datenbank-Healthcheck ausgelagert](016-datenbank-healthcheck-ausgelagert.md)
+
+- [017 - Serverstruktur: Status-API ausgelagert](017-serverstruktur-status-api-ausgelagert.md)
diff --git a/install-notes/017-serverstruktur-status-api-ausgelagert.md b/install-notes/017-serverstruktur-status-api-ausgelagert.md
new file mode 100644
index 0000000..a99e848
--- /dev/null
+++ b/install-notes/017-serverstruktur-status-api-ausgelagert.md
@@ -0,0 +1,125 @@
+# 017 - Serverstruktur: Status-API ausgelagert
+
+## Ziel
+
+Die Status-API wurde aus Main.kt ausgelagert, damit der Ktor-Server modularer aufgebaut ist.
+
+## Ausgangslage
+
+Vor diesem Schritt enthielt Main.kt mehrere Verantwortlichkeiten:
+
+- Serverstart
+- ContentNegotiation-Konfiguration
+- Routing
+- Status-DTOs
+- Status-Endpunkte
+- Datenbankstatus-Mapping
+
+Das war für den frühen Prototypen okay, wird aber bei wachsender API-Struktur unübersichtlich.
+
+## Änderung
+
+Es wurde ein neues API-Package angelegt:
+
+src/main/kotlin/de/ruvnox/tactical/api
+
+Neue Dateien:
+
+- StatusDtos.kt
+- StatusRoutes.kt
+
+Geänderte Datei:
+
+- Main.kt
+
+## StatusDtos.kt
+
+Diese Datei enthält die serialisierbaren Antwortmodelle für den Status-Endpunkt:
+
+- ServiceStatusResponse
+- DatabaseStatusResponse
+
+Die DTOs sind mit kotlinx.serialization Serializable annotiert.
+
+## StatusRoutes.kt
+
+Diese Datei enthält die Status-Routen:
+
+- GET /
+- GET /health
+- GET /api/v1/status
+
+Der Datenbankstatus wird über Database.check() abgefragt und in DatabaseStatusResponse gemappt.
+
+## Main.kt nach Refactor
+
+Main.kt enthält jetzt nur noch:
+
+- Lesen von SERVER_HOST
+- Lesen von SERVER_PORT
+- Start des Netty-Servers
+- Installation von ContentNegotiation
+- Registrierung der Status-Routen über statusRoutes()
+
+## API-Verhalten
+
+Die Endpunkte bleiben unverändert erreichbar.
+
+Lokal:
+
+curl -fsS http://127.0.0.1:8080/
+curl -fsS http://127.0.0.1:8080/health
+curl -fsS http://127.0.0.1:8080/api/v1/status
+
+Öffentlich:
+
+curl -fsS https://tactical.ruvnox.de/api/v1/status
+
+## Erwartete Statusantwort
+
+/api/v1/status liefert weiterhin:
+
+- service
+- status
+- version
+- database.status
+- database.host
+- database.port
+- database.name
+- database.latencyMs
+
+## Deployment
+
+Das Deployment wurde über das bestehende Script ausgeführt:
+
+/opt/ruvnox/tactical/scripts/deploy-server.sh
+
+Erwartetes Ergebnis:
+
+Deployment erfolgreich.
+
+## Git-Commit
+
+tactical-server:
+
+Extract status API routes
+
+## Abschlussstand
+
+- Status-DTOs ausgelagert
+- Status-Routen ausgelagert
+- Main.kt vereinfacht
+- Build erfolgreich
+- Deployment erfolgreich
+- API lokal geprüft
+- API öffentlich geprüft
+- Server-Code committed und gepusht
+
+## Nächster Abschnitt
+
+Als nächstes kann die echte Repository-Schicht vorbereitet werden:
+
+- UserRepository
+- OperationRoomRepository
+- AuditEventRepository
+- DB-Zugriffsfunktionen für die ersten API-Routen