> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mdscribe.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-Hosting

> Betrieb von MDScribe in eigener Infrastruktur mit klaren Daten- und Compliance-Grenzen

## Self-Hosting von MDScribe

Self-Hosting bedeutet, dass Sie MDScribe in Ihrer eigenen Infrastruktur betreiben und damit die volle Kontrolle, aber auch die volle Verantwortung übernehmen.

## Kurzposition (OSS)

* Die cloud-gehostete Nutzung sollte derzeit nicht als sicher für sensible Patientendaten/PHI betrachtet werden, bis weitere Datenschutzmaßnahmen abgeschlossen sind.
* Self-Hosting ist der empfohlene Weg, wenn Sie vollständige Kontrolle über Verarbeitung, Speicherung und Aufbewahrung benötigen.
* Die Verantwortung für den rechtskonformen Betrieb liegt beim jeweiligen Betreiber.
* Wir arbeiten daran, das eigentständige Betreiben von MDScribe deutlich zu vereinfachen.

## 1. Basis-Setup

```bash theme={null}
git clone https://github.com/ekpah/mdscribe.git
cd mdscribe
bun install
cp .env.example .env
```

Danach alle erforderlichen Umgebungsvariablen in `.env` setzen und den Start lokal validieren:

```bash theme={null}
bun dev
```

Für Produktionsumgebungen ist ein Build vor Deployment erforderlich:

```bash theme={null}
bun run build
```

Bei Schema-Aenderungen sollten die Drizzle-Migrationen im Deployment-Schritt vor dem Rollout der neuen App-Version laufen:

```bash theme={null}
bun run db:migrate
```

Das Docker-Image startet nur die App und fuehrt keine Migrationen beim Container-Start aus.

Wenn Sie MDScribe per Dockerfile ueber Coolify deployen, setzen Sie dafuer einen `Post-deployment`-Hook:

```sh theme={null}
cd /app/packages/database && bun run migrate
```

Dafuer muss das Runtime-Image neben `packages/database` auch die installierten `node_modules` enthalten, damit `drizzle-kit` aus `drizzle.config.ts` korrekt aufgeloest werden kann.

## 2. Umgebungsvariablen (Self-Hosted)

Fuer Self-Hosting ohne integrierte SaaS-Abrechnung sind nur die Kernvariablen relevant:

| Variable                      | Fuer Self-Hosting | Zweck                                            |
| ----------------------------- | ----------------- | ------------------------------------------------ |
| `POSTGRES_DATABASE_URL`       | erforderlich      | Verbindung zur PostgreSQL-Datenbank              |
| `NEXT_PUBLIC_BASE_URL`        | erforderlich      | Externe Basis-URL der Instanz                    |
| `ADMIN_EMAIL`                 | erforderlich      | Administrativer Hauptaccount                     |
| `BETTER_AUTH_SECRET`          | erforderlich      | Signatur/Session-Secret fuer Auth                |
| `AUTH_POSTMARK_KEY`           | erforderlich      | E-Mail-Versand (Auth-Mails, z.B. Passwort-Reset) |
| `OPENROUTER_API_KEY`          | erforderlich      | Modellzugriff ueber OpenRouter                   |
| `VOYAGE_API_KEY`              | erforderlich      | Embeddings / Vektorsuche                         |
| `STRIPE_SECRET_KEY`           | optional          | Nur fuer integrierte Abrechnung notwendig        |
| `STRIPE_WEBHOOK_SECRET`       | optional          | Nur fuer Stripe-Webhooks notwendig               |
| `STRIPE_PLUS_PRICE_ID`        | optional          | Nur fuer Stripe-Preislogik notwendig             |
| `STRIPE_PLUS_PRICE_ID_ANNUAL` | optional          | Nur fuer Stripe-Preislogik notwendig             |

Wenn Sie keine integrierte Billing-Logik nutzen, koennen Stripe-Variablen in einem Self-Hosted-Setup weggelassen werden.

## 3. Datenfluss und Kontrollgrenzen

| Pfad                                     | Standardverhalten               | Betreiberkontrolle                                             |
| ---------------------------------------- | ------------------------------- | -------------------------------------------------------------- |
| Browser -> MDScribe                      | TLS-verschlüsselte Eingaben     | Zugriffsschutz, Session-Policies, Logging-Policy               |
| MDScribe -> PostgreSQL                   | Persistenz von App-Daten        | DB-Standort, Verschlüsselung, Backup/Restore                   |
| MDScribe -> OpenRouter -> Modellanbieter | Verarbeitung von Prompt/Antwort | Provider- und Modellwahl, organisatorische Nutzungsrichtlinien |
| MDScribe -> Postmark                     | Versand transaktionaler E-Mails | Anbieterwahl/Policy, Mail-Inhalte                              |
| MDScribe -> Stripe                       | Abrechnung und Webhooks         | Billing-Setup und Zugriffsschutz                               |

Wenn Sie striktere Grenzen benötigen (z.B. keine externen KI-Endpunkte), ist zusätzlicher Implementierungsaufwand notwendig. Es soll jedoch in Kürze auch möglich sein, MDScribe mit lokalen LLMszu nutzen.

## 6. Secrets, Rotation und Zugriff

* Verwenden Sie einen Secret Manager oder verschlüsselte Deployment-Secrets, nicht Git.
* Halten Sie `.env.example` ausschließlich mit Platzhaltern.
* Rotieren Sie Schlüssel regelmäßig und immer nach vermutetem Leak.
* Trennen Sie Rollen für Deployments, DB-Administration und Anwendungszugriff.
* Nutzen Sie Least-Privilege für DB- und Service-Credentials.

## 7. Backup- und Wiederherstellungsstrategie

* Planen Sie tägliche PostgreSQL-Backups (`pg_dump` oder Snapshot-basiert).
* Definieren Sie klare Aufbewahrungsfristen und Offsite-Backups.
* Testen Sie Recovery regelmäßig in einer separaten Umgebung.
* Dokumentieren Sie RTO/RPO für Ihren Betrieb.

## 8. Telemetrie- und Compliance-Hinweise

* Prüfen Sie vor Produktivbetrieb, welche externen Dienste in Ihrem Setup aktiv sind.
* Prüfen Sie vertragliche und regulatorische Anforderungen (z.B. Datenschutz, Dokumentationspflichten) für Ihre Organisation.
* ZDR- oder Provider-Einstellungen können Risiken reduzieren, ersetzen aber keine eigene Compliance-Prüfung.

## 9. Go-Live Checkliste (Self-Hosted)

* [ ] Alle erforderlichen Environment-Variablen gesetzt und valide
* [ ] TLS und Zugriffsschutz (Auth, Rollen, Admin-Zugänge) geprüft
* [ ] `bun run db:migrate` oder der Coolify-Post-deployment-Hook erfolgreich gegen die Ziel-Datenbank ausgeführt
* [ ] Backup/Restore erfolgreich getestet
* [ ] Secret-Rotation-Prozess dokumentiert
* [ ] Logging-/Monitoring-Policy dokumentiert
* [ ] Datenfluss und Drittanbieter-Nutzung intern freigegeben

## 10. Verantwortlichkeit

Diese Seite beschreibt technische Leitplanken. Sie ersetzt keine rechtliche Beratung. Der Betreiber ist verantwortlich für die Einhaltung aller anwendbaren Datenschutz- und Compliance-Vorgaben im jeweiligen Einsatzkontext.