Self-Hosting hat einen schlechten Ruf — zu Unrecht. Für ein Digital-Signage-CMS braucht es heute weder einen Server-Schrank noch einen Linux-Profi. Diese Anleitung zeigt, wie Sie Displayna in unter einer Stunde live haben und worauf es wirklich ankommt.

Warum überhaupt selbst hosten?

Drei Gründe rechtfertigen den geringen Mehraufwand fast immer:

  • Daten bleiben bei Ihnen — kein AVV mit Drittanbietern, keine Drittland-Diskussion.
  • Keine laufenden Pro-Screen-Gebühren — die Lizenz zahlen Sie einmal, danach ist es Ihre.
  • Sie sind unabhängig vom Hersteller — geht das Unternehmen pleite, läuft Ihre Installation weiter.

Welche Hardware reicht

Das CMS ist genügsam. Bis zu 30 Bildschirme laufen problemlos auf:

  • Ein NAS (Synology, QNAP, Asustor) — Docker-Anwendung oder LXC-Container.
  • Ein Mini-PC (Intel NUC, Ryzen Mini-PC mit 8 GB RAM) — Linux drauf, läuft.
  • Eine kleine VM bei einem EU-Hoster (Hetzner, IONOS, Strato) — 2 vCPU, 4 GB RAM reichen.
  • Ein vorhandener Linux-Server — als zusätzlicher Service in Ihrem Rechenzentrum.

Auch ein Raspberry Pi 4/5 mit 4 GB RAM funktioniert für kleine Setups (1–5 Bildschirme). Wir empfehlen ihn eher als Player, weniger als Server.

Installation: Docker, LXC oder Bare-Metal

Drei Wege, je nach Vorliebe:

  1. Docker (empfohlen): ein docker compose up -d mit der mitgelieferten docker-compose.yml, drei Container (CMS, License-Server, Volume für Uploads). Fertig.
  2. LXC-Container (Proxmox-Nutzer): wir liefern eine fertige Container-Vorlage. Importieren, starten, IP-Adresse merken.
  3. Bare-Metal (Ubuntu/Debian): Node.js installieren, Repo klonen, npm start. Funktioniert, ist aber für Updates etwas umständlicher als Docker.

Erst-Login mit Benutzer admin und Passwort admin — der erste Schritt im CMS ist der erzwungene Passwort-Wechsel. Bitte nicht überspringen.

HTTPS und Domain

Für den Player ist HTTPS Pflicht — Browser blockieren WebSocket-Verbindungen sonst auf vielen Geräten. Zwei Wege:

  • Reverse Proxy mit Caddy oder Nginx vor das CMS legen, Let's-Encrypt-Zertifikat automatisch ziehen. Sehr robust, weniger als 10 Minuten Setup.
  • Eigene CA bei reinem Intranet-Betrieb: selbst-signiertes Zertifikat, intern verteilt. Funktioniert, aber Aufwand pro Player höher.

Erste Player anbinden

Im CMS-Dashboard auf Geräte → Neues Gerät pairen. Auf dem Player den Pairing-Code eingeben, der im CMS angezeigt wird. Sekunden später taucht der Player in der Geräteliste auf, lädt sein Projekt und beginnt zu spielen.

Das Schöne: Sie können das Pairing-Verfahren auch fern-administriert nutzen — der Mitarbeiter vor Ort liest den Code ab, Sie tippen ihn in der Zentrale ein. Kein Domänen-Konto, kein Setup-Aufwand.

Backup, Updates, Monitoring

Drei einfache Empfehlungen, die viel Ärger sparen:

  • Backup: einmal pro Tag das CMS-Datenverzeichnis (SQLite + Uploads) wegsichern. Eine tar-Datei reicht, die Sie auf einen anderen Server kippen.
  • Updates: Displayna meldet neue Versionen im Dashboard. Aktualisieren ist ein Docker-Image-Pull oder ein git pull plus Restart. Wir empfehlen Updates im Wochenrhythmus.
  • Monitoring: jeder Player schickt alle 60 Sekunden einen Heartbeat. Das Dashboard zeigt offline-Geräte sofort. Optional erweiterbar mit Mail-Benachrichtigungen, sobald ein Gerät länger als 10 Minuten offline ist.

Häufige Stolpersteine

  • Falscher Port: das CMS hört per Default auf 4400, der Player verbindet sich dahin — vergessen Sie nicht, den Port in der Firewall freizugeben.
  • WebSocket-Block durch Reverse-Proxy: Nginx braucht Upgrade- und Connection-Header weitergereicht, sonst kommen Live-Updates nicht durch.
  • Self-Signed-Zertifikat im Browser-Player: muss als trusted hinterlegt sein, sonst weigert sich der Browser auf vielen Plattformen, WebSocket aufzubauen.
  • Player schläft ein: bei TVs den Bildschirm-Schoner aus, bei Linux-Mini-PCs den DPMS deaktivieren (xset -dpms).