Wer Besucher-Statistiken für seine Website möchte, steht vor einer unbequemen Wahl: entweder Google Analytics mit all seinen Datenschutz-Fragezeichen, oder ein Schwergewicht wie Matomo, das auf dem NAS gut 500–800 MB RAM beansprucht und eine umfangreiche Konfiguration erfordert. Umami schlägt einen dritten Weg: eine schlanke Node.js-Anwendung mit PostgreSQL-Backend, die komplett ohne Cookies auskommt, keine personenbezogenen Daten speichert und sich auf dem Synology NAS mit einem einzigen Compose-Projekt in rund 20 Minuten aufsetzen lässt. Da keinerlei Cookies gesetzt werden, entfällt in aller Regel die Pflicht zum Cookie-Consent-Banner – ein echtes Argument für DACH-Betreiber, die rechtliche Klarheit schätzen.

Voraussetzungen

Synology NAS mit x86_64- oder ARM64-Prozessor und DSM 7.2 oder neuer
Container Manager aus dem Synology Package Center installiert
Mindestens 1 GB freier RAM (Umami-Stack ca. 200–300 MB)
Mindestens 2 GB freier Speicherplatz auf /volume1 für Datenbankdaten
SSH-Zugang zum NAS – empfohlen für die APP_SECRET-Generierung (Einrichtung: SSH auf dem Synology NAS aktivieren und verbinden)
Internetverbindung für den ersten Image-Pull von ghcr.io
Optional: eigene (Sub-)Domain oder Synology DDNS für HTTPS-Zugriff von außen
Eine oder mehrere Websites, auf denen das Tracking-Snippet eingebunden werden soll

Eckdaten: Umami auf einen Blick

Eigenschaft	Wert
Image (App)	`ghcr.io/umami-software/umami:postgresql-latest`
Image (DB)	`postgres:15-alpine`
Externer Port	3999 (→ Container-Port 3000; vermeidet Konflikte auf Synology)
PostgreSQL-Port	5432 – nur intern im Docker-Netzwerk, nicht nach außen exponiert
Persistentes Volume	`/volume1/docker/umami/db` → `/var/lib/postgresql/data`
Pflicht-Env (App)	`DATABASE_URL`, `APP_SECRET`
Pflicht-Env (DB)	`POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`
RAM-Bedarf	ca. 200–300 MB (Stack gesamt)
Standard-Login	admin / umami – sofort ändern!
Lizenz	MIT

Schritt 1: Ordner anlegen und APP_SECRET generieren

Bevor der Stack starten kann, muss der Datenbankordner auf dem NAS existieren. Verbinde dich per SSH mit dem NAS und lege den Pfad an:

mkdir -p /volume1/docker/umami/db

Generiere im gleichen SSH-Terminal dein persönliches APP_SECRET. Dieser 64-Zeichen-String sichert alle JWT-Authentifizierungstoken der Umami-Installation – er darf niemals der Standardwert bleiben:

openssl rand -hex 32

Die Ausgabe sieht in etwa so aus:

a3f8e2c1d94b7065f18e3a42bc90d5e71f6c2480e9b3d7a561042fc8e95a1b2

Kopiere diesen Wert – du trägst ihn gleich in die Compose-Datei ein. Alternativ lässt sich der Ordner über die File Station erstellen (navigiere zu docker, dann Unterordner umami und darin db). Alles zu Berechtigungen und PUID/PGID erklärt Docker-Ordner und Berechtigungen auf dem Synology NAS.

Verifizieren: Prüfe im SSH-Terminal, dass der Ordner existiert:

ls -la /volume1/docker/umami/

Erwartete Ausgabe: ein Verzeichnis db wird aufgelistet. Erscheint „Permission denied", korrigiere mit chmod 755 /volume1/docker/umami/db.

Schritt 2: Compose-Datei erstellen und Projekt starten

Öffne den Container Manager in DSM, wechsle zu Projekt und klicke auf Erstellen. Gib als Projektname umami und als Pfad /volume1/docker/umami an. Wie du ein Compose-Projekt im Container Manager anlegst, beschreibt Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren Schritt für Schritt. Füge folgende compose.yaml ein – ersetze die Platzhalter für Passwort und APP_SECRET durch deine eigenen Werte:

---
services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    container_name: umami
    ports:
      - "3999:3000"
    environment:
      DATABASE_URL: postgresql://umami:SicheresPasswort123@db:5432/umami
      APP_SECRET: ersetze-dies-mit-openssl-rand-hex-32-ausgabe
      DISABLE_TELEMETRY: "1"
    depends_on:
      db:
        condition: service_healthy
    init: true
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
      interval: 5s
      timeout: 5s
      retries: 5

  db:
    image: postgres:15-alpine
    container_name: umami-db
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: SicheresPasswort123
    volumes:
      - /volume1/docker/umami/db:/var/lib/postgresql/data
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5

Drei Punkte verdienen besondere Aufmerksamkeit:

Port 3999:3000: Der externe Port 3999 vermeidet Konflikte mit anderen Diensten, die auf Synology häufig Port 3000 belegen. Du kannst jeden freien Port wählen.
Doppeltes $$ im Healthcheck: In Compose-YAML muss das Dollarzeichen verdoppelt werden ($${POSTGRES_USER}), damit Docker Compose es nicht als eigene Variable interpretiert.
depends_on mit condition: service_healthy: Umami wartet, bis PostgreSQL den Healthcheck besteht – ohne diese Bedingung entstehen „connection refused"-Fehler beim Start.

Verifizieren: Beide Container sollten nach etwa 30–60 Sekunden den Status „Wird ausgeführt" (grünes Symbol) anzeigen. Im Protokoll-Tab des umami-Containers darf keine Fehlerausgabe erscheinen. Rufe außerdem den Heartbeat-Endpunkt auf:

curl http://NAS-IP:3999/api/heartbeat

Erwartete Antwort: OK – dann läuft Umami korrekt.

Schritt 3: Firewall-Port freigeben

Damit Umami aus dem Netzwerk erreichbar ist, muss der externe Port in der DSM-Firewall freigegeben werden. Gehe zu Systemsteuerung → Sicherheit → Firewall und füge eine Regel für Port 3999 (TCP) hinzu. Die genauen Schritte beschreibt DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben.

Verifizieren: Öffne einen Browser auf einem anderen Gerät im Netzwerk und rufe http://NAS-IP:3999 auf. Die Umami-Anmeldeseite muss erscheinen. Bleibt das Fenster leer oder kommt ein Timeout, ist die Firewall-Regel noch nicht aktiv oder der falsche Port eingetragen.

Öffne http://NAS-IP:3999 im Browser. Melde dich mit den Standard-Zugangsdaten an:

Benutzername: admin
Passwort: umami

Das Standard-Passwort umami ist öffentlich bekannt – ändere es sofort nach dem ersten Login. Klicke oben rechts auf dein Profilbild und wähle Profil → Passwort ändern. Wähle ein starkes, einzigartiges Passwort.

Verifizieren: Melde dich nach der Passwortänderung ab und erneut mit dem neuen Passwort an. Klappt der Login, ist das Standard-Passwort erfolgreich ersetzt. Schlägt er fehl, setze das Passwort erneut.

Schritt 5: Website anlegen und Tracking-Snippet einbinden

Im Umami-Dashboard klickst du oben rechts auf das Zahnrad-Symbol (Einstellungen) und dann auf Websites → Website hinzufügen. Trage den Namen und die Domain deiner Website ein. Nach dem Speichern erscheint die Website in der Liste – klicke auf Bearbeiten und wechsle zum Reiter Tracking-Code.

Das generierte Snippet sieht so aus:

<script defer src="https://DEINE-DOMAIN/script.js"
  data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"></script>

Binde dieses Snippet in den <head>-Bereich aller zu trackenden Seiten ein. Bei WordPress reicht dafür ein Theme-Hook oder ein einfaches Plugin wie „Insert Headers and Footers". Beachte: Wenn du Ad-Blocker auf deinen Test-Geräten aktiv hast, blockieren sie möglicherweise script.js – dazu mehr im Troubleshooting-Abschnitt.

Verifizieren: Öffne nach dem Einbinden des Snippets eine der überwachten Seiten im Browser. Wechsle dann ins Umami-Dashboard zur jeweiligen Website und klicke auf Live. Eigene Aufrufe erscheinen nach wenigen Sekunden in Echtzeit. Alternativ öffne die Browser-Dev-Tools (F12), wechsle zum Network-Tab, lade die Seite neu und suche nach einem Request an /api/send – HTTP 200 bestätigt aktives Tracking.

