Calendly-Alternativen selbst hosten: Vergleich

Die kurze Antwort

Eine selbst gehostete Calendly-Alternative muss eine Aufgabe erfüllen, die interne Tools auf Ihrem VPS nie erfüllen: Sie muss öffentlich erreichbar sein. Die Buchungsseite ist das Produkt. Sie benötigt von Anfang an einen echten Domainnamen und TLS (Transport Layer Security). Außerdem muss sie E-Mails an Personen zustellen können, die noch nie von Ihrem Server gehört haben.

Vier Projekte decken die realistischen Optionen ab. Cal.com ist Calendly am ähnlichsten und die Standardempfehlung für Einzelberater. Easy!Appointments ist die schlanke Lösung auf Basis von PHP und MySQL und läuft problemlos auf einem VPS mit 1 GB. Rallly ist ein Tool für Gruppenabstimmungen und hat überhaupt keine Buchungsseite. DayOtter ist der neueste Anbieter. Dabei handelt es sich um eine AGPLv3-Terminplanungsplattform mit einem Assistenten davor, der zuerst eine Bestätigung anfordert.

Zwei Fragen entscheiden darüber, welche Lösung Sie tatsächlich betreiben können. Synchronisiert sie in beide Richtungen mit dem Kalender, den Sie bereits verwenden? Und kann sie E-Mails versenden? An der zweiten Frage scheitern die meisten selbst gehosteten Buchungslösungen unbemerkt. Deshalb wird sie zuerst behandelt.

Der Versand ausgehender E-Mails ist der fehleranfällige Teil

Eine Buchungsbestätigung landet im Postfach einer fremden Person. Dabei handelt es sich um transaktionale E-Mail, die bei Gmail oder Microsoft 365 zugestellt wird. Diese Empfänger bewerten Sie anhand der sendenden IP-Adresse und Ihrer DNS-Einträge.

Der direkte Versand vom VPS funktioniert fast nie. Die meisten Anbieter blockieren bei neuen Konten den ausgehenden TCP-Port 25. Dadurch hängt die Verbindung und läuft schließlich in einen Timeout. Selbst wenn Port 25 geöffnet ist, hat eine neue VPS-Adresse noch keine Versandhistorie. Große Empfänger stufen unbekannte Adressen aus Hosting-Netzen als verdächtig ein. Die Buchung wird in die Datenbank geschrieben, die Seite zeigt die Bestätigung an, und niemand erhält eine E-Mail. Auf Serverseite sieht nichts fehlerhaft aus. Deshalb wird das Problem häufig erst Wochen später von einem Kunden entdeckt, der nie erschienen ist.

Verwenden Sie ein Relay. Jeder Anbieter für transaktionale E-Mails ist geeignet. Die Anwendung benötigt dafür nur einen Hostnamen, einen Port, einen Benutzer und ein Passwort. Prüfen Sie die Erreichbarkeit des Ports, bevor Sie die Anwendungskonfiguration ändern:

nc -vz -w 5 "$SMTP_HOST" 587

Eine Zeile mit succeeded bedeutet, dass der Pfad geöffnet ist. Bei einem Hänger oder Connection refused ist der Port auf Netzwerkebene blockiert. Keine Änderung an .env kann das beheben. Relays verwenden Port 587 oder 465, weil Port 25 so häufig blockiert wird.

Jedes Projekt bindet das Relay auf eigene Weise ein. Cal.com liest EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER und EMAIL_SERVER_PASSWORD und akzeptiert alternativ auch ein RESEND_API_KEY. Prüfen Sie diesen Wert besonders sorgfältig: Das mitgelieferte .env.example verweist EMAIL_SERVER_HOST auf localhost an Port 1025. Dabei handelt es sich um ein lokales Entwicklungs-Postfach. Wenn Sie den Standardwert beibehalten, sendet die Anwendung ohne Fehlermeldung ins Leere. Rallly verwendet SMTP_HOST, SMTP_PORT, SMTP_USER und SMTP_PWD. DayOtter verwendet SMTP-Einstellungen oder einen Resend-Schlüssel. Easy!Appointments versendet Benachrichtigungen aus der Anwendung. Verweisen Sie die Anwendung daher auf der Einstellungsseite auf dasselbe Relay, bevor Sie eine echte Buchung annehmen.

