Cal.com selbst hosten 2026: Was nach dem Wechsel zu Closed Source noch geht und welche Alternativen tragen

• Cal.com ist seit April 2026 Closed Source, offen ist nur noch Cal.diy
• Anleitungen mit fertigem Cal.com-Image beschreiben den Stand vom März 2026
• Cal.diy hat keine Teams, Organisationen, Workflows und Routing Forms mehr
• Tymeslot, Calnode und Easy!Appointments bringen Buchungsseite, Kalenderabgleich und Absage durch den Gast mit
• Rallly, alf.io, LibreBooking und Thunderbird Appointment taugen nicht als Ersatz für Cal.com
• Für eine Person oder einen Betrieb reicht eine eigene Instanz, für viele Kunden braucht es Mehrmandanten
• Calnode braucht im Test 85 MB Arbeitsspeicher und lädt auf der Buchungsseite nichts von Dritten
• CalDAV mit App-Passwort erspart die OAuth-Prüfung von Google
• Manche Hoster sperren ausgehendes SMTP, dann geht Mail nur über eine HTTPS-Schnittstelle
• Offene Fragen: Admin-Verwaltung von Cal.diy, Build-Variablen und ungeprüfte Drittanfragen
• Quellen

Cal.com lässt sich im Oktober 2026 nur noch eingeschränkt selbst hosten. Der Hersteller hat den Produktionscode im April 2026 geschlossen. Offen geblieben ist ein abgespeckter Ableger namens Cal.diy, für den es kein aktuelles fertiges Image gibt und von dessen Produktivbetrieb der Hersteller selbst abrät. Für eine Terminbuchung ohne Abo und ohne Daten bei Dritten kommen vor allem Tymeslot, Calnode und Easy!Appointments infrage. Welches davon passt, hängt an einer Frage: eine Instanz je Person oder Betrieb, oder eine Instanz für viele.

Stand aller Angaben: 13.10.2026. Grundlage sind GitHub- und Docker-Hub-API, eine Durchsicht des Quellcodes und ein lokaler Test von Calnode. Die übrigen Kandidaten wurden nicht live installiert.

§Cal.com ist seit April 2026 Closed Source, offen ist nur noch Cal.diy

Am 14.04.2026 kündigte Cal.com die Umstellung auf geschlossenen Quellcode an. Als Grund nennt der Beitrag Sicherheitsrisiken durch KI-gestützte Schwachstellensuche [1]. Einen Tag später wurde das Repository calcom/cal.com in calcom/cal.diy umbenannt. Der Umstellungs-Commit löschte rund 412.000 Zeilen in 4.080 Dateien [2][3]. Wer heute github.com/calcom/cal.com aufruft, landet bei Cal.diy.

Seitdem gelten zwei Lizenzen nebeneinander. Auf dem Zweig main steht Cal.diy vollständig unter MIT, keine Funktion braucht mehr einen Lizenzschlüssel [4]. Die letzte veröffentlichte Version ist aber v6.2.0 vom 01.03.2026. Sie steht unter AGPLv3, ihre ee-Ordner (Teams, Organisationen, Workflows, SSO und weitere) unter einer kommerziellen Lizenz, die den Produktivbetrieb ohne Enterprise-Abo untersagt [5]. MIT bekommt also nur, wer selbst aus main baut. Einen neuen Versionstag gab es seit der Umstellung nicht.

README und Dokumentation empfehlen Cal.diy „strictly … for personal, non-production use“ und verweisen für kommerziellen Einsatz auf Cal.com. Cal.com übernimmt nach eigener Aussage keine Gewähr für die Sicherheit des offenen Projekts [6]. Eine Lizenzbedingung ist das nicht: Der MIT-Text erlaubt Nutzung, Veränderung und Verkauf, solange Copyright- und Lizenzhinweis erhalten bleiben [4]. Gepflegt wird Cal.diy laut Hersteller von ehemaligen Praktikanten [2]. Auf main landeten im April 39 Commits, im September 14, im Oktober bis zum 13. keiner.

§Anleitungen mit fertigem Cal.com-Image beschreiben den Stand vom März 2026

Wer einer älteren Anleitung folgt und calcom/cal.com von Docker Hub zieht, bekommt v6.2.0 vom 02.03.2026, also den AGPL-Stand mit kommerziellem EE-Teil (5,1 Millionen Abrufe). Das Nachfolge-Image calcom/cal.diy, auf das README und Doku verweisen, hatte am 13.10.2026 null Tags und null Abrufe [7]. Das frühere Repository calcom/docker ist seit dem 29.10.2025 archiviert [8].

Laut Issue #28995, offen seit dem 24.04.2026, ist der Fehler im Bau-Ablauf behoben; es fehlt ein neuer Tag, den niemand mit den nötigen Rechten setzt. Die letzten acht Release-Läufe (12. bis 26.09.2026) schlugen fehl [9]. Ein Nutzer dokumentierte am 30.09.2026 den Bau aus dem Quellcode: rund 36 Minuten, in der Spitze etwa 6,5 GB Arbeitsspeicher auf einer VM mit 2 vCPU und 8 GB [9]. Zum Betrieb nennt die Doku PostgreSQL ab Version 13, dazu Redis, und „Ideally, 2 vCPUs and 2-4GB RAM“ [6].

§Cal.diy hat keine Teams, Organisationen, Workflows und Routing Forms mehr

Die Funktionen wurden aus Cal.diy entfernt, nicht nur gesperrt. Laut Hersteller fehlen Organisationen und Teams mit Team-Buchung, Round-Robin und rollenbasierten Rechten, außerdem Routing Forms, Workflows, Instant Booking, Cal.ai Phone, Attribute und Segmente, SAML/SSO, Insights, API v1, Booking Audit und Impersonation [2]. Die Doku-Tabelle nennt zusätzlich Managed Event Types, SCIM und Videoaufzeichnungen [6].

Erhalten bleiben unabhängige Einzelkonten mit eigenen Buchungsseiten unter /<benutzername>/<termin>. Die offene Registrierung lässt sich abschalten, Markenfarbe und Theme sind je Konto einstellbar, und auf eigener Domain darf jedes Konto den Hinweis „Powered by“ ausblenden. Ein eigenes Logo je Konto wurde im Code nicht gefunden [10].

Eine Anfrage an Dritte bleibt auch auf main: Ohne Profilbild lädt Cal.diy einen Platzhalter von eu.ui-avatars.com, mit dem Namen des Kontos in der Adresse. Eine Variable zum Abschalten wurde nicht gefunden [10]. Telemetrie, Sentry und weitere Dienste sind auf main ohne gesetzte Schlüssel inaktiv. Für v6.2.0, das einzige fertige Image, ist das nicht geprüft.

„Cal.diy“ und „Cal“ sind eingetragene Marken von Cal.com, Inc. Eine veröffentlichte Markenrichtlinie wurde nicht gefunden. Der angezeigte Name einer Instanz lässt sich über NEXT_PUBLIC_APP_NAME ändern [10].

§Tymeslot, Calnode und Easy!Appointments bringen Buchungsseite, Kalenderabgleich und Absage durch den Gast mit

Quellen der Tabelle: [11][12][13].

Tymeslot ist in Elixir geschrieben und läuft als ein Container mit eingebautem PostgreSQL, laut Doku ab „500MB RAM minimum (1GB recommended)“. Oberfläche, Buchungsseite und Mails gibt es auf Deutsch. Ohne gesetzte Schlüssel fand die Code-Durchsicht keinen Aufruf externer Dienste. Von rund 5.000 Commits stammen fast alle von einer Person, und TRADEMARK.md schließt aus, ein eigenes Angebot unter dem Namen Tymeslot zu betreiben. Eine Falle bei der Einrichtung: Die Vorgabe EMAIL_ADAPTER=test verwirft alle Mails [11].

Calnode ist in Go geschrieben, speichert in SQLite und trennt Kunden über je eine eigene Instanz („instance-per-tenant“). Mehrere Domains in einer Instanz stehen erst auf der Roadmap. Die Buchungsseiten sind maschinell ins Deutsche übersetzt, die Verwaltung gibt es nur auf Englisch. Calnode ist das jüngste Projekt im Vergleich; 559 Commits stammen von einer Person [12].

Easy!Appointments ist das älteste, in PHP geschrieben, mit offiziellem Image (134.877 Abrufe). Es kennt mehrere Anbieter mit eigenen Leistungen, aber nur einen Markenauftritt je Instanz, passt also zu einem Betrieb mit mehreren Mitarbeitenden. Fremde Webseiten können die Buchung ohne Code-Änderung nicht einbetten; wie das vorhandene WordPress-Plugin das löst, ist nicht geprüft. Die Admin-Seite „About“ lädt serverseitig einen Feed von easyappointments.org, und acht von zehn mitgelieferten Themes laden Google Fonts [13].

§Rallly, alf.io, LibreBooking und Thunderbird Appointment taugen nicht als Ersatz für Cal.com

Rallly stimmt Termine per Gruppenumfrage ab, alf.io verkauft Tickets, LibreBooking bucht Räume und Geräte. Thunderbird Appointment (MPL-2.0) hat Buchungsseiten je Nutzer, aber kein fertiges Image, braucht fünf Container mit PostgreSQL, Redis und Celery, und eine Einbettung wurde im Frontend nicht gefunden. Die Termin-Funktion von Nextcloud Calendar setzt eine Nextcloud voraus, Gäste können dort nicht selbst absagen. calit gleicht nur mit Google ab, DayOtter nennt sich selbst „not yet battle-tested“ [14].

§Für eine Person oder einen Betrieb reicht eine eigene Instanz, für viele Kunden braucht es Mehrmandanten

Mehrmandanten heißt: eine Instanz für viele Kunden. Wer sie betreibt, hält die Termine und Kundendaten aller Beteiligten auf einem Server. Eine Instanz je Person oder Betrieb trennt diese Daten von vornherein und kostet je Kunde einen Container, was nur bei geringem Speicherbedarf günstig bleibt.

§Calnode braucht im Test 85 MB Arbeitsspeicher und lädt auf der Buchungsseite nichts von Dritten

Getestet wurde Calnode v0.10.1 am 13.10.2026 lokal in Docker, der Netzverkehr wurde mit den Chrome DevTools mitgeschnitten. Das Image ist 64 MB groß. Im Leerlauf belegte der Container 11 MB Arbeitsspeicher, nach Einrichtung und mehreren Seitenaufrufen 85 MB. Zum Vergleich die Herstellerangaben, nicht gemessen: Tymeslot nennt 500 MB als Minimum, Cal.diy 2 bis 4 GB.

Die Buchungsseite /book/<slug> lud nur eigenes CSS, die eigene Schnittstelle für freie Zeiten und das Favicon, keine einzige Anfrage ging an Dritte. Die Verwaltung unter /admin lud als einzige Fremdquelle Google Fonts (Poppins). Eingebettet wird über embed.js als Web Component im Shadow DOM (<calnode-booking slug="…"> oder als Popup-Knopf). Die Buchungsseite selbst verbietet Rahmen per frame-ancestors 'none', ein iframe funktioniert also nicht.

Nicht getestet wurden in diesem Durchlauf der CalDAV-Abgleich, der Mailversand und eine echte Buchung. Die Werte stammen aus einem einzelnen Durchlauf auf einem Rechner.

Offenlegung: Die Terminbuchung dieser Webseite läuft seit dem 13.10.2026 auf einer eigenen Calnode-Instanz unter termine.stevennoack.de. Dort gingen Bestätigung und Absage einer Testbuchung über die Resend-API zu.

§CalDAV mit App-Passwort erspart die OAuth-Prüfung von Google

Für den Google-Kalender braucht jede selbst gehostete Instanz eine eigene OAuth-App. Kalenderereignisse zu lesen gilt bei Google als „sensitive scope“, die Freigabe verlangt eine Prüfung mit Begründung je Berechtigung und ein Demo-Video [15]. Eine ungeprüfte App zeigt Nutzern einen Warnbildschirm und ist auf 100 neue Nutzer begrenzt [16]. Im Status „Testing“ verfallen die Refresh-Token nach sieben Tagen [17].

CalDAV mit einem App-Passwort kommt ohne OAuth aus. Alle drei empfohlenen Alternativen unterstützen es. Ob iCloud und Nextcloud die CalDAV-Abfrage für freie und belegte Zeiten (RFC 4791, Abschnitt 7.10) beantworten, ist nicht geprüft; Easy!Appointments liest stattdessen die Ereignisse im Zeitraum [13][18].

§Manche Hoster sperren ausgehendes SMTP, dann geht Mail nur über eine HTTPS-Schnittstelle

Ohne Mail gibt es keine Buchungsbestätigung. Manche Hoster blockieren ausgehendes SMTP ganz oder auf einzelnen Ports. Auf Hetzner-Cloud-Servern waren in zwei Praxisfällen (29.08. und 13.10.2026) ausgehend die Ports 25 und 465 gesperrt. Der E-Mail-Versand von Cloudflare nimmt SMTP auf smtp.mx.cloudflare.net über Port 465 an; diese Kombination stellt keine Mail zu. Eine offizielle Aussage von Hetzner dazu wurde nicht geprüft.

Die Calnode-Doku beschreibt das Muster allgemein: Railway sperrt SMTP unterhalb des Pro-Tarifs, indem es die Pakete verwirft. Im Container sieht das zuerst wie ein Hänger aus, dann wie ein falsches Passwort, auf den Ports 25, 465, 587 und 2525 gleich [12]. Keine SMTP-Einstellung hilft dagegen, wohl aber Versand über eine HTTPS-Schnittstelle auf Port 443: Calnode und Cal.diy können Mails über die API von Resend schicken [10][12]. Teils hilft ein Ausweich-Port; Resend über Port 2465 kam am 29.08.2026 von einem Hetzner-Server an. Easy!Appointments kennt nur SMTP. Ob die Tymeslot-Adapter für Postmark, SendGrid, Mailgun und AhaSend über HTTPS senden, ist nicht geprüft.

§Offene Fragen: Admin-Verwaltung von Cal.diy, Build-Variablen und ungeprüfte Drittanfragen

Ob Cal.diy eine Benutzerverwaltung für Admins hat, ist widersprüchlich. Die Doku-Tabelle sagt „Admin Panel ❌“, im Code auf main sind die Seiten vorhanden. Laut Issue #30013 vom 19.08.2026 sieht der Admin in v6.2.0 nicht einmal, wer sich registriert hat; behoben ist das nur auf main [19].

Ob NEXT_PUBLIC_WEBAPP_URL beim Bau feststeht, ist ebenfalls widersprüchlich: Die Docker-Doku verlangt dafür ein eigenes Image, Code und README ersetzen den Wert beim Start, zwei offene Issues melden trotzdem Umleitungen auf localhost [10][20].

Nicht geprüft sind die Drittanfragen von v6.2.0, mögliche weitere Hosts in Hintergrundjobs von Tymeslot und Calnode und der Speicherbedarf von Easy!Appointments. Zu Release-Plänen für Cal.diy haben die Maintainer in den Issues #28995 und #30013 nicht geantwortet [9][19].

§Quellen

Alle Abrufe am 13.10.2026.

• [1] Cal.com Blog, Bailey Pumfleet, 14.04.2026: https://cal.com/blog/cal-com-goes-closed-source-why
• [2] Cal.com Blog, Keith Williams, 15.04.2026: https://cal.com/blog/cal-diy-open-source-to-closed-source
• [3] Umstellungs-Commit, Pull Request #28903: https://github.com/calcom/cal.diy/pull/28903
• [4] Lizenz auf main: https://github.com/calcom/cal.diy/blob/main/LICENSE
• [5] Lizenz v6.2.0: https://github.com/calcom/cal.diy/blob/v6.2.0/LICENSE und https://github.com/calcom/cal.diy/blob/v6.2.0/packages/features/ee/LICENSE
• [6] Cal.diy-Dokumentation und README: https://www.cal.diy/ und https://github.com/calcom/cal.diy/blob/main/README.md
• [7] Docker Hub, Tags von calcom/cal.diy: https://hub.docker.com/v2/repositories/calcom/cal.diy/tags
• [8] Archiviertes Repository: https://github.com/calcom/docker
• [9] Issue #28995 „Docker Image Missing“: https://github.com/calcom/cal.diy/issues/28995
• [10] Cal.diy-Quellcode und Umgebungsvorlage: https://github.com/calcom/cal.diy/blob/main/.env.example
• [11] Tymeslot: https://github.com/Tymeslot/tymeslot und https://hub.docker.com/r/luka1thb/tymeslot
• [12] Calnode, README und DEPLOY.md: https://github.com/Calnode/calnode
• [13] Easy!Appointments: https://github.com/alextselegidis/easyappointments und https://hub.docker.com/r/alextselegidis/easyappointments
• [14] Rallly https://github.com/lukevella/rallly, alf.io https://github.com/alfio-event/alf.io, LibreBooking https://github.com/LibreBooking/librebooking, Thunderbird Appointment https://github.com/thunderbird/appointment, Nextcloud Calendar https://docs.nextcloud.com/server/latest/user_manual/en/groupware/calendar.html, calit https://github.com/asm0dey/calit, DayOtter https://github.com/Dayotter/dayotter
• [15] Google, Prüfung sensibler Berechtigungen: https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification
• [16] Google, ungeprüfte Apps: https://support.google.com/cloud/answer/7454865
• [17] Google, OAuth 2.0: https://developers.google.com/identity/protocols/oauth2
• [18] RFC 4791, Abschnitt 7.10: https://www.rfc-editor.org/rfc/rfc4791.html
• [19] Issue #30013: https://github.com/calcom/cal.diy/issues/30013
• [20] Issues #28172 und #28712: https://github.com/calcom/cal.diy/issues/28172 und https://github.com/calcom/cal.diy/issues/28712

Die Messwerte zu Calnode und die Befunde zum Mailversand auf Hetzner stammen aus Praxistests vom 29.08. und 13.10.2026, die nicht gesondert veröffentlicht sind.