Skip to main content

​
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

Danach alle erforderlichen Umgebungsvariablen in .env setzen und den Start lokal validieren:
Für Produktionsumgebungen ist ein Build vor Deployment erforderlich:
Bei Schema-Aenderungen sollten die Drizzle-Migrationen im Deployment-Schritt vor dem Rollout der neuen App-Version laufen:
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:
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: Wenn Sie keine integrierte Billing-Logik nutzen, koennen Stripe-Variablen in einem Self-Hosted-Setup weggelassen werden.

​
3. Datenfluss und Kontrollgrenzen

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.