Schritt 6: Reverse Proxy für HTTPS einrichten (optional, empfohlen)

Für den produktiven Einsatz – insbesondere wenn das Tracking-Snippet von außen laden soll – empfiehlt sich HTTPS über den Synology Reverse Proxy. Öffne DSM und gehe zu Systemsteuerung → Anmeldungsportal → Erweitert → Reverse Proxy → Erstellen. Trage ein:

Quelle: HTTPS, Port 443, deine (Sub-)Domain oder DDNS-Adresse
Ziel: HTTP, localhost, Port 3999

Aktiviere unter Benutzerdefinierte Header die WebSocket-Header (Upgrade und Connection). Ein Let's-Encrypt-Zertifikat lässt sich direkt in DSM unter Systemsteuerung → Sicherheit → Zertifikat beantragen. Eine detaillierte Anleitung zum Reverse Proxy mit SSL bietet Nginx Proxy Manager auf der Synology mit Container Manager einrichten.

Verifizieren: Öffne https://DEINE-SUBDOMAIN im Browser. Das Schloss-Symbol in der Adressleiste zeigt ein gültiges Zertifikat. Prüfe außerdem, ob das Tracking-Snippet (jetzt mit HTTPS-URL) weiterhin Requests an /api/send sendet.

Troubleshooting / Typische Fehler

„connection refused" oder Umami startet nicht: Fehlendes oder falsch konfiguriertes depends_on. Prüfe, ob condition: service_healthy gesetzt ist und ob der Healthcheck des db-Containers erfolgreich durchläuft. Logs im Protokoll-Tab des Container Managers prüfen.
„permission denied" beim PostgreSQL-Start: Der Ordner /volume1/docker/umami/db existiert nicht oder hat falsche Berechtigungen. Lösung: mkdir -p /volume1/docker/umami/db && chmod 755 /volume1/docker/umami/db per SSH ausführen.
„variable not set"-Warnung oder fehlerhafter Healthcheck: Das Dollarzeichen im Healthcheck-Befehl ist nur einfach geschrieben. In der YAML-Datei muss es $${POSTGRES_USER} heißen, nicht ${POSTGRES_USER}.
„getaddrinfo ENOTFOUND db": Der Service-Name in der DATABASE_URL stimmt nicht mit dem Compose-Service-Namen des Datenbank-Containers überein. Wenn der DB-Service db heißt, muss die URL @db:5432 enthalten – exakt wie im Compose-File definiert.
Kein Tracking, obwohl Snippet eingebunden: Ad-Blocker (uBlock Origin, Brave Shield) filtern standardmäßig script.js. Lösung: In der Compose-Datei TRACKER_SCRIPT_NAME: analytics.js setzen und das Snippet entsprechend aktualisieren.
Sonderzeichen im Passwort, DATABASE_URL schlägt fehl: Zeichen wie @, / oder ? im POSTGRES_PASSWORD müssen in der DATABASE_URL URL-kodiert werden (@ → %40). Einfachste Lösung: Passwörter nur aus Buchstaben, Ziffern und Bindestrichen zusammensetzen.
Umami von außen nicht erreichbar trotz laufendem Container: Port 3999 ist in der DSM-Firewall nicht freigegeben. Unter Systemsteuerung → Sicherheit → Firewall eine Regel für TCP/3999 hinzufügen.
Altes Image läuft nach Update weiterhin: Container Manager cached Images. Container stoppen, unter Registrierung das Image explizit neu laden und dann den Container neu starten.

Häufige Fragen

In aller Regel nein. Die offizielle Umami-FAQ bestätigt ausdrücklich: „No, Umami does not use any cookies in the tracking code." Da keine Cookies gesetzt und keine personenbezogenen Daten (wie Roh-IP-Adressen) gespeichert werden, entfällt die Einwilligungspflicht nach TTDSG/DSGVO. Für rechtliche Sicherheit im DACH-Raum empfiehlt sich: DISABLE_TELEMETRY: "1" setzen, in der Datenschutzerklärung kurz erwähnen („wir nutzen selbst gehostetes Umami ohne Cookies und ohne Personenbezug") und eine kompakte Datenschutz-Folgenabschätzung dokumentieren.

Wo finde ich meinen Tracking-Code?

Im Umami-Dashboard unter Einstellungen (Zahnrad-Icon) → Websites → gewünschte Website → Bearbeiten → Reiter „Tracking-Code". Das Snippet enthält deine individuelle Website-ID im Format data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" und die URL deines Tracking-Scripts. Dieses Snippet gehört in den <head>-Bereich aller zu trackenden Seiten.

Wie verifiziere ich, dass das Tracking wirklich funktioniert?

Drei Methoden stehen zur Verfügung: (1) Umami-Dashboard → gewählte Website → Live-Ansicht: eigene Seitenaufrufe erscheinen nach wenigen Sekunden. (2) Browser-Dev-Tools (F12) → Network-Tab → Seite neu laden → Request an /api/send suchen – HTTP 200 bedeutet aktives Tracking. (3) Heartbeat direkt prüfen:

curl http://NAS-IP:3999/api/heartbeat

Antwort OK bestätigt, dass Umami erreichbar ist und läuft.

Was ist der Unterschied zwischen Umami und Matomo für den NAS-Betrieb?

Umami benötigt ca. 200–300 MB RAM, besteht aus zwei Containern und bietet Traffic-Überblick ohne Consent-Aufwand – Einrichtung in etwa 20 Minuten. Matomo kommt auf 500–800 MB RAM, drei Container und bietet Funnels, Heatmaps, E-Commerce-Tracking und eine vollständige Consent-Verwaltung – dafür deutlich mehr Konfigurationsaufwand. Empfehlung: Umami für einfache Traffic-Analyse ohne Overhead; Matomo wenn detaillierte Marketinganalysen notwendig sind. Den vollständigen Matomo-Aufbau beschreibt Matomo auf dem Synology NAS installieren: DSGVO-konforme Webanalyse.

Kann ich mehrere Websites mit einer Umami-Instanz tracken?

Ja – Umami unterstützt beliebig viele Websites pro Instanz. Für jede Website wird im Dashboard eine eigene ID generiert und ein eigenes Snippet bereitgestellt. Alle Daten landen in derselben PostgreSQL-Datenbank, sind aber im Dashboard sauber getrennt und einzeln auswertbar.

Was passiert bei einem NAS-Neustart?

Mit restart: always starten beide Container automatisch neu. Der Healthcheck-Mechanismus stellt sicher, dass Umami erst hochfährt, wenn die Datenbank wirklich bereit ist. Alle Analytics-Daten bleiben erhalten, weil die PostgreSQL-Dateien im persistenten Volume /volume1/docker/umami/db liegen.

Wie sichere ich die Umami-Daten?

Der gesamte Analytics-Datenbestand liegt unter /volume1/docker/umami/db und kann direkt mit Synology Hyper Backup gesichert werden – kein zusätzliches Datenbankdump-Skript nötig. Für eine robuste Gesamtstrategie lies 3-2-1-Backup-Strategie umsetzen.

Fazit

Umami ist die konsequent minimalistische Antwort auf die Frage „Wie messe ich Besucher, ohne Datenschutz-Probleme zu riskieren?" Zwei Container, ein openssl rand -hex 32 und ein Tracking-Snippet – fertig ist eine cookielose, selbst gehostete Webanalyse, die auf dem NAS kaum Ressourcen frisst. Die fehlenden Features gegenüber Matomo (Funnels, Heatmaps, Consent-Management) sind für persönliche Websites und kleine Agenturen schlicht irrelevant. Wer nur wissen will, woher seine Besucher kommen, welche Seiten sie aufrufen und welche Geräte sie nutzen, bekommt mit Umami genau das – ohne Overhead und ohne die Notwendigkeit, sich durch eine DSGVO-Checkliste zu arbeiten, bevor das erste Snippet live gehen kann.

Weiterführende Anleitungen und Quellen

Matomo auf dem Synology NAS installieren: DSGVO-konforme Webanalyse – der große Bruder mit Funnels, Heatmaps und Consent-Verwaltung
Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren
DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben
Nginx Proxy Manager auf der Synology: Reverse Proxy und SSL einrichten
3-2-1-Backup-Strategie umsetzen

Quellen: Offizielle Umami-Dokumentation (docs.umami.is/docs/install, docs.umami.is/docs/faq, docs.umami.is/docs/environment-variables), Umami GitHub Repository mit offiziellem docker-compose.yml (github.com/umami-software/umami).