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

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: 
bun dev
Für Produktionsumgebungen ist ein Build vor Deployment erforderlich: 
bun run build
Bei Schema-Aenderungen sollten die Drizzle-Migrationen im Deployment-Schritt vor dem Rollout der neuen App-Version laufen: 
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: 
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:
VariableFuer Self-HostingZweck
POSTGRES_DATABASE_URLerforderlichVerbindung zur PostgreSQL-Datenbank
NEXT_PUBLIC_BASE_URLerforderlichExterne Basis-URL der Instanz
ADMIN_EMAILerforderlichAdministrativer Hauptaccount
BETTER_AUTH_SECRETerforderlichSignatur/Session-Secret fuer Auth
AUTH_POSTMARK_KEYerforderlichE-Mail-Versand (Auth-Mails, z.B. Passwort-Reset)
OPENROUTER_API_KEYerforderlichModellzugriff ueber OpenRouter
VOYAGE_API_KEYerforderlichEmbeddings / Vektorsuche
STRIPE_SECRET_KEYoptionalNur fuer integrierte Abrechnung notwendig
STRIPE_WEBHOOK_SECREToptionalNur fuer Stripe-Webhooks notwendig
STRIPE_PLUS_PRICE_IDoptionalNur fuer Stripe-Preislogik notwendig
STRIPE_PLUS_PRICE_ID_ANNUALoptionalNur 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

PfadStandardverhaltenBetreiberkontrolle
Browser -> MDScribeTLS-verschlüsselte EingabenZugriffsschutz, Session-Policies, Logging-Policy
MDScribe -> PostgreSQLPersistenz von App-DatenDB-Standort, Verschlüsselung, Backup/Restore
MDScribe -> OpenRouter -> ModellanbieterVerarbeitung von Prompt/AntwortProvider- und Modellwahl, organisatorische Nutzungsrichtlinien
MDScribe -> PostmarkVersand transaktionaler E-MailsAnbieterwahl/Policy, Mail-Inhalte
MDScribe -> StripeAbrechnung und WebhooksBilling-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.