Wer im Team auf Slack oder Microsoft Teams verzichten und trotzdem nicht auf strukturierte Kommunikation mit Channels, Threads und Dateiablage verzichten möchte, ist mit Mattermost gut bedient. Die Open-Source-Plattform läuft als kompakter Zwei-Container-Stack aus PostgreSQL und der Mattermost-App – und lässt sich auf jedem modernen Synology-NAS mit DSM 7.2 und dem integrierten Container Manager innerhalb einer Stunde aufsetzen. Die gesamten Daten bleiben dabei auf dem eigenen NAS, ohne Nutzungsgebühr und ohne Cloud-Abhängigkeit.

Voraussetzungen

Synology NAS mit DSM 7.2 oder höher, x86_64-Architektur (Intel/AMD-CPU)
Mindestens 2 GB RAM im NAS (empfohlen: 4 GB), mindestens 5 GB freier Speicher
Container Manager in DSM installiert und aktiviert
SSH-Zugang zum NAS (für den chown-Befehl zwingend erforderlich)
Eigene Domain oder Synology DDNS (z. B. name.synology.me) für eine erreichbare HTTPS-URL
SSL-Zertifikat für HTTPS – entweder über das Synology Application Portal mit Let's Encrypt oder ein eigenes Zertifikat
SMTP-Zugangsdaten (optional, aber empfohlen für Nutzereinladungen und Passwort-Reset)

Schritt 1: Ordnerstruktur im Synology File Station anlegen

Öffne in DSM die File Station und navigiere nach /volume1/docker. Lege dort den Ordner mattermost an, und darin folgende sieben Unterordner:

config – Konfigurationsdatei config.json
data – Nutzer-Uploads und Anhänge
logs – Anwendungslogs
plugins – Server-Plugins
client – Client-seitige Plugins
indexes – Bleve-Volltext-Suchindex
db – PostgreSQL-Datenbankdaten

Der vollständige Basispfad lautet /volume1/docker/mattermost.

Verifizieren: Prüfe per SSH, ob alle sieben Unterordner vorhanden sind:

ls /volume1/docker/mattermost/

Erwartete Ausgabe:

client  config  data  db  indexes  logs  plugins

Schritt 2: Verzeichnis-Berechtigungen per SSH setzen (UID 2000)

Dies ist der häufigste Stolperstein bei der Mattermost-Installation: Der Mattermost-Container läuft intern mit UID/GID 2000:2000 – nicht als Root. Alle Mattermost-Datenverzeichnisse auf dem NAS-Host müssen diesem Nutzer gehören, sonst verweigert der Container den Start mit einem „permission denied“-Fehler. Das db-Verzeichnis gehört PostgreSQL und bleibt wie es ist.

Verbinde dich per SSH mit dem NAS (z. B. über PuTTY oder das Windows-Terminal) und führe folgenden Befehl aus:

sudo chown -R 2000:2000 \
  /volume1/docker/mattermost/config \
  /volume1/docker/mattermost/data \
  /volume1/docker/mattermost/logs \
  /volume1/docker/mattermost/plugins \
  /volume1/docker/mattermost/client \
  /volume1/docker/mattermost/indexes

Das db-Verzeichnis für PostgreSQL bleibt mit den Standard-Berechtigungen; PostgreSQL setzt die Rechte beim ersten Start selbst.

Verifizieren: Prüfe die Eigentümer-Zuweisung:

ls -la /volume1/docker/mattermost/

Alle sechs Mattermost-Verzeichnisse (alles außer db) sollten 2000 2000 als Eigentümer zeigen, z. B. drwxr-xr-x 2 2000 2000 ... config.

Schritt 3: Compose-Datei im Container Manager anlegen

Öffne in DSM den Container Manager, wechsle in den Reiter Projekt und klicke auf Erstellen. Gib als Projektname mattermost ein und wähle als Pfad /volume1/docker/mattermost. Füge folgende compose.yaml ein – ersetze SICHERES_DB_PASSWORT mit einem starken eigenen Passwort und https://chat.example.synology.me mit deiner tatsächlichen öffentlichen HTTPS-URL:

services:
  db:
    image: postgres:18-alpine
    container_name: mattermost-db
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    pids_limit: 100
    read_only: true
    tmpfs:
      - /tmp
      - /var/run/postgresql
    volumes:
      - /volume1/docker/mattermost/db:/var/lib/postgresql/data
    environment:
      TZ: Europe/Berlin
      POSTGRES_USER: mmuser
      POSTGRES_PASSWORD: SICHERES_DB_PASSWORT
      POSTGRES_DB: mattermost
    networks:
      - mattermost-net

  mattermost:
    image: mattermost/mattermost-team-edition:11.7.0
    container_name: mattermost-app
    restart: unless-stopped
    depends_on:
      - db
    security_opt:
      - no-new-privileges:true
    pids_limit: 200
    tmpfs:
      - /tmp
    ports:
      - "8065:8065"
    volumes:
      - /volume1/docker/mattermost/config:/mattermost/config
      - /volume1/docker/mattermost/data:/mattermost/data
      - /volume1/docker/mattermost/logs:/mattermost/logs
      - /volume1/docker/mattermost/plugins:/mattermost/plugins
      - /volume1/docker/mattermost/client:/mattermost/client/plugins
      - /volume1/docker/mattermost/indexes:/mattermost/bleve-indexes
    environment:
      TZ: Europe/Berlin
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: postgres://mmuser:SICHERES_DB_PASSWORT@db:5432/mattermost?sslmode=disable&connect_timeout=10
      MM_BLEVESETTINGS_INDEXDIR: /mattermost/bleve-indexes
      MM_SERVICESETTINGS_SITEURL: https://chat.example.synology.me
      # SMTP (optional – auskommentieren und befüllen für E-Mail-Benachrichtigungen)
      # MM_EMAILSETTINGS_SMTPSERVER: smtp.example.com
      # MM_EMAILSETTINGS_SMTPPORT: "587"
      # MM_EMAILSETTINGS_CONNECTIONSECURITY: STARTTLS
      # MM_EMAILSETTINGS_SMTPUSERNAME: user@example.com
      # MM_EMAILSETTINGS_SMTPPASSWORD: APP_PASSWORT
      # MM_EMAILSETTINGS_SENDEMAILNOTIFICATIONS: "true"
    networks:
      - mattermost-net

networks:
  mattermost-net:
    driver: bridge

Drei wichtige Punkte zur Compose-Datei:

Das Image mattermost/mattermost-team-edition:11.7.0 ist der aktuelle ESR (Extended Support Release, Support bis Mai 2027). Kein :latest in Produktion – die offizielle Doku empfiehlt explizite Versions-Tags.
Der Hostname im Datasource-String (@db:5432) entspricht dem Service-Namen im Docker-Netzwerk, nicht localhost.
Umgebungsvariablen werden im Synology Container Manager nicht aus einer separaten .env-Datei geladen – alle Werte direkt als Klartextwerte in der Compose-Datei angeben.

Verifizieren: Prüfe vor dem Start, dass SICHERES_DB_PASSWORT in beiden Stellen (unter db und im Datasource-String) identisch ist, und dass MM_SERVICESETTINGS_SITEURL mit https:// beginnt und deine echte Domain enthält. Der Container Manager zeigt YAML-Syntaxfehler direkt im Editor an.

Schritt 4: Stack starten und DB-Migration beobachten

Klicke im Container Manager auf Erstellen, um den Stack hochzufahren. Docker lädt die Images herunter (postgres:18-alpine ca. 80 MB, mattermost-team-edition:11.7.0 ca. 300 MB) und startet beide Container. Beim ersten Start führt Mattermost automatisch alle Datenbank-Migrationen aus – das kann zwei bis drei Minuten dauern.

Verfolge den Fortschritt per SSH:

docker logs mattermost-app -f

Verifizieren: Die erfolgreiche DB-Migration erkennst du an folgender Zeile in den Logs:

Finished running database migrations

Danach erscheint Server is listening on [::]:8065. Wenn stattdessen Verbindungsfehler zu PostgreSQL auftauchen, prüfe ob das Passwort in beiden Stellen der Compose-Datei übereinstimmt. Abbrechen mit Ctrl+C.

Schritt 5: Reverse Proxy im Synology Application Portal einrichten

Mattermost hört intern auf HTTP-Port 8065. Für den Produktivbetrieb muss der Synology Reverse Proxy HTTPS 443 auf diesen Port übersetzen. Gehe in DSM zu Systemsteuerung > Anwendungsportal > Reverseproxy und lege einen neuen Eintrag an:

Feld	Wert
Quelle – Protokoll	HTTPS
Quelle – Hostname	chat.example.synology.me
Quelle – Port	443
Ziel – Protokoll	HTTP
Ziel – Hostname	localhost
Ziel – Port	8065

Anschließend muss WebSocket-Unterstützung aktiviert werden, sonst funktionieren Echtzeit-Updates (neue Nachrichten, Tipp-Indikatoren) nicht. Wechsle im Proxy-Eintrag auf den Tab Benutzerdefinierte Header und füge zwei Einträge hinzu:

Header-Name	Wert
Upgrade	$http_upgrade
Connection	upgrade

Stelle außerdem sicher, dass in Systemsteuerung > Sicherheit > Firewall Port 443 von außen erreichbar ist. Port 8065 muss nicht direkt geöffnet werden.

Verifizieren: Rufe im Browser https://chat.example.synology.me auf. Du solltest die Mattermost-Einrichtungsseite sehen. Ein SSL-Fehler deutet auf ein fehlendes Zertifikat hin; ein „502 Bad Gateway“ zeigt, dass der Reverse Proxy den Container nicht erreicht (Container läuft noch nicht oder falscher Port).

Schritt 6: Erstadmin einrichten und System-Konfiguration prüfen

Beim ersten Aufruf der Mattermost-URL erscheint automatisch der Einrichtungsassistent. Lege dort E-Mail-Adresse, Benutzernamen und ein starkes Passwort für den ersten Administrator-Account fest. Danach ist der Setup-Wizard dauerhaft deaktiviert – weitere Admins werden über System Console > Nutzer > Rolle ändern angelegt.

Nach der Erstanmeldung empfehlen sich folgende Prüfpunkte in der System Console (Produktname oben links > System Console):

Environment > Web Server: Prüfe, ob „Site URL“ korrekt auf deine HTTPS-URL zeigt.
Environment > SMTP: Falls SMTP konfiguriert, hier den Test-Button nutzen.
Experimental > Bleve: Bleve-Suche aktivieren und Indexierungspfad bestätigen.
Environment > Push Notification Server: Test-Push-Benachrichtigung absenden.

Verifizieren: Erstelle einen zweiten Test-Nutzer per Einladungslink und sende eine Direktnachricht. Wenn die Nachricht in Echtzeit erscheint (ohne manuelles Reload), funktionieren WebSocket-Verbindung und Reverse Proxy korrekt.

Schritt 7: SMTP für E-Mail-Benachrichtigungen aktivieren (optional)

Für Nutzereinladungen, Passwort-Reset und E-Mail-Benachrichtigungen braucht Mattermost einen SMTP-Relay. Kommentiere in der Compose-Datei die entsprechenden Zeilen ein und ersetze die Platzhalter:

      MM_EMAILSETTINGS_SMTPSERVER: smtp.example.com
      MM_EMAILSETTINGS_SMTPPORT: "587"
      MM_EMAILSETTINGS_CONNECTIONSECURITY: STARTTLS
      MM_EMAILSETTINGS_SMTPUSERNAME: user@example.com
      MM_EMAILSETTINGS_SMTPPASSWORD: APP_PASSWORT
      MM_EMAILSETTINGS_SENDEMAILNOTIFICATIONS: "true"
      MM_EMAILSETTINGS_REQUIREEMAILVERIFICATION: "true"

Starte danach den mattermost-app-Container im Container Manager neu (nicht den gesamten Stack – die Datenbank läuft weiter).

Verifizieren: Gehe in der System Console zu Environment > SMTP und klicke auf Test Connection. Eine erfolgreiche Verbindung zeigt „SMTP connection test successful.“ Danach eine Einladungs-E-Mail an eine externe Adresse senden und Zustellung prüfen.

Technische Eckdaten

Parameter	Wert
Mattermost-Image	mattermost/mattermost-team-edition:11.7.0 (ESR, Support bis 2027-05-15)
PostgreSQL-Image	postgres:18-alpine
Web-Port (intern)	8065/TCP (HTTP, nur für Reverse Proxy)
Calls/WebRTC-Port	8443/TCP+UDP (optional, nur Calls-Plugin)
Container-UID/GID	2000:2000 (alle Mattermost-Volumes)
RAM-Bedarf	ca. 500 MB–1 GB (empfohlen: max. 4 GB mem_limit)
Lizenz Team Edition	kostenlos, MIT-Lizenz, kein Nutzer-Limit

Troubleshooting / Typische Fehler

Container startet nicht / „permission denied“: Die Mattermost-Verzeichnisse gehören noch Root statt UID 2000. Lösung: SSH-Befehl aus Schritt 2 erneut ausführen, danach Container neu starten.
„address not in DNS“ oder Blank-Screen nach Setup: MM_SERVICESETTINGS_SITEURL fehlt, ist leer oder enthält http:// statt https://. Compose-Datei korrigieren, Container neu starten.
„connect: connection refused“ (DB-Verbindungsfehler): Der Hostname im Datasource-String ist falsch – muss der Service-Name im Docker-Netzwerk sein (db), nicht localhost.
WebSocket schlägt fehl / Echtzeit-Updates fehlen: Synology Reverse Proxy hat keine WebSocket-Header. Lösung: Im Application Portal benutzerdefinierte Header Upgrade: $http_upgrade und Connection: upgrade hinzufügen (Schritt 5).
E-Mail-Einladungen kommen nicht an: Entweder SMTP nicht konfiguriert, oder der SMTP-Server blockiert E-Mails aus dem Docker-Netzwerk (172.x.x.x). Lösung: Authentifizierten SMTP-Relay mit App-Passwort nutzen.
Mobile Push-Benachrichtigungen funktionieren nicht: Die NAS-URL ist nicht aus dem Internet erreichbar. Lösung: DynDNS oder Synology QuickConnect konfigurieren. Alternativ: eigenen ntfy-Push-Proxy auf dem Synology NAS einrichten.
Update schlägt fehl: Nie mehr als eine Hauptversion gleichzeitig überspringen (z. B. 9.x → 10.x → 11.x). DB-Migrationen müssen sequenziell laufen. Vor jedem Update: PostgreSQL-Dump erstellen.

Häufige Fragen

Team Edition oder Enterprise Edition – was braucht ein KMU?

Für die meisten KMU ist die Team Edition vollständig ausreichend: unbegrenzte Nutzer und Channels, Direktnachrichten, Threads, Dateiablage, Volltext-Suche, mobile Apps und Integrationen – kostenlos ohne Lizenzkosten. Die Enterprise Edition wird erst nötig bei Active-Directory-/LDAP-SSO, SAML, erweiterten Compliance-Features oder Gäste-Accounts. Der einzige Unterschied beim Deployment ist der Image-Name: mattermost-enterprise-edition statt mattermost-team-edition.

Wie prüfe ich, ob die DB-Migration erfolgreich war?

Nach dem ersten Start die Container-Logs prüfen:

docker logs mattermost-app 2>&1 | grep -i migrat

Eine erfolgreiche Migration zeigt Finished running database migrations. Anschließend http://NAS-IP:8065 aufrufen – der Setup-Wizard erscheint bei erfolgreicher DB-Verbindung.

Wie viel Speicher braucht Mattermost langfristig?

Die Datenbank startet mit ca. 50–200 MB für kleine Teams. Nutzer-Uploads im data-Verzeichnis können je nach Nutzung schnell mehrere Gigabyte erreichen – ein Speicher-Quota auf /volume1/docker/mattermost/data im Synology DSM ist empfehlenswert. Der Container selbst benötigt ca. 500 MB bis 1 GB RAM.

Mattermost vs. Microsoft Teams – was taugt Mattermost wirklich?

Mattermost bietet volle Datenkontrolle ohne Cloud-Pflichtvertrag, ist DSGVO-konform on-premise betreibbar und hat kein Nutzer-Limit in der kostenlosen Edition. Nachteile: kein natives Videokonferenz (nur über das optionale Calls-Plugin), kein integrierter Office-365-Workflow. Für einen direkten Vergleich beider Plattformen aus KMU-Sicht empfiehlt sich die Anleitung Microsoft Teams für KMU einrichten und absichern.

Was ist mit dem Calls-Plugin für Sprach- und Videoanrufe?

Das Calls-Plugin ermöglicht direkte Browser-basierte Sprach- und Videoanrufe innerhalb von Mattermost. Es benötigt zusätzlich Port 8443 (UDP/TCP) für WebRTC-TURN. Das Plugin ist in der Team Edition enthalten, muss aber in der System Console aktiviert und in der Synology-Firewall freigeschaltet werden. Für reine Text-Kommunikation ist das Plugin nicht zwingend nötig.

Wie gehe ich bei einem Mattermost-Update vor?

Den Image-Tag in der Compose-Datei auf die neue Version ändern und das Projekt im Container Manager neu erstellen. Mattermost führt die DB-Migration automatisch beim Start durch. Nie mehr als eine Hauptversion gleichzeitig überspringen. Vor jedem Update einen PostgreSQL-Dump erstellen:

docker exec mattermost-db pg_dump -U mmuser mattermost > /volume1/docker/mattermost/backup_$(date +%Y%m%d).sql

Fazit

Mattermost auf dem Synology NAS ist ein solider, kostengünstiger Slack-Ersatz für KMU-Teams, die Wert auf Datenkontrolle und DSGVO-Konformität legen. Der Compose-Stack aus PostgreSQL und Mattermost Team Edition ist in weniger als einer Stunde aufgesetzt und danach wartungsarm. Die wichtigsten Fallstricke sind die UID-2000-Berechtigungen auf dem Host, die korrekte MM_SERVICESETTINGS_SITEURL und die WebSocket-Header im Reverse Proxy – wer diese drei Punkte beachtet, bekommt eine stabile, selbst gehostete Kommunikationsplattform, die Teams und Slack in vielen KMU-Szenarien vollwertig ersetzen kann.

Weiterführende Anleitungen und Quellen

Microsoft Teams für KMU einrichten und absichern – direkter Vergleichsartikel für die Entscheidung Teams vs. Mattermost
ntfy auf dem Synology NAS: Push-Benachrichtigungen für Server und Skripte – eigener Push-Proxy als Alternative zum Mattermost Public Push Proxy
Nginx Proxy Manager auf der Synology mit Container Manager einrichten – alternative Reverse-Proxy-Lösung

Offizielle Quellen: Alle technischen Details basieren auf der offiziellen Mattermost-Dokumentation (docs.mattermost.com) und dem offiziellen Mattermost-Docker-Repository auf GitHub (github.com/mattermost/docker). Die mariushosting-Anleitung diente als Orientierung für den Synology-spezifischen Ablauf; Abweichungen (Image-Tag, UID, PostgreSQL-Image) wurden zugunsten der offiziellen Empfehlungen korrigiert.