Chatwoot auf dem Synology NAS installieren: Kundensupport mit Live-Chat

Wer Kundenanfragen professionell bearbeiten will, kennt das Problem: Intercom, Zendesk und Freshdesk sind leistungsstark, aber teuer – jeder Agenten-Sitz kostet monatlich. Chatwoot ist die meistgenutzte Open-Source-Antwort darauf: eine Omnichannel-Plattform, die Live-Chat-Widget, E-Mail-Postfach, WhatsApp, Facebook Messenger und weitere Kanäle in einer einzigen Inbox vereint. Agenten weisen Konversationen zu, hinterlegen interne Notizen und versenden Antworten – alles unter einem Dach. Auf dem Synology NAS läuft Chatwoot als Vier-Dienste-Compose-Stack vollständig im Container Manager und speichert alle Daten lokal. Keine Abo-Kosten pro Sitz, volle Datenkontrolle, DSGVO-konform.

Voraussetzungen

• Synology NAS mit x86_64-Prozessor (z. B. DS923+, DS1522+, DS1823xs+) und mindestens 4 GB RAM installiert (2 GB für DSM, ~1 GB für den Chatwoot-Stack)
• DSM 7.2 oder neuer mit installiertem Container Manager (kostenlos im Package Center)
• SSH-Zugang zum NAS – du benötigst ihn für den Datenbank-Init-Befehl; Aktivierung Schritt für Schritt: SSH auf dem Synology NAS aktivieren und verbinden
• Domain oder DynDNS-Adresse mit gültigem HTTPS-Zertifikat (z. B. *.synology.me Wildcard-Zertifikat oder eigene Domain mit Let's Encrypt) – Chatwoot benötigt zwingend HTTPS für Cookies und das Live-Chat-Widget
• Ca. 2 GB freier Speicherplatz auf dem Volume für Images und Datenbankwachstum
• SMTP-Zugangsdaten für E-Mail-Versand (Gmail App-Passwort, Sendgrid, Mailgun o. ä.) – optional, aber für den E-Mail-Kanal notwendig
• Grundkenntnisse in Docker Compose – Auffrischung: Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren

Schritt 1: Ordnerstruktur anlegen

Chatwoot benötigt drei persistente Volumes: eines für die Rails-Datei-Uploads, eines für die PostgreSQL-Datenbank und eines für Redis. Lege alle Ordner vor dem ersten Stack-Start an – der Container Manager würde sie sonst mit falschen Berechtigungen erstellen, was PostgreSQL mit einem wrong ownership-Fehler quittiert.

Öffne die File Station und erstelle folgende Verzeichnisse unterhalb von /volume1/docker/:

/volume1/docker/chatwoot/
/volume1/docker/chatwoot/storage
/volume1/docker/chatwoot/db
/volume1/docker/chatwoot/redis

Alle drei Unterordner müssen existieren, bevor du den Stack startest. Eigentümer root, Berechtigungen 755 sind ausreichend; den Detailweg für Ordnerberechtigungen zeigt: Docker-Ordner und Berechtigungen auf dem Synology NAS.

Verifizieren: Öffne die File Station und navigiere nach /volume1/docker/chatwoot. Du siehst drei Unterordner: storage, db und redis. Alle drei müssen vorhanden sein, bevor du weiter machst.

Schritt 2: SECRET_KEY_BASE und Passwörter generieren

Chatwoot benötigt einen 128-stelligen alphanumerischen Zufallsschlüssel als SECRET_KEY_BASE. Wichtig: Der Schlüssel darf ausschließlich die Zeichen A–Z, a–z und 0–9 enthalten – Sonderzeichen wie !, @ oder # führen beim Rails-Start zu einem ArgumentError. Verbinde dich per SSH mit dem NAS und führe folgenden Befehl aus:

cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 128 ; echo

Kopiere die Ausgabe in einen Texteditor. Generiere außerdem zwei sichere Passwörter für PostgreSQL und Redis. Notiere dir alle drei Werte – du trägst sie gleich in die Compose-Datei ein.

Verifizieren: Der generierte Schlüssel ist exakt 128 Zeichen lang und enthält ausschließlich Buchstaben und Ziffern. Prüfe mit ... | wc -c – die Ausgabe muss 128 sein.

Eckdaten auf einen Blick

Parameter	Wert
Image Rails/Sidekiq	chatwoot/chatwoot:v4.14.2 (stabiles Release, Juni 2026)
Image PostgreSQL	pgvector/pgvector:pg16 (offiziell, mit pgvector-Extension)
Image Redis	redis:alpine
Host-Port → Container	3248:3000 (Rails Web-App; Reverse Proxy notwendig)
PostgreSQL / Redis	nur intern erreichbar (kein Port-Mapping nach außen)
Storage-Volume	/volume1/docker/chatwoot/storage:/app/storage
DB-Volume	/volume1/docker/chatwoot/db:/var/lib/postgresql/data
Redis-Volume	/volume1/docker/chatwoot/redis:/data
RAM-Bedarf gesamt	~1 GB (Rails 512 MB, Sidekiq 256 MB, PG 128 MB, Redis 30 MB)

Schritt 3: Compose-Datei erstellen und Stack starten

Öffne den Container Manager, wechsle zu Projekt → Erstellen und lege ein neues Projekt mit dem Namen chatwoot an. Füge folgende compose.yaml ein und ersetze alle Platzhalter:

• HIEREIN128STELLIGENALPHANUMERISCHENSCHLUESSEL → deinen generierten SECRET_KEY_BASE (identisch in Rails und Sidekiq!)
• chatwoot.meinedomain.de → deine tatsächliche Domain (inkl. https://, ohne abschließenden Slash)
• chatwootpass → dein gewähltes PostgreSQL-Passwort (an beiden Stellen identisch)
• REDIS_PASSWORT → dein gewähltes Redis-Passwort (an beiden Stellen identisch)

version: "3"

services:

  base: &base
    image: chatwoot/chatwoot:v4.14.2
    restart: always
    volumes:
      - /volume1/docker/chatwoot/storage:/app/storage

  rails:
    <<: *base
    container_name: Chatwoot-RAILS
    hostname: rails
    depends_on:
      - postgres
      - redis
    ports:
      - "3248:3000"
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=HIEREIN128STELLIGENALPHANUMERISCHENSCHLUESSEL
      - FRONTEND_URL=https://chatwoot.meinedomain.de
      - DATABASE_URL=postgresql://chatwootuser:chatwootpass@chatwoot-db:5432/chatwoot_production
      - REDIS_URL=redis://:REDIS_PASSWORT@chatwoot-redis:6379
      - DEFAULT_LOCALE=de
      - MAILER_SENDER_EMAIL=noreply@meinedomain.de
      - SMTP_ADDRESS=smtp.example.com
      - SMTP_USERNAME=noreply@meinedomain.de
      - SMTP_PASSWORD=smtp-passwort
      - SMTP_TLS=true
      - ENABLE_ACCOUNT_SIGNUP=false
      - TZ=Europe/Berlin
    entrypoint: docker/entrypoints/rails.sh
    command: ["bundle", "exec", "rails", "s", "-p", "3000", "-b", "0.0.0.0"]

  sidekiq:
    <<: *base
    container_name: Chatwoot-SIDEKIQ
    hostname: sidekiq
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=HIEREIN128STELLIGENALPHANUMERISCHENSCHLUESSEL
      - FRONTEND_URL=https://chatwoot.meinedomain.de
      - DATABASE_URL=postgresql://chatwootuser:chatwootpass@chatwoot-db:5432/chatwoot_production
      - REDIS_URL=redis://:REDIS_PASSWORT@chatwoot-redis:6379
      - DEFAULT_LOCALE=de
      - MAILER_SENDER_EMAIL=noreply@meinedomain.de
      - SMTP_ADDRESS=smtp.example.com
      - SMTP_USERNAME=noreply@meinedomain.de
      - SMTP_PASSWORD=smtp-passwort
      - SMTP_TLS=true
      - TZ=Europe/Berlin
    command: ["bundle", "exec", "sidekiq", "-C", "config/sidekiq.yml"]

  postgres:
    image: pgvector/pgvector:pg16
    container_name: Chatwoot-DB
    hostname: chatwoot-db
    restart: always
    volumes:
      - /volume1/docker/chatwoot/db:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot_production
      - POSTGRES_USER=chatwootuser
      - POSTGRES_PASSWORD=chatwootpass

  redis:
    image: redis:alpine
    container_name: Chatwoot-REDIS
    hostname: chatwoot-redis
    restart: always
    command: ["sh", "-c", "redis-server --requirepass \"REDIS_PASSWORT\""]
    volumes:
      - /volume1/docker/chatwoot/redis:/data

Hinweis: Rails und Sidekiq müssen identische Werte für SECRET_KEY_BASE, DATABASE_URL und REDIS_URL tragen – sie teilen sich Datenbank und Storage-Volume. ENABLE_ACCOUNT_SIGNUP=false verhindert, dass sich Fremde selbst registrieren; für private Instanzen immer setzen. Das PostgreSQL-Image muss zwingend pgvector/pgvector:pg16 sein – das Standard-Image postgres:16 fehlt die pgvector-Extension und führt beim Init-Befehl zu einem Fehler.

Verifizieren: Starte das Projekt im Container Manager. Nach etwa zwei Minuten sollten alle vier Container grün sein. Prüfe die Logs des Chatwoot-RAILS-Containers – du siehst Booting Puma und danach einen Datenbankfehler (relation does not exist). Das ist normal – der Init-Schritt folgt im nächsten Abschnitt.

Schritt 4: Datenbank initialisieren (db:chatwoot_prepare)

Dies ist der wichtigste und am häufigsten vergessene Schritt. Ohne die Datenbankinitialisierung zeigt Chatwoot beim ersten Aufruf nur Datenbankfehler. Der Befehl erstellt alle Tabellen, installiert die pgvector-Extension und legt Seed-Daten an. Führe ihn per SSH aus:

docker exec -it Chatwoot-RAILS bundle exec rails db:chatwoot_prepare

Das dauert beim ersten Mal etwa 60–90 Sekunden. Starte danach den Rails-Container neu:

docker restart Chatwoot-RAILS

Verifizieren: Prüfe die Logs nach dem Neustart. Du siehst nun Listening on http://0.0.0.0:3000 ohne Datenbankfehler. Ein Aufruf von http://nas-ip:3248 im Browser (nur zur Überprüfung, noch per HTTP) sollte den Chatwoot-Onboarding-Assistenten oder den Login-Bildschirm laden.

Schritt 5: Reverse Proxy mit WebSocket-Unterstützung einrichten

Das Live-Chat-Widget benötigt WebSocket-Verbindungen für Echtzeit-Updates; ohne die entsprechenden HTTP-Header zeigt das Widget dauerhaft „Connecting…". Richte im DSM einen Reverse Proxy ein unter Systemsteuerung → Anmeldeportal → Erweitert → Reverseproxy:

Feld	Wert
Quellprotokoll	HTTPS
Quellhostname	chatwoot.meinedomain.de
Quellport	443
Zielprotokoll	HTTP
Zielhost	localhost
Zielport	3248

Klicke anschließend auf Benutzerdefinierter Header → Erstellen → WebSocket. DSM fügt automatisch die Header Upgrade: websocket und Connection: Upgrade ein. Als Alternative zum DSM-Reverse-Proxy funktioniert auch ein Nginx Proxy Manager auf dem gleichen NAS: Nginx Proxy Manager auf der Synology mit Container Manager einrichten.

Öffne außerdem Port 443 in der DSM-Firewall, sofern noch nicht geschehen: DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben.

Verifizieren: Öffne https://chatwoot.meinedomain.de im Browser. Du siehst den Onboarding-Assistenten oder den Login-Bildschirm mit gültigem HTTPS-Schloss. Prüfe in den Browser-Entwicklertools (F12 → Netzwerk → WS), ob WebSocket-Verbindungen aufgebaut werden (Status 101 Switching Protocols).

Schritt 6: Onboarding und erste Inbox einrichten

Beim ersten Aufruf startet der Onboarding-Assistent automatisch und führt dich durch: Account erstellen (Name, E-Mail, Passwort des ersten Admins), Account-Name des Unternehmens, erste Inbox anlegen. Wähle für einen schnellen Test den Kanal „Website" (Live-Chat-Widget). Nach Abschluss erhältst du einen JavaScript-Snippet – bette ihn auf einer Test-HTML-Seite ein:

<script>
  (function(d,t) {
    var BASE_URL="https://chatwoot.meinedomain.de";
    var g=d.createElement(t),s=d.getElementsByTagName(t)[0];
    g.src=BASE_URL+"/packs/js/sdk.js";
    g.defer = true;
    g.async = true;
    s.parentNode.insertBefore(g,s);
    g.onload=function(){
      window.chatwootSDK.run({
        websiteToken: 'DEIN-TOKEN',
        baseUrl: BASE_URL
      })
    }
  })(document,"script");
</script>

Verifizieren: Öffne deine Test-Seite im Browser. Das Chatwoot-Widget erscheint als Bubble rechts unten. Sende eine Testnachricht – sie erscheint im Dashboard unter Konversationen als neue Anfrage. Das ist der Beweis, dass der gesamte Stack korrekt funktioniert: Rails verarbeitet die Anfrage, Sidekiq die Hintergrundprozesse, und WebSocket liefert die Echtzeit-Updates.

Schritt 7: E-Mail-Kanal konfigurieren (optional)

Die SMTP-Variablen sind bereits in der Compose-Datei hinterlegt. Um auch eingehende E-Mails als Konversationen zu verarbeiten, richtest du im Dashboard eine E-Mail-Inbox ein: Einstellungen → Inboxes → E-Mail-Postfach. Trage dort die IMAP-Zugangsdaten ein. Alternativ nutzt du die von Chatwoot generierte Forward-Adresse: Eingehende E-Mails an deine Support-Adresse werden per Weiterleitung dorthin geleitet und tauchen automatisch als neue Konversationen auf.

Verifizieren: Sende eine Test-E-Mail an die konfigurierte Inbox-Adresse. Nach wenigen Sekunden (Sidekiq verarbeitet die E-Mail im Hintergrund) erscheint sie als neue Konversation im Dashboard. Antworte aus Chatwoot heraus und prüfe, ob die Antwort beim Absender ankommt.

Upgrade-Prozess

Beim Upgrade auf eine neue Chatwoot-Version passt du den Image-Tag in der Compose-Datei an und führst folgende Befehle aus:

docker compose pull
docker compose up -d
docker exec -it Chatwoot-RAILS bundle exec rails db:chatwoot_prepare

Der Befehl db:chatwoot_prepare ist idempotent – er führt ausstehende Migrationen durch, ohne vorhandene Daten zu verlieren.

Troubleshooting / Typische Fehler

• ArgumentError: secret_key_base must be alphanumeric: Dein SECRET_KEY_BASE enthält Sonderzeichen. Generiere einen neuen Schlüssel ausschließlich mit A-Za-z0-9 (Befehl aus Schritt 2), trage ihn in beide Dienste identisch ein und starte den Stack neu.
• relation does not exist / leere Seite nach Start: Du hast db:chatwoot_prepare noch nicht ausgeführt. Führe den Befehl aus Schritt 4 aus und starte den Rails-Container neu.
• Live-Chat-Widget zeigt dauerhaft „Connecting…": WebSocket-Header fehlen im Reverse Proxy. Öffne den Reverse-Proxy-Eintrag im DSM, gehe zu „Benutzerdefinierter Header" und aktiviere die WebSocket-Option.
• CORS-Fehler im Browser / Widget-Snippet mit falscher URL: FRONTEND_URL enthält einen abschließenden Slash oder nutzt HTTP statt HTTPS. Korrigiere den Wert auf exakt https://chatwoot.meinedomain.de (ohne Slash), aktualisiere beide Dienste und starte neu.
• FATAL: data directory has wrong ownership: Das Volume-Verzeichnis /volume1/docker/chatwoot/db existiert nicht oder hat falsche Berechtigungen. Lege den Ordner manuell in der File Station an (Schritt 1) und starte den Stack neu.
• extension pgvector does not exist bei db:chatwoot_prepare: Du verwendest postgres:16 statt pgvector/pgvector:pg16. Ändere das Image in der Compose-Datei – das Standard-Postgres-Image enthält die pgvector-Extension nicht.
• NOAUTH Authentication required (Redis-Fehler): Das Redis-Passwort in REDIS_URL stimmt nicht. Korrektes Format: redis://:PASSWORT@chatwoot-redis:6379 (Doppelpunkt vor dem Passwort nicht vergessen).

Häufige Fragen

Muss ich SECRET_KEY_BASE in Rails und Sidekiq wirklich doppelt eintragen?

Ja. Beide Dienste starten das gleiche Rails-Image und müssen denselben Schlüssel verwenden, um Session-Cookies und verschlüsselte Daten korrekt zu verarbeiten. Ein unterschiedlicher Schlüssel führt zu kryptischen Fehlern bei der Hintergrundverarbeitung. Trage den Wert exakt identisch in beide environment-Blöcke ein.

Wann und wie oft muss ich db:chatwoot_prepare ausführen?

Beim ersten Start (Erstinstallation) ist es Pflicht. Nach jedem Versions-Upgrade ebenfalls – der Befehl führt ausstehende Datenbankmigrationen durch. Er ist idempotent und schadet nicht, wenn du ihn vorsichtshalber nach jedem Update ausführst. Anschließend immer den Rails-Container neu starten.

Kann ich Chatwoot ohne öffentliche Domain (nur im LAN) betreiben?

Grundsätzlich ja: Setze FRONTEND_URL=http://nas-ip:3248. Das Live-Chat-Widget funktioniert dann auf Seiten, die unter derselben IP laufen. Externe Kanal-Webhooks (WhatsApp, Facebook Messenger) benötigen jedoch eine öffentlich erreichbare HTTPS-URL – für diese Integrationen ist eine öffentliche Domain Pflicht.

Was unterscheidet Chatwoot von FreeScout und Mattermost?

FreeScout ist ein reiner E-Mail-Helpdesk ohne Live-Chat – ideal, wenn du nur ein gemeinsames Postfach für Support-E-Mails brauchst. Mattermost ist internes Team-Chat ohne externen Kundenkontakt. Chatwoot schließt die Lücke: externer Kundenkontakt über Live-Chat, E-Mail, WhatsApp und mehr in einer Plattform.

Was ist der Unterschied zwischen latest, latest-ce und einem gepinnten Tag?

latest ist das Standard-Release-Image. latest-ce (Community Edition) ist für Selfhosting funktional identisch mit latest. Gepinnte Tags wie v4.14.2 sind die beste Wahl: Du weißt exakt, welche Version läuft, und kannst Upgrades kontrolliert durchführen.

Fazit

Chatwoot ist eine ausgereifte Plattform, die auf dem Synology NAS überraschend reibungslos läuft – vorausgesetzt, man beachtet drei kritische Punkte: SECRET_KEY_BASE muss alphanumerisch sein, db:chatwoot_prepare darf nicht vergessen werden, und der Reverse Proxy braucht zwingend WebSocket-Unterstützung. Der Vier-Dienste-Stack benötigt rund 1 GB RAM im Betrieb und läuft stabil auf jedem x86_64-Synology mit 4 GB verbautem RAM. Für KMUs, die Intercom oder Zendesk durch eine datenschutzkonforme Selfhosted-Lösung ersetzen wollen, ist Chatwoot die erste Adresse: keine Sitzkosten, volle DSGVO-Kontrolle, aktiv gepflegt.

Weiterführende Anleitungen und Quellen

• FreeScout auf dem Synology NAS installieren: Helpdesk-Postfach für Support-Teams – die Alternative für reinen E-Mail-Helpdesk ohne Live-Chat
• Mattermost auf dem Synology NAS installieren: Team-Chat als Slack-Alternative – für interne Teamkommunikation neben dem Kundensupport
• Nginx Proxy Manager auf der Synology mit Container Manager einrichten – Reverse Proxy mit Let's Encrypt als Alternative zum DSM-Reverse-Proxy
• Portainer auf Synology NAS installieren – Container-Verwaltung mit erweiterter Web-Oberfläche

Offizielle Quellen: Chatwoot Docker-Deployment-Dokumentation (developers.chatwoot.com) und Environment-Variables-Referenz – beide bilden die fachliche Grundlage dieser Anleitung. Das Chatwoot GitHub-Repository enthält die aktuelle docker-compose.production.yaml als offizielle Compose-Referenz.