Cal.diy: Der reine MIT-Fork von Cal.com für Selbsthoster
cal.diy bündelt die Planungsschnittstelle und Kalenderintegrationen von Cal.com für persönliches, nicht produktives Selbsthosting.
Auf einen Blick
- Was ist das?
- Was die Community-Edition gegenüber Cal.com weglässt, welche Befehle und Schlüssel das Setup braucht und für wen der Verzicht auf Enterprise-Funktionen zum Problem wird.
- Für wen ist es gedacht?
- Cal.diy passt für Einzelne, die ihre Terminbuchung selbst betreiben wollen und Teams, SSO/SAML oder Workflows nicht benötigen. Für kommerzielle oder unternehmenskritische Infrastruktur empfiehlt die README ausdrücklich Cal.com statt Cal.diy, und wer keine Serververwaltung, PostgreSQL-Pflege und Schlüsselverwaltung übernehmen will, sollte ebenfalls dort bleiben.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 16. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Cal.diy als Fork von Cal.com: MIT statt Open Core
Cal.diy versteht sich als community-getriebene, vollständig quelloffene Scheduling-Plattform und ist ein Fork von Cal.com, bei dem sämtlicher Enterprise- und kommerzieller Code entfernt wurde. Die README betont die 100-prozentige MIT-Lizenz ohne Open-Core-Aufteilung und ohne proprietäre Enterprise-Edition. Es gibt keinen Lizenzschlüssel, nichts braucht ein Cal.com-Konto, und es existiert keine gehostete oder verwaltete Variante. Wer Cal.diy nutzt, betreibt die Plattform auf eigener Infrastruktur.
Die Warnung zu Beginn der README ist deutlich: Die Edition ist ausdrücklich für den persönlichen, nicht-produktiven Gebrauch empfohlen, Selbsthosting verlangt fortgeschrittene Kenntnisse in Serververwaltung, Datenbankverwaltung und im Schutz sensibler Daten. Für kommerzielle und unternehmensreife Termin-Infrastruktur verweist das Projekt auf Cal.com selbst. Mit rund 48.000 Sternen und knapp 15.000 Forks ist das Repository dennoch eines der größten seiner Art, die Projektsprache ist TypeScript.
Teams, Organizations, SSO/SAML: Was Cal.diy gegenüber Cal.com weglässt
Die Unterschiede sind konkreter Natur: Teams, Organizations, Insights, Workflows und SSO/SAML sind entfernte, rein enterprise-behaftete Funktionen und stehen in Cal.diy nicht zur Verfügung. Beiträge von der Community fließen laut CONTRIBUTING.md direkt in dieses Repository, nicht in die Produktionsplattform von Cal.com. Das ist der Kern der Differenz: gleiche Scheduling-Basis, abgeschnittener Funktionsumfang, dafür lizenzfreier Betrieb.
Für eine konkrete Alternative ergibt sich damit eine klare Entscheidungslinie. Wer SSO/SAML für eine Organisation braucht, greift zu Cal.com, das diese Funktionen bereitstellt und von den Betreibern gehostet wird. Wer sie nicht braucht und lieber Kontrolle über Daten und Deployment behält, nutzt Cal.diy und akzeptiert, dass etwa Workflow-Automatisierungen fehlen. Eine mittlere Option gibt es nicht, der Fork enthält bewusst kein Teil der EE-Features.
NEXTAUTH_SECRET und CALENDSO_ENCRYPTION_KEY: Cal.diy mit Yarn aufsetzen
Die Voraussetzungen aus der README: Node.js ab Version 18, PostgreSQL ab Version 13, Yarn als Paketmanager. Der manuelle Weg beginnt mit git clone https://github.com/calcom/cal.diy.git, dann yarn für die Installation. Aus .env.example wird .env, darin landen zwei generierte Schlüssel: NEXTAUTH_SECRET über openssl rand -base64 32 und CALENDSO_ENCRYPTION_KEY über openssl rand -base64 24. Der zweite Schlüssel verschlüsselt Zugangsdaten von Kalender-Integrationen, sein Verlust macht gespeicherte Credentials unlesbar.
Stimmt die Node-Version nicht, regelt nvm use beziehungsweise nvm install && nvm use die passende Version. Windows-Nutzer müssen zwei Besonderheiten kennen: git clone -c core.symlinks=true mit Admin-Rechten in Git Bash, und der Symlink packages/prisma/.env wird durch eine echte Kopie ersetzt, sonst wirft Prisma den Fehler unexpected character / in variable name. Für die Datenbank-Migrationen nennt die README yarn workspace @calcom/prisma db-migrate in der Entwicklung und db-deploy für Produktion. Einen ersten Benutzer legt man über Prisma Studio oder ein Seed-Skript an.
yarn dx und db-studio: Testbenutzer der Cal.diy-Entwicklungsumgebung
Der schnellere Weg läuft über yarn dx und setzt Docker samt Docker Compose voraus. Der Befehl startet eine lokale Postgres-Instanz samt Web-App und legt Testbenutzer an, deren Zugangsdaten in der Konsole geloggt werden: free@example.com mit Passwort free, pro@example.com mit pro, trial@example.com mit trial und admin@example.com mit ADMINadmin2022!. Der Login erfolgt danach auf localhost:3000. Die vollständige Liste der Seed-Benutzer zeigt yarn db-studio unter Port 5555.
Zwei Tipps aus der README erleichtern den Alltag. Für größere Builds hebt export NODE_OPTIONS="--max-old-space-size=16384" das Speicherlimit des Node-Prozesses an. Das Log-Aufkommen von tRPC-Queries und -Mutations steuert NEXT_PUBLIC_LOGGER_LEVEL in der .env-Datei, die Stufen reichen von 0 (silly) bis 6 (fatal), wobei der gesetzte Level und alle höheren ausgegeben werden. NEXT_PUBLIC_LOGGER_LEVEL=3 etwa bedeutet, dass ab info geloggt wird und trace sowie debug stumm bleiben.
calcom/cal.diy auf Docker Hub: Deployment mit DATABASE_URL
Für das Deployment steht das vorgebaute Image calcom/cal.diy auf Docker Hub bereit, alternativ baut man das Image selbst aus dem Quellcode. Ein Compose-Stack kann eine lokale Postgres-Datenbank, die Web-App und Prisma Studio umfassen. Zur Laufzeit gehören DATABASE_URL, NEXTAUTH_SECRET und CALENDSO_ENCRYPTION_KEY zu den zwingenden Umgebungsvariablen, und die README warnt davor, Standardwerte für Geheimnisse in Produktion zu belassen.
Wer selbst baut, setzt zusätzlich Build-Zeit-Variablen wie MAX_OLD_SPACE_SIZE und NEXT_PUBLIC_WEBAPP_URL. Beim ersten Start erscheint ein Einrichtungsassistent, über den der erste Benutzer definiert wird. Dass es keine gehostete Variante gibt, ist hier die tragende Voraussetzung: Backups, Updates und Absicherung der PostgreSQL-Instanz liegen vollständig beim Betreiber. Der Fork liefert das Image, aber kein operationelles Sicherheitsnetz, und die README räumt genau diese Verantwortung explizit ein.
Google Calendar, Zoom, Pipedrive: Integrationen in Cal.diy einrichten
Für jede Integration verlangt Cal.diy eigene Credentials, die README führt Schritt für Schritt durch die Beschaffung. Die Liste umfasst Google Calendar, Microsoft Graph, Zoom, Daily.co, Basecamp, HubSpot, Webex, ZohoCRM, Zoho Calendar, Zoho Bigin und Pipedrive. Video-Konferenzen laufen dabei über Daily.co, das im Stack als Built-with-Baustein auftaucht. Optional lässt sich ein Rate-Limiting mit Unkey einrichten, um Missbrauch der Instanz einzudämmen.
Der Beitragsweg ist im CONTRIBUTING.md beschrieben, Hilfe wird bei Code, Dokumentation und Übersetzungen angenommen, und für Einsteiger existiert eine Liste mit als Help wanted markierten Issues. Die Versionslinie zeigt regelmäßige Pflege, zuletzt erschien Release v6.2.0 im März 2026, davor v6.1.16 und v6.1.15 im Februar. Die MIT-Lizenz liefert die Software ohne Gewährleistung, wie besehen, was bei einem für den persönlichen Betrieb empfohlenen Fork die erwartete Haltung ist.
Redaktionelles Fazit
Cal.diy passt für Einzelne, die ihre Terminbuchung selbst betreiben wollen und Teams, SSO/SAML oder Workflows nicht benötigen. Für kommerzielle oder unternehmenskritische Infrastruktur empfiehlt die README ausdrücklich Cal.com statt Cal.diy, und wer keine Serververwaltung, PostgreSQL-Pflege und Schlüsselverwaltung übernehmen will, sollte ebenfalls dort bleiben. Vor dem Einsatz lohnt ein Probelauf mit yarn dx in Docker und ein Abgleich der .env-Variablen wie DATABASE_URL und CALENDSO_ENCRYPTION_KEY gegen die eigene Infrastruktur.
Community-Notizen