EmDash CMS – Referenz: Self-Hosted-Deployment mit Node

Veröffentlicht am 2026-04-08 von Emdash Cms Everything

Wann Self-Hosting die richtige Wahl ist

Wählen Sie Self-Hosting, wenn Ihre Grenzen operativ, rechtlich oder architektonisch sind:

• strenge Datenresidenz
• Sie betreiben bereits gemeinsame Plattformdienste intern
• volle Kontrolle über Laufzeit, Prozessmodell und Netzpfade
• Vermeidung starker Managed-Cloud-Kopplung in frühen Phasen

Self-Hosting ist nicht automatisch günstiger. Es ist meist besser kontrollierbar.

Empfohlenes Stufenmodell

Nicht mit maximaler Komplexität starten. Ausrollen in Stufen:

1. Node.js + SQLite + lokaler Dateispeicher
2. PostgreSQL für Multi-Instance-Sicherheit und höhere Durabilität
3. S3-kompatibler Objektspeicher für Medien-Portabilität
4. Prozessüberwachung und Observability schärfen

So bleibt Migrationsschock gering bei klarem Produktionspfad.

Basis-Architektur (Stufe 1)

Für Single-Node-Produktion oder frühen Launch:

• App-Laufzeit: Node-Adapter (standalone)
• Datenbank: SQLite-Datei auf persistentem Datenträger
• Medien: lokales Upload-Verzeichnis
• Reverse-Proxy: Nginx oder Caddy

Reicht für niedrige bis moderate redaktionelle Last mit einer Laufzeitinstanz.

# Produktions-Build und Start
npm install
npm run build
npm run start

Upgrade-Kriterien Stufe 2 (Wechsel zu PostgreSQL)

Datenbank upgraden, wenn eines eintritt:

• häufige gleichzeitige Schreibkonflikte
• Backup-/Recovery-Ziele übersteigen Datei-Kopie-Strategie
• sichereres Multi-Instance-Deployment nötig

PostgreSQL vor horizontalem App-Scaling nutzen. App-Knoten auf SQLite zu skalieren erzeugt schnell operatives Risiko.

Speicherstrategie: lokale Dateien vs. Objektspeicher

Lokale Dateien (Start hier)

Gut für Single-Instance mit vorhersehbarem Speicherwachstum.

S3-kompatibler Objektspeicher (bei Skalierung)

Nutzen wenn:

• mehrere App-Instanzen gemeinsamen Medienzugriff brauchen
• Backup und Disaster Recovery standardisiert sein müssen
• CDN-/Edge-Cache auf stabilen Objekt-URLs basiert

MinIO kann auf privater Infrastruktur für S3-kompatibles Verhalten dienen.

Laufzeitprozess und Proxy-Baseline

Prozessverwaltung

Eine von:

• systemd für natives Linux-Service-Management
• pm2 für Teams, die Metriken und schnelle Restarts wollen

Reverse-Proxy

TLS am Proxy beenden und an die Node-App weiterleiten:

• Host und X-Forwarded-* Header erhalten
• Health-Check-Pfad konfigurieren
• Body-Größenlimits an Upload-Richtlinie anpassen

Backup und Wiederherstellung

Backup-Richtlinie ist launch-blockierend, kein nachgelagerter Task.

Minimum:

• Datenbank-Snapshots nach Zeitplan
• Mediensicherung oder Replikation
• mindestens ein Restore-Test vor öffentlichem Launch

Ein Backup, das nie getestet wurde, ist keine Kontrolle, sondern ein Gerücht.

Checkliste operative Reife

Vor Produktions-Cutover:

• Kaltstart ohne manuelle Eingriffe
• Anwendungslogs zentral und durchsuchbar
• 5xx-Alerting aktiv
• Plattennutzung und Speicherwachstum überwacht
• Secret-Rotation dokumentiert

Migrationshinweise von Cloudflare-orientiertem Setup

Wenn das Projekt mit Cloudflare-Annahmen begann:

• cloud-only Bindings aus der Laufzeitkonfiguration entfernen
• D1/R2-Adapter durch Node-kompatible DB- und Storage-Adapter ersetzen
• Auth und Callback-URLs hinter dem Reverse-Proxy neu validieren

Migrationsrisiko liegt vor allem in Umgebungsannahmen, nicht in Page-Code.

Entscheidungsrahmen für Teams

Regel:

• Geschwindigkeit und minimaler Ops: Managed-Cloud-Pfad bevorzugen
• Kontrolle und Integration in bestehende Infra: Self-Hosted-Pfad bevorzugen

Pro Umgebung einen Standard-Pfad wählen. Hybrid ist möglich, erhöht aber kognitive Last und Support-Aufwand.