Veröffentlichen Sie anschließend die DNS-Einträge, die Ihnen das Relay bereitstellt. Ein SPF-Eintrag (Sender Policy Framework) legt fest, welche Server für Ihre Domain senden dürfen. Ein DKIM-Schlüssel (DomainKeys Identified Mail) signiert jede Nachricht, damit der Empfänger prüfen kann, dass sie nicht verändert wurde. Fügen Sie eine DMARC-Richtlinie (Domain-based Message Authentication, Reporting and Conformance) hinzu, sobald beide Prüfungen erfolgreich sind. Senden Sie eine Testbuchung an eine echte Adresse bei einem großen Anbieter. Öffnen Sie die Nachrichten-Header und prüfen Sie, ob die Authentifizierungszeilen pass lauten. Eine Buchungsseite, die keine E-Mails versenden kann, ist schlechter als keine Buchungsseite, weil der Fehler unbemerkt bleibt.

Welche Kalender-Backends synchronisieren wirklich in beide Richtungen

Die Synchronisierung hat zwei Richtungen, und sie können unabhängig voneinander fehlschlagen. Die Leserichtung betrifft die Verfügbarkeit: Die Anwendung muss Ihre bereits belegten Zeitblöcke sehen. Andernfalls vergibt sie einen Termin, den Sie bereits anderweitig belegt haben. Die Schreibrichtung betrifft die Buchung selbst: Der bestätigte Termin muss in dem Kalender erscheinen, den Sie tatsächlich verwenden, nicht nur im Buchungstool.

Google Calendar und Microsoft 365 unterstützen beide Richtungen, allerdings gilt bei einer selbst gehosteten Installation eine Bedingung. Sie müssen den OAuth-Client (Open Authorization) selbst erstellen, weil die Client-ID des gehosteten Produkts nicht im Quellcode enthalten ist. Bei Cal.com ist das GOOGLE_API_CREDENTIALS in .env. Dort wird die JSON-Datei abgelegt, die Sie aus der Google Cloud Console herunterladen. DayOtter verwendet Google- und Microsoft-OAuth-Anmeldedaten auf dieselbe Weise.

Hier treten zwei Probleme auf, die Sie vor dem Start kennen sollten. Erstens muss die registrierte Redirect-URI exakt mit Ihrer öffentlichen URL übereinstimmen, einschließlich Schema und eventuell vorhandenem abschließendem Pfad. Andernfalls bricht Google die Verbindung auf der Einwilligungsseite mit redirect_uri_mismatch ab. Zweitens stellt ein Google-Projekt mit dem Veröffentlichungsstatus Testing Refresh-Tokens aus, die nach sieben Tagen ablaufen. Die Synchronisierung funktioniert eine Woche lang und stoppt dann. Beim nächsten Refresh zeigen die Anwendungslogs invalid_grant. Setzen Sie den Einwilligungsbildschirm auf In production, oder stellen Sie die Verbindung jeden Montag manuell wieder her.

CalDAV (Kalendererweiterungen für WebDAV) ist die offene Option, aber die Unterstützung ist eingeschränkter. Cal.com enthält eine CalDAV-App, die weiterhin als Beta gekennzeichnet ist und unter anderem gegen Baikal, Radicale, Nextcloud und Kerio Connect geprüft wurde. Apple iCloud funktioniert über dieselbe App, benötigt aber ein anwendungsspezifisches Passwort anstelle Ihres Apple-ID-Passworts. DayOtter führt Apple neben Google und Microsoft 365 über CalDAV auf.

Ein ICS-Feed ist keine Synchronisierung. Eine abonnierte .ics-URL ist absichtlich schreibgeschützt. Sie kann daher auf Ihrer Buchungsseite belegte Zeiten anzeigen, aber niemals die Buchung empfangen. Wenn ein Tool für Ihren Kalender nur ICS anbietet, ist die Integration nur zur Hälfte vorhanden. Sie müssen die Termine weiterhin manuell kopieren.

