Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Synology / NAS 11.09.2026 · 9 min Lesezeit

Cal.com auf dem Synology NAS installieren: Terminbuchung als Calendly-Alternative

Cal.com v6.2.0 mit PostgreSQL im Synology Container Manager: Schlüssel erzeugen, Domain und Reverse Proxy, erstes Konto, Kalender verbinden, Backup. Mit Hinweis auf den Projektwechsel zu Cal.diy.

Geprüft am 14.10.2026 · für cal.com 6.2.0

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Heller Schreibtisch mit offenem Notizbuch und Kaffeetasse, im Hintergrund ein NAS im Holzregal und eine Wanduhr

Cal.com ist eine quelloffene Terminbuchung: Kunden wählen auf einer öffentlichen Seite einen freien Termin, die Software gleicht ihn mit Ihrem Kalender ab und verschickt Bestätigungen. Auf einem Synology NAS betreiben Sie Cal.com mit dem fertigen Image calcom/cal.com und PostgreSQL als Projekt im Container Manager. Diese Anleitung zeigt den Aufbau mit dem letzten veröffentlichten Image v6.2.0 und erklärt, was sich beim Projekt geändert hat, bevor Sie es einplanen.

Voraussetzungen

  • Synology NAS mit DSM 7.2 oder neuer und Container Manager. Für x86_64-Modelle nutzen Sie v6.2.0, für ARM64-Modelle v6.2.0-arm.
  • 4 GB RAM; das Image ist komprimiert rund 1,6 GB groß.
  • Mindestens 5 GB frei auf dem Volume.
  • Eine Domain oder Synology-DDNS-Adresse mit Zertifikat und einen Reverse Proxy, zum Beispiel Nginx Proxy Manager auf der Synology.
  • SMTP-Zugang für Bestätigungsmails.
  • SSH für das Erzeugen der Schlüssel und für Backups (SSH auf dem Synology NAS aktivieren).

Eckdaten auf einen Blick

EigenschaftWert
Imagecalcom/cal.com:v6.2.0 (amd64) bzw. v6.2.0-arm (arm64), Stand März 2026
Datenbankpostgres:15
Port3000 im Container
Daten/volume1/docker/calcom/postgres
Lizenz v6.2.0AGPLv3, Enterprise-Verzeichnisse unter kommerzieller Lizenz
Lizenz Cal.diyMIT, ohne Teams, Organisationen, Workflows, SSO

Schritt 1: Projektstand prüfen und Ordner anlegen

Klären Sie vor der Installation, ob das Projekt zu Ihrem Zweck passt. Das Repository github.com/calcom/cal.com leitet inzwischen auf calcom/cal.diy weiter. Cal.diy ist laut README die Community-Edition ohne Enterprise-Code und wird „strictly recommended for personal, non-production use“. Für kommerzielle Terminbuchung verweist der Hersteller auf das gehostete Cal.com oder ein Enterprise-Angebot. Für Cal.diy veröffentlicht der Hersteller auf Docker Hub bisher keine fertigen Images; das Image calcom/cal.com endet bei v6.2.0. Spätere Versionen müssten Sie selbst bauen, was das Dockerfile mit 4 bis 6 GB Node-Speicher für den Build vorsieht und auf einem NAS kaum sinnvoll ist.

Passt das, legen Sie in der File Station unter /volume1/docker den Ordner calcom mit dem Unterordner postgres an.

Verifizieren: /volume1/docker/calcom/postgres ist in der File Station vorhanden und leer.

Schritt 2: Schlüssel erzeugen

Cal.com braucht zwei Schlüssel. NEXTAUTH_SECRET verschlüsselt die Sitzungs-Cookies, CALENDSO_ENCRYPTION_KEY verschlüsselt gespeicherte Zugangsdaten, etwa für verbundene Kalender. Die Werte secret aus der Vorlage sind laut README ein Sicherheitsrisiko. Erzeugen Sie per SSH die Werte so, wie die README es vorgibt:

openssl rand -base64 32
openssl rand -base64 24

Die erste Ausgabe ist Ihr NEXTAUTH_SECRET. Die zweite ergibt 32 Zeichen und damit die 32 Byte, die AES-256 für CALENDSO_ENCRYPTION_KEY verlangt. Legen Sie außerdem ein Datenbankpasswort aus Buchstaben und Ziffern fest; Sonderzeichen wie @ oder / müssten in der Datenbank-URL kodiert werden.