Easy!Appointments synchronisiert nur Google Calendar. Rallly liest die Verfügbarkeit überhaupt nicht aus. Es sammelt Stimmen zu einer Reihe möglicher Termine. Das ist das richtige Tool für die Frage „Wann können wir uns zu sechst treffen?“ und das falsche Tool für „Buchen Sie 30 Minuten mit mir“.

Eine Buchungsseite ist öffentlich, daher hat TLS Priorität

Die meisten selbst gehosteten Dienste sind privat. Ein Wiki, ein Board oder ein Dashboard kann hinter einem VPN oder einer SSO-Anmeldung betrieben werden und muss nie aus dem offenen Internet erreichbar sein. Das gilt nicht für einen Buchungslink. Jede Person, der Sie den Link senden, muss ihn aufrufen können. Dadurch ändert sich die Einrichtung in drei konkreten Punkten.

Sie benötigen einen Domainnamen mit einem auf die VPS-IP-Adresse zeigenden A-Record, bevor Sie etwas installieren. Sie benötigen vom ersten Tag an ein Zertifikat, weil Browser ein reines HTTP-Formular als nicht sicher markieren und Ihre Kunden darin ihren Namen und ihre E-Mail-Adresse eingeben. Außerdem müssen Sie die öffentliche URL der Anwendung in ihrer Konfiguration korrekt setzen. Dieser Wert wird in die Links ausgehender E-Mails und in die OAuth-Redirect-URIs übernommen. Setzen Sie NEXT_PUBLIC_WEBAPP_URL in Cal.com, DOMAIN in Rallly, BASE_URL in Easy!Appointments oder DAYOTTER_DOMAIN während der Installation und verwenden Sie dafür die https://-Adresse, die Sie tatsächlich nutzen werden.

Rallly und DayOtter übernehmen die TLS-Konfiguration für Sie. Der mitgelieferte Stack von Rallly enthält Traefik und stellt mithilfe der Adresse in ACME_EMAIL Let's-Encrypt-Zertifikate aus. Der Installer von DayOtter startet Caddy mit automatischem HTTPS. Cal.com und Easy!Appointments tun das nicht. Daher schalten Sie nginx davor und stellen das Zertifikat selbst aus, genauso wie bei einem Let's-Encrypt-Zertifikat für nginx mit Certbot. Binden Sie den Anwendungskontainer an 127.0.0.1, damit der einzige Zugriffsweg über den von Ihnen kontrollierten Proxy führt. Wenn auf demselben System bereits eine selbst gehostete Trello-Alternative für Ihre internen Boards läuft, lassen Sie diesen Dienst hinter Ihrer bestehenden Authentifizierung und geben Sie nur dem Buchungs-Host einen öffentlichen Server-Block.

Cal.com auf Ihrem VPS

Die Docker-Konfiguration liegt in einem eigenen Repository, und die Images sind auf Docker Hub bereits erstellt. Sie rufen sie daher ab, statt sie zu erstellen.

git clone --recursive https://github.com/calcom/cal.diy.git
cd cal.diy
cp .env.example .env
openssl rand -base64 32
openssl rand -base64 24
docker compose pull
docker compose up -d

Der erste Zufallswert kommt in NEXTAUTH_SECRET und der zweite in CALENDSO_ENCRYPTION_KEY. Beide sind erforderlich. Setzen Sie DATABASE_URL und verweisen Sie mit NEXT_PUBLIC_WEBAPP_URL auf Ihre öffentliche Adresse. Der enthaltene Stack besteht aus der Webanwendung, PostgreSQL und Prisma Studio. Die Dokumentation nennt docker compose up -d calcom für den Betrieb der Anwendung allein mit einer Datenbank, die Sie an anderer Stelle hosten. Das ist geeignet, sobald die Installation abgeschlossen ist.

Rufen Sie das Image ab. Erstellen Sie es nicht auf dem VPS. Die Anweisungen des Projekts verlangen beim Erstellen aus dem Quellcode, dass Sie NODE_OPTIONS="--max-old-space-size=16384" exportieren. Das entspricht allein für Node einem 16-GB-Heap. Fügen Sie auf ARM-Hardware das Suffix -arm an den Image-Tag an. Das Projekt nennt keine Mindestanforderungen für den Betrieb des vorgefertigten Images. Betrachten Sie daher 2 GB für die Anwendung und PostgreSQL als eigenen Richtwert und nicht als dokumentierte Anforderung. Überwachen Sie den Speicherverbrauch in der ersten Woche.

Prüfen Sie, ob der Dienst gestartet ist:

docker compose ps
docker compose logs -f calcom
curl -sI https://cal.example.com | head -n 1

curl sollte HTTP/2 200 ausgeben. Ein 502 Bad Gateway von nginx, während der Container als aktiv angezeigt wird, bedeutet normalerweise, dass der erste Start noch Datenbankmigrationen ausführt. Warten Sie einige Minuten und lesen Sie die Logs, bevor Sie von einem Fehler ausgehen. Die Webhooks von Cal.com werden bei jeder bestätigten Buchung ausgelöst. Eine Buchung kann daher jede bereits vorhandene Automatisierung anstoßen, beispielsweise eine über HTTPS auf Ihrem VPS erreichbare n8n-Instanz.

Der Kern steht unter AGPLv3. Einige Funktionen liegen jedoch in einem Enterprise-Verzeichnis und unter einer separaten kommerziellen Lizenz. Lesen Sie diese Lizenz, bevor Sie auf den Team-Funktionen einen kostenpflichtigen Geschäftsprozess aufbauen.

Easy!Appointments auf einem System mit 1 GB

Voraussetzungen sind Apache oder Nginx, PHP 8.2 oder neuer sowie MySQL. Unter alextselegidis/easyappointments ist ein offizielles Image verfügbar.

Zunächst eine Warnung. Das docker-compose.yml im Repository ist eine Entwicklungsumgebung. Es erwartet, dass Sie eine Shell im Container öffnen und npm install && composer install && npm start ausführen. Das ist keine Deployment-Konfiguration. Verwenden Sie stattdessen das veröffentlichte Image:

services:
  easyappointments:
    image: alextselegidis/easyappointments  # pin the current tag from Docker Hub
    environment:
      - BASE_URL=https://book.example.com
      - DB_HOST=mysql
      - DB_NAME=easyappointments
      - DB_USERNAME=easyapp
      - DB_PASSWORD=change-me
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - mysql
  mysql:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=change-me-too
      - MYSQL_DATABASE=easyappointments
      - MYSQL_USER=easyapp
      - MYSQL_PASSWORD=change-me
    volumes:
      - ./mysql:/var/lib/mysql

BASE_URL muss die öffentliche HTTPS-Adresse sein. Wenn der Wert falsch ist, verweisen die Buchungslinks in Bestätigungs-E-Mails auf einen Host, den Ihr Client nicht erreichen kann. Das Image stellt unverschlüsseltes HTTP auf Port 80 bereit und besitzt kein eigenes Zertifikat. Deshalb wird der Port an 127.0.0.1 gebunden und Nginx übernimmt die TLS-Terminierung davor. Wenn die Compose-Syntax für Sie neu ist, beginnen Sie mit Grundlagen zu Docker Compose auf einem VPS und kehren Sie anschließend hierher zurück.

Dies ist mit großem Abstand die ressourcenschonendste Option in dieser Übersicht. Zwei Container, eine PHP-Anwendung und MySQL, laufen problemlos auf einem VPS mit 1 GB. Der Nachteil ist die eingeschränkte Auswahl: Google Calendar ist das einzige Kalender-Backend, und die Oberfläche ist ein herkömmliches Admin-Panel statt eines modernen Buchungsablaufs. Wenn Sie Microsoft 365, Fastmail oder Nextcloud als Kalender verwenden, scheidet diese Option von vornherein aus.

Rallly für Gruppenabstimmungen

Rallly beantwortet eine andere Frage. Es veröffentlicht nicht Ihre Verfügbarkeit. Stattdessen stellt es einer Gruppe mehrere mögliche Zeitpunkte zur Auswahl und sammelt die Stimmen. Das ist für eine Vorstandssitzung geeignet, aber für einen Buchungslink für Kunden unbrauchbar.

curl -fsSL https://get.rallly.co | bash

Lesen Sie jedes Skript, bevor Sie es an eine Shell weiterleiten. Ersetzen Sie bash durch less, prüfen Sie, was das Skript tut, und führen Sie es erst danach aus. Der manuelle Weg erledigt dieselbe Aufgabe in nachvollziehbaren Schritten:

git clone https://github.com/lukevella/rallly-selfhosted.git
cd rallly-selfhosted
./rallly.sh setup
./rallly.sh start

Laut Dokumentation sind mindestens 2 GB RAM, Docker 19.03 oder neuer mit Compose v2, freie Ports 80 und 443 sowie eine Domain erforderlich, die auf den Server zeigt. Der enthaltene Stack besteht aus Traefik für HTTPS, der Webanwendung, PostgreSQL und Garage für S3-kompatiblen Objektspeicher. Setzen Sie DOMAIN, ein SECRET_PASSWORD mit mindestens 32 Zeichen, SUPPORT_EMAIL und INITIAL_ADMIN_EMAIL. Wenn Sie bereits einen Reverse Proxy betreiben, setzen Sie PROXY_MODE=external und WEB_PORT. Traefik greift dann nicht ein. Wenn Sie bereits einen selbst gehosteten S3-kompatiblen Objektspeicher mit MinIO betreiben, verweisen Sie die S3_*-Variablen darauf und entfernen Sie den Garage-Container.

SMTP ist hier zwingend erforderlich, weil die Anmeldung über einen Magic Link erfolgt. Ohne ein funktionierendes Relay kann sich niemand anmelden, auch das gerade erstellte Administratorkonto nicht. Das ist die weniger problematische Variante eines E-Mail-Fehlers: Er blockiert Sie am Eingang, statt drei Wochen später die Buchung eines Kunden zu verlieren.

DayOtter, der neueste Zugang

DayOtter ist eine AGPLv3-Scheduling-Plattform mit integriertem Assistenten. Die Installation für den Produktivbetrieb erfolgt mit einem Befehl:

curl -fsSL https://raw.githubusercontent.com/Dayotter/dayotter/main/deploy/install.sh \
  | sudo DAYOTTER_DOMAIN=cal.example.com bash

Lesen Sie den Befehl wie oben beschrieben, bevor Sie ihn ausführen. Das Installationsprogramm richtet Docker ein, generiert Secrets und startet den vollständigen Stack: die Next.js-Webanwendung, einen Hintergrund-Worker für Erinnerungen, Kalendersynchronisierung und Webhooks, PostgreSQL, Redis sowie Caddy mit automatischem HTTPS.

Die Kalenderunterstützung ist unter den vier Plattformen am umfassendsten. Unterstützt werden Google, Microsoft 365, Apple über CalDAV und ICS-Feeds, mit dem oben genannten Vorbehalt für ICS. Alle anderen Integrationen werden über Umgebungsvariablen aktiviert. Dazu gehören SMTP oder Resend für E-Mail, ANTHROPIC_API_KEY für den Assistenten, Twilio für SMS und Stripe für Zahlungen. Der Assistent arbeitet nach dem Prinzip der vorherigen Bestätigung: Er macht einen Vorschlag, Sie bestätigen ihn, und ohne ausdrückliche Zustimmung wird nichts in Ihren Kalender eingetragen. Wenn Sie den API-Schlüssel leer lassen, wird dieser Teil des Produkts nicht ausgeführt.

Die Lizenzierung ist für Self-Hosting klar geregelt. Der Kern steht unter AGPLv3. Ein Verzeichnis ee/ enthält eine kommerzielle, ausschließlich für die Cloud vorgesehene Lizenz. Sie bleibt inaktiv, solange DAYOTTER_CLOUD=1 nicht gesetzt ist. Damit stehen die Teamfunktionen des gehosteten Plans, der im August 2026 pro Sitzplatz und Monat $9 kostet, auf Ihrem eigenen Server zur Verfügung.

Dies ist zugleich der umfangreichste Stack und das jüngste Projekt in diesem Vergleich. Betreiben Sie ihn zwei Wochen lang neben Ihrem bestehenden Buchungslink, nehmen Sie über beide Systeme reale Buchungen an und lesen Sie die Worker-Logs, bevor Sie Ihre Kunden umstellen.

Was jeder Stack tatsächlich kostet

Die Anzahl der Container ist ein verlässlicher Indikator dafür, wie stark ein Stack einen kleinen VPS belastet, da jeder Dienst einen eigenen Grundbedarf an Arbeitsspeicher hat. Dies sind die Anzahlen aus den von den jeweiligen Projekten veröffentlichten Docker-Stacks, ermittelt im August 2026.

[
  {
    "tool": "Easy!Appointments",
    "containers": 2,
    "database": "MySQL"
  },
  {
    "tool": "Cal.com",
    "containers": 3,
    "database": "PostgreSQL"
  },
  {
    "tool": "Rallly",
    "containers": 4,
    "database": "PostgreSQL"
  },
  {
    "tool": "DayOtter",
    "containers": 5,
    "database": "PostgreSQL and Redis"
  }
]

Easy!Appointments benötigt 2 Container und läuft mit 1 GB. Rallyls gebündelter Stack umfasst 4 Container, und die Dokumentation nennt 2 GB als Anforderung. Der Installer von DayOtter startet 5 Container. Deshalb benötigt DayOtter hier den größten Server unter den 4 Optionen. Cal.com und DayOtter veröffentlichen überhaupt keine Mindestangabe zum Arbeitsspeicher. Deshalb setze ich für beide zunächst 2 GB an, ohne dass dies eine unterstützte Mindestgröße wäre.

Zwei dieser Anzahlen sinken, wenn Sie die Infrastruktur bereits betreiben. Die Traefik- und Garage-Container von Rallly entfallen, wenn Sie einen eigenen Proxy und eigenen Objektspeicher verwenden. Prisma Studio von Cal.com ist ein Entwicklungswerkzeug und sollte nicht auf einem öffentlichen Server dauerhaft ausgeführt werden.

Welche selbst gehostete Calendly-Alternative sollten Sie wählen

Ein Einzelberater sollte Cal.com einsetzen. Es ist das einzige Projekt hier, das eine wiedererkennbare Buchungsseite, vorgefertigte Images ohne Node-Build auf Ihrem VPS und eine CalDAV-Anbindung für alle kombiniert, die keinen Kalender bei Google oder Microsoft führen. Eine PostgreSQL-Datenbank und ein Anwendungskontainer sind ein Wartungsaufwand, den Sie über Jahre bewältigen können. Planen Sie einen Nachmittag für den OAuth-Client und das Mail-Relay ein. Beachten Sie, dass die CalDAV-Anwendung noch Beta-Status hat. Testen Sie daher eine echte Buchung vollständig, bevor Sie den Link veröffentlichen.

Ein kleines Team sollte sich DayOtter ansehen. Weighted Round Robin und kollektive Buchungen sind im AGPLv3-Kern enthalten. Beim Self-Hosting erhalten Sie daher Funktionen, für die ein gehosteter Sitzungszugang Gebühren verlangt. Der Worker-Prozess ist außerdem für Erinnerungen und Webhooks ausgelegt, auf die ein Team tatsächlich angewiesen ist. Der Nachteil ist der Reifegrad: Es ist das jüngste Projekt in dieser Liste. Betreiben Sie es daher zunächst parallel und lassen Sie den alten Link aktiv, bis Sie einen vollständigen Monat mit Buchungen beobachtet haben.

Zwei speziellere Fälle: Wenn Sie nur eine Umfrage benötigen, um einen Termin zu finden, an dem sich die Gruppe treffen kann, installieren Sie Rallly und belassen Sie es dabei. Wenn Sie einen 1-GB-VPS haben, Google Calendar verwenden und die kleinste Anwendung benötigen, die Buchungen entgegennimmt, wird Easy!Appointments jede aufwendigere Option überdauern, die Sie auf diesem System installieren könnten. Eine umfassendere Frage dazu, welche anderen Anwendungen auf demselben Server sinnvoll sind, beantwortet was sich 2026 für das Self-Hosting lohnt.

FAQ

Kann ich eine selbst gehostete Buchungsseite ohne Domainnamen betreiben?

Nein. Jede dieser Anwendungen schreibt ihre öffentliche URL in die Links der Bestätigungs-E-Mails. Google und Microsoft vergleichen außerdem die OAuth-Weiterleitungs-URI mit demselben Wert. Bei einer einfachen IP-Adresse erhalten Sie daher auf der Zustimmungsseite redirect_uri_mismatch. Let’s Encrypt stellt ebenfalls kein Zertifikat für eine IP-Adresse aus. Die Seite wird dann über unverschlüsseltes HTTP geladen, und der Browser markiert das Formular als nicht sicher. Kaufen Sie zuerst die Domain, setzen Sie einen A-Eintrag auf die VPS-IP-Adresse und installieren Sie die Anwendung anschließend.

Warum kommen meine Buchungsbestätigungen per E-Mail nie an?

Fast immer versucht der Server, die E-Mail selbst zuzustellen. Die meisten VPS-Anbieter blockieren bei neuen Konten ausgehende Verbindungen auf Port 25. Dadurch bleibt die Verbindung hängen. Selbst wenn der Port geöffnet ist, hat eine neue Adresse noch keine Reputation als Absender, und große Empfänger lehnen die Nachricht ab. Konfigurieren Sie in der Anwendung ein Transaktionsmail-Relay auf Port 587. Prüfen Sie mit nc -vz -w 5 "$SMTP_HOST" 587, ob der Port erreichbar ist. Veröffentlichen Sie anschließend die SPF- und DKIM-Einträge, die Ihnen das Relay bereitstellt. Wenn Sie Cal.com betreiben, prüfen Sie, ob Sie die mitgelieferten Standardwerte EMAIL_SERVER_HOST=localhost und EMAIL_SERVER_PORT=1025 ersetzt haben. Diese verweisen auf ein lokales Entwicklungs-Postfach.

Synchronisiert selbst gehostetes Cal.com mit CalDAV oder nur mit Google?

Mit beiden, allerdings mit unterschiedlichem Reifegrad. Die CalDAV-Anwendung ist als Beta gekennzeichnet und wurde unter anderem mit Baikal, Radicale, Nextcloud und Kerio Connect verifiziert. Apple iCloud funktioniert darüber mit einem anwendungsspezifischen Passwort. Google Calendar und Microsoft 365 synchronisieren in beide Richtungen. Bei einer selbst gehosteten Installation müssen Sie jedoch einen eigenen OAuth-Client erstellen und ihn über GOOGLE_API_CREDENTIALS bereitstellen, da die Zugangsdaten des gehosteten Dienstes nicht im Quelltext enthalten sind.

Warum funktioniert die Synchronisierung mit meinem Google Calendar nach einer Woche nicht mehr?

Weil das Google-Cloud-Projekt noch den Veröffentlichungsstatus Testing besitzt. Google stellt Anwendungen in diesem Status Refresh-Tokens aus, die nach sieben Tagen ablaufen. Daher funktioniert die Verbindung zunächst und schlägt beim nächsten Token-Refresh fehl. Im Anwendungslog erscheint dann invalid_grant. Setzen Sie den OAuth-Zustimmungsbildschirm auf In production und verbinden Sie den Kalender einmal erneut. Wenn Sie die Verbindung erneut herstellen, ohne den Status zu ändern, erhalten Sie lediglich weitere sieben Tage.

Welche dieser Anwendungen läuft auf einer VPS mit 1 GB?

Easy!Appointments läuft, da es sich um eine PHP-Anwendung mit MySQL handelt. Rallly dokumentiert ein Minimum von 2 GB, und der mitgelieferte Stack führt vier Dienste aus. Cal.com und DayOtter nennen keine Mindestanforderung. Eine Next.js-Anwendung mit PostgreSQL benötigt jedoch entsprechend Ressourcen. Bei DayOtter kommen außerdem Redis und ein Worker-Prozess hinzu. Planen Sie daher 2 GB oder mehr ein. Bauen Sie Cal.com auf einem kleinen Server niemals aus dem Quelltext. Die eigenen Build-Anweisungen des Projekts verlangen einen 16-GB-Node-Heap. Verwenden Sie stattdessen das vorgefertigte Image.