Verifizieren: Die erste Ausgabe ist 44 Zeichen lang, die zweite 32 Zeichen. Beide Werte liegen in Ihrem Passwortmanager.

Schritt 3: Compose-Datei vorbereiten

Der folgende Aufbau orientiert sich an der Compose-Datei und den Laufzeitvariablen der README zu v6.2.0. Er enthält nur Datenbank und Web-App. Die offizielle Datei enthält zusätzlich die API v2 mit Redis, die laut README nur für eigene Integrationen nötig ist, und Prisma Studio, das Sie laut Kommentar im Produktivbetrieb entfernen sollen, weil es direkten Zugriff auf die Datenbank gibt.

services:
  database:
    image: postgres:15
    container_name: calcom-db
    restart: unless-stopped
    volumes:
      - /volume1/docker/calcom/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: calcom
      POSTGRES_PASSWORD: IHR_DB_PASSWORT
      POSTGRES_DB: calcom
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U calcom -d calcom"]
      interval: 10s
      timeout: 5s
      retries: 5

  calcom:
    image: calcom/cal.com:v6.2.0
    container_name: calcom
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    depends_on:
      database:
        condition: service_healthy
    environment:
      DATABASE_HOST: database:5432
      DATABASE_URL: postgresql://calcom:IHR_DB_PASSWORT@database:5432/calcom
      DATABASE_DIRECT_URL: postgresql://calcom:IHR_DB_PASSWORT@database:5432/calcom
      NEXT_PUBLIC_WEBAPP_URL: https://termine.ihre-domain.de
      NEXTAUTH_SECRET: IHR_NEXTAUTH_SECRET
      CALENDSO_ENCRYPTION_KEY: IHR_ENCRYPTION_KEY
      CALCOM_TELEMETRY_DISABLED: "1"
      TZ: Europe/Berlin
      EMAIL_FROM: termine@ihre-domain.de
      EMAIL_FROM_NAME: Terminbuchung
      EMAIL_SERVER_HOST: smtp.ihr-anbieter.de
      EMAIL_SERVER_PORT: "587"
      EMAIL_SERVER_USER: termine@ihre-domain.de
      EMAIL_SERVER_PASSWORD: IHR_SMTP_PASSWORT

Auf ARM-Modellen ersetzen Sie den Tag durch v6.2.0-arm. Die Portbindung an 127.0.0.1 sorgt dafür, dass Cal.com nur über den Reverse Proxy auf demselben NAS erreichbar ist. Läuft Ihr Proxy auf einem anderen Gerät, verwenden Sie "3000:3000" und beschränken den Zugriff in der DSM-Firewall.

Wichtige Umgebungsvariablen im Überblick

VariablePflichtBedeutung
DATABASE_URLjaVerbindung zu PostgreSQL mit Zugangsdaten
DATABASE_HOSTjaHost und Port, auf die das Startskript des Images wartet
NEXTAUTH_SECRETjaSchlüssel für Sitzungs-Cookies
CALENDSO_ENCRYPTION_KEYjaSchlüssel für gespeicherte Zugangsdaten, 32 Byte
NEXT_PUBLIC_WEBAPP_URLpraktisch jaöffentliche Adresse ohne Schrägstrich am Ende; weicht sie vom Build-Wert ab, ersetzt das Image sie beim Start
NEXTAUTH_URLneinStandard ist NEXT_PUBLIC_WEBAPP_URL/api/auth
EMAIL_*für MailsSMTP-Versand von Bestätigungen

Verifizieren: Kein Platzhalter IHR_ ist übrig, das Datenbankpasswort steht an drei Stellen gleich, und NEXT_PUBLIC_WEBAPP_URL beginnt mit https:// und endet ohne Schrägstrich.

Schritt 4: Projekt im Container Manager starten

Öffnen Sie den Container Manager, wählen Sie Projekt > Erstellen, Projektname calcom, Pfad /volume1/docker/calcom, Quelle „docker-compose.yml erstellen“, und fügen Sie die Datei aus Schritt 3 ein. Lassen Sie das Projekt nach dem Assistenten starten. Wie Projekte im Container Manager funktionieren, erklärt Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren.

Das Startskript des Images ersetzt zuerst die eingebaute Adresse durch Ihre NEXT_PUBLIC_WEBAPP_URL, wartet auf die Datenbank, führt die Datenbankmigrationen aus, füllt den App Store und startet dann die Web-App. Der erste Start dauert deshalb einige Minuten.

Verifizieren: Beide Container laufen, im Protokoll von calcom erscheinen die Meldungen zu den Migrationen ohne Fehler, und der im Image eingebaute Healthcheck meldet den Container nach kurzer Zeit als gesund. Per SSH liefert curl -I http://127.0.0.1:3000 eine HTTP-Antwort.

Schritt 5: Reverse Proxy einrichten

Legen Sie im Nginx Proxy Manager einen Proxy Host an: Domain termine.ihre-domain.de, Schema http, Ziel die NAS-Adresse bzw. bei gleichem Host-Netz 127.0.0.1, Port 3000, und fordern Sie im Reiter SSL ein Let's-Encrypt-Zertifikat an. Alternativ nutzen Sie den Reverse Proxy in DSM unter Systemsteuerung > Anmeldeportal > Erweitert.

Die Domain muss exakt zu NEXT_PUBLIC_WEBAPP_URL passen. Andernfalls zeigen Links in Mails und Weiterleitungen nach der Anmeldung auf eine falsche Adresse.

Verifizieren: https://termine.ihre-domain.de öffnet Cal.com mit gültigem Zertifikat.

Schritt 6: Erstes Konto im Setup-Assistenten anlegen

Laut README startet beim ersten Aufruf ein Setup-Assistent, in dem Sie den ersten Benutzer festlegen. Rufen Sie die Domain direkt nach dem Start auf, damit niemand anderes zuvorkommt. Tragen Sie Name, Benutzername, E-Mail-Adresse und ein starkes Passwort ein. Der Benutzername bestimmt die öffentliche Adresse https://termine.ihre-domain.de/BENUTZERNAME. Bietet der Assistent im Kalenderschritt keine Möglichkeit zum Überspringen, rufen Sie laut README die Adresse Ihrer Instanz mit dem Pfad zum Dashboard direkt auf.

Legen Sie danach unter Verfügbarkeit Ihre Arbeitszeiten fest und unter Ereignistypen mindestens einen Termin, zum Beispiel „Erstgespräch, 30 Minuten“.

Verifizieren: Sie sind angemeldet, und die öffentliche Seite /BENUTZERNAME zeigt Ihren Ereignistyp mit freien Zeiten in einem privaten Browserfenster.

Schritt 7: Kalender verbinden und Testbuchung durchführen

Damit Cal.com belegte Zeiten kennt, verbinden Sie einen Kalender über die Apps-Übersicht.

CalDAV-Anbindung

Für CalDAV-Server wählen Sie die App „CalDav“ und tragen die CalDAV-Adresse Ihres Kalenders sowie Benutzername und Passwort ein. Die Zugangsdaten speichert Cal.com mit CALENDSO_ENCRYPTION_KEY verschlüsselt; ändern Sie den Schlüssel später, müssen Sie Kalender neu verbinden. Die App-Beschreibung warnt, dass ein langsamer CalDAV-Server die Buchungsseite verlangsamt, und nennt die bestätigten Server.

Google Calendar (optional)

Google Calendar setzt ein OAuth-Projekt in der Google Cloud Console voraus. Die README beschreibt die Schritte; die Zugangsdaten tragen Sie als GOOGLE_API_CREDENTIALS ein, danach wird die App im App Store verfügbar.

Testbuchung durchführen

Buchen Sie in einem privaten Browserfenster einen Termin auf Ihrer öffentlichen Seite.

Verifizieren: Die Buchung erscheint unter Buchungen, die Bestätigungsmail kommt an, und der Termin steht im verbundenen Kalender.

Troubleshooting / Typische Fehler

  • Weiterleitung auf localhost:3000: NEXT_PUBLIC_WEBAPP_URL fehlt oder passt nicht zur Domain. Wert korrigieren, Projekt neu erstellen.
  • CLIENT_FETCH_ERROR im Log: Der Container kann die eigene Domain intern nicht auflösen. Die README empfiehlt NEXTAUTH_URL=http://localhost:3000/api/auth.
  • Container hängt beim Warten auf die Datenbank: DATABASE_HOST fehlt oder lautet nicht database:5432.
  • „password authentication failed“: Passwort in DATABASE_URL weicht von POSTGRES_PASSWORD ab, oder der Datenordner stammt aus einem früheren Versuch mit anderem Passwort.
  • Kalender lässt sich nach Neuinstallation nicht mehr lesen: CALENDSO_ENCRYPTION_KEY wurde geändert. Alten Wert wiederherstellen oder Kalender neu verbinden.
  • Keine Mails: SMTP-Werte prüfen; Port 587 mit STARTTLS oder 465 mit TLS je nach Anbieter.
  • Image startet nicht auf ARM-NAS: Tag v6.2.0 gibt es nur für amd64, nutzen Sie v6.2.0-arm.
  • Prisma Studio auf Port 5555 erreichbar: Dienst aus der Compose-Datei entfernen.

Häufige Fragen

Geht es ohne eigene Domain?

Für den Test im LAN ja, mit NEXT_PUBLIC_WEBAPP_URL=http://NAS-IP:3000 und offener Portbindung. Für Kundenbuchungen brauchen Sie eine öffentliche HTTPS-Adresse, damit Links in Mails funktionieren; eine Synology-DDNS-Adresse mit Zertifikat reicht dafür.

Wie aktualisieren Sie Cal.com?

Für calcom/cal.com ist v6.2.0 der letzte Tag. Neuere Versionen von Cal.diy müssten Sie aus dem Quellcode bauen. Prüfen Sie vor einer solchen Entscheidung auf Docker Hub, ob inzwischen fertige Images für calcom/cal.diy vorliegen, und sichern Sie vorher die Datenbank.

Wie verbinden Sie Google Calendar?

Über ein eigenes OAuth-Projekt in der Google Cloud Console und GOOGLE_API_CREDENTIALS, siehe Schritt 7.

Ist das für den Firmeneinsatz geeignet?

Nach Aussage des Herstellers ist die selbst gehostete Community-Edition für den persönlichen, nicht produktiven Einsatz gedacht. Teams, Organisationen, Workflows und SSO hat Cal.diy entfernt. Für Kundentermine im Unternehmen wägen Sie deshalb ab: Testbetrieb und Einzelpersonen ja, geschäftskritische Terminvergabe besser mit gepflegtem Angebot und Support.

Wie sichern Sie die Buchungsdaten?

Alle Konten, Buchungen und Kalenderverbindungen liegen in PostgreSQL. Sichern Sie per SSH mit einem Dump und lassen Sie Hyper Backup den Ordner backup extern kopieren; legen Sie den Ordner vorher an:

sudo docker exec calcom-db pg_dump -U calcom -Fc calcom > /volume1/docker/calcom/backup/calcom_$(date +%Y%m%d).dump

Bewahren Sie die beiden Schlüssel aus Schritt 2 getrennt auf; ohne CALENDSO_ENCRYPTION_KEY sind gespeicherte Kalender-Zugangsdaten nach einer Wiederherstellung nicht lesbar.

Welche CalDAV-Adresse tragen Sie ein?

Die Adresse Ihres Kalenders auf dem CalDAV-Server, nicht eine Adresse von Cal.com. Bei Synology Calendar zeigt die Kalenderanwendung die CalDAV-Adresse in den Einstellungen des jeweiligen Kalenders.

Fazit

Mit dem Image v6.2.0 und PostgreSQL läuft Cal.com auf einem Synology NAS als schlankes Zwei-Container-Projekt. Entscheidend sind die richtig erzeugten Schlüssel, die exakte öffentliche Adresse und ein Datenbank-Dump. Planen Sie den Einsatz bewusst: Das fertige Image erhält keine neuen Versionen mehr, und der Hersteller empfiehlt die selbst gehostete Community-Edition nur für den persönlichen Gebrauch. Für Zeiterfassung im selben Umfeld eignet sich Kimai auf dem Synology NAS.

Weiterführende Anleitungen und Quellen