Samodzielne alternatywy dla Calendly: porównanie systemów

Krótka odpowiedź

Samodzielnie hostowana alternatywa dla Calendly musi realizować jedno zadanie, którego narzędzia wewnętrzne na VPS nigdy nie wykonują: odpowiadać na żądania publiczne. Strona rezerwacji jest produktem. Wymaga ona poprawnej nazwy domenowej oraz TLS (transport layer security) od pierwszego dnia, a także musi dostarczać wiadomości e-mail do osób, które nigdy nie słyszały o Twoim serwerze.

Cztery projekty wyczerpują realistyczny zakres rozwiązań. Cal.com jest najbliższym odpowiednikiem Calendly i domyślnym wyborem dla konsultanta pracującego samodzielnie. Easy!Appointments to lekka alternatywa, oparta na PHP i MySQL, działająca poprawnie na VPS z 1 GB pamięci RAM. Rallly służy do tworzenia ankiet grupowych i nie posiada strony rezerwacji. DayOtter to najnowszy uczestnik rynku, platforma do planowania na licencji AGPLv3, wyposażona w asystenta wymagającego potwierdzenia przed rezerwacją.

Dwa pytania decydują o tym, które rozwiązanie można faktycznie uruchomić. Czy narzędzie synchronizuje się dwukierunkowo z używanym kalendarzem? Oraz czy potrafi wysyłać wiadomości e-mail? To drugie pytanie jest punktem, w którym większość samodzielnie hostowanych systemów rezerwacji zawodzi, dlatego należy rozpatrzyć je w pierwszej kolejności.

Wychodząca poczta elektroniczna jest elementem, który zawodzi

Potwierdzenie rezerwacji trafia do skrzynki odbiorczej nieznajomej osoby. Jest to poczta transakcyjna docierająca do Gmail lub Microsoft 365, a odbiorcy ci oceniają nadawcę na podstawie adresu IP oraz rekordów DNS.

Wysyłka bezpośrednio z VPS prawie nigdy nie działa. Większość dostawców blokuje wychodzący port TCP 25 na nowych kontach, więc połączenie zawiesza się, a następnie przekracza limit czasu. Nawet jeśli port 25 jest otwarty, świeży adres VPS nie posiada historii wysyłkowej, a duzi odbiorcy traktują nieznane adresy z zakresów hostingowych jako podejrzane. Rezerwacja zostaje zapisana w bazie danych, strona wyświetla komunikat o potwierdzeniu, a nikt nie otrzymuje wiadomości. Od strony serwera wszystko wygląda poprawnie, dlatego problem ten jest zazwyczaj wykrywany dopiero po tygodniach przez klienta, który nie dotarł na miejsce.

Należy użyć przekaźnika (relay). Każdy dostawca poczty transakcyjnej jest odpowiedni, a aplikacja wymaga jedynie nazwy hosta, portu, użytkownika i hasła. Przed edycją konfiguracji aplikacji sprawdź, czy port jest osiągalny:

nc -vz -w 5 "$SMTP_HOST" 587

Linia succeeded oznacza, że ścieżka jest otwarta. Zawieszenie lub Connection refused oznacza, że port jest blokowany na poziomie sieci i żadna edycja .env tego nie naprawi. Przekaźniki nasłuchują na portach 587 lub 465 właśnie dlatego, że port 25 jest tak często blokowany.

Każdy projekt obsługuje przekaźnik w inny sposób. Cal.com odczytuje EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER oraz EMAIL_SERVER_PASSWORD, akceptuje również RESEND_API_KEY. Należy na to uważać: dostarczony .env.example wskazuje EMAIL_SERVER_HOST na localhost na porcie 1025, co jest lokalną skrzynką programistyczną. Pozostawienie wartości domyślnej spowoduje, że aplikacja będzie wysyłać wiadomości w próżnię bez zgłaszania błędu. Rallly wymaga SMTP_HOST, SMTP_PORT, SMTP_USER oraz SMTP_PWD. DayOtter przyjmuje ustawienia SMTP lub klucz Resend. Easy!Appointments wysyła powiadomienia z poziomu aplikacji, więc przed przyjęciem pierwszej prawdziwej rezerwacji należy wskazać ten sam przekaźnik w ustawieniach.

Następnie opublikuj rekordy DNS dostarczone przez przekaźnik. Rekord SPF (sender policy framework) określa, które serwery mogą wysyłać pocztę w imieniu Twojej domeny, a klucz DKIM (domainkeys identified mail) podpisuje każdą wiadomość, aby odbiorca mógł zweryfikować, czy nie została ona zmodyfikowana. Po poprawnej konfiguracji obu tych elementów dodaj politykę DMARC (domain-based message authentication, reporting and conformance). Wyślij testową rezerwację na prawdziwy adres u dużego dostawcy, otwórz nagłówki wiadomości i potwierdź, że linie uwierzytelniania wskazują pass. Strona rezerwacji, która nie potrafi wysłać powiadomienia, jest gorsza niż brak strony rezerwacji, ponieważ zawodzi w sposób niezauważalny.

Które backendy kalendarza faktycznie synchronizują się dwukierunkowo

Synchronizacja odbywa się w dwóch kierunkach, a każdy z nich może zawieść niezależnie. Kierunek odczytu to dostępność: aplikacja musi widzieć istniejące bloki zajętości, w przeciwnym razie zaproponuje termin, w którym użytkownik jest już zajęty. Kierunek zapisu to sama rezerwacja: potwierdzone wydarzenie musi pojawić się w kalendarzu, z którego faktycznie korzystasz, a nie tylko wewnątrz narzędzia do rezerwacji.

Google Calendar oraz Microsoft 365 obsługują oba kierunki, pod jednym warunkiem w przypadku instalacji self-hosted. Klient OAuth (open authorization) musi zostać utworzony samodzielnie, ponieważ identyfikator klienta (client ID) produktu hostowanego nie znajduje się w kodzie źródłowym. W przypadku Cal.com jest to GOOGLE_API_CREDENTIALS w .env, przechowujące plik JSON pobrany z konsoli Google Cloud. DayOtter przyjmuje poświadczenia OAuth Google i Microsoft w ten sam sposób.

Dwie rzeczy mogą tu zawieść i warto o nich wiedzieć przed rozpoczęciem. Po pierwsze, zarejestrowany redirect URI musi dokładnie odpowiadać publicznemu adresowi URL, włącznie ze schematem i ewentualną ścieżką końcową, w przeciwnym razie Google przerwie połączenie z błędem redirect_uri_mismatch na ekranie zgody. Po drugie, projekt Google pozostawiony w statusie publikacji Testing wydaje tokeny odświeżania (refresh tokens), które wygasają po siedmiu dniach. Synchronizacja działa przez cały tydzień, a następnie przestaje, a logi aplikacji pokazują invalid_grant przy kolejnej próbie odświeżenia. Przełącz ekran zgody na In production lub zaakceptuj konieczność ręcznego ponownego łączenia w każdy poniedziałek.

CalDAV (rozszerzenia kalendarzowe dla WebDAV) to opcja otwarta, jednak wsparcie jest węższe. Cal.com dostarcza aplikację CalDAV, która wciąż jest oznaczona jako beta, zweryfikowaną z serwerami takimi jak Baikal, Radicale, Nextcloud oraz Kerio Connect. Apple iCloud działa przez tę samą aplikację, ale wymaga hasła specyficznego dla aplikacji (app-specific password), a nie hasła do Apple ID. DayOtter wymienia Apple przez CalDAV obok Google i Microsoft 365.

Kanał ICS nie jest synchronizacją. Subskrybowany adres URL .ics jest z założenia tylko do odczytu, więc może blokować czas w kalendarzu rezerwacji, ale nigdy nie otrzyma samej rezerwacji. Jeśli narzędzie oferuje tylko ICS dla kalendarza, oznacza to posiadanie tylko połowy niezbędnej infrastruktury i konieczność ręcznego kopiowania wydarzeń.

Easy!Appointments synchronizuje wyłącznie Google Calendar. Rallly w ogóle nie odczytuje dostępności: zbiera głosy dla zestawu proponowanych dat. Jest to właściwe narzędzie do ustalania terminu spotkania dla grupy osób, ale niewłaściwe do rezerwacji 30-minutowych slotów z jedną osobą.

Strona rezerwacji jest publiczna, więc TLS jest priorytetem

Większość usług hostowanych samodzielnie jest prywatna. Wiki, forum czy panel sterowania mogą znajdować się za VPN lub logowaniem SSO i nigdy nie być widoczne w otwartym Internecie. Link do rezerwacji nie może być ukryty. Każda osoba, której go wyślesz, musi mieć możliwość jego załadowania, co zmienia konfigurację w trzech konkretnych aspektach.

Przed instalacją czegokolwiek potrzebujesz nazwy domeny z rekordem A wskazującym na VPS. Certyfikat jest niezbędny od pierwszego dnia, ponieważ przeglądarki oznaczają zwykłe formularze HTTP jako niezabezpieczone, a klient wpisuje w nie swoje imię, nazwisko oraz adres e-mail. Należy również poprawnie ustawić publiczny adres URL aplikacji w jej konfiguracji, ponieważ wartość ta jest osadzana w linkach w wychodzących wiadomościach e-mail oraz w identyfikatorach URI przekierowań OAuth. Ustaw NEXT_PUBLIC_WEBAPP_URL w Cal.com, DOMAIN w Rallly, BASE_URL w Easy!Appointments lub DAYOTTER_DOMAIN w momencie instalacji i przypisz go do adresu https://, którego faktycznie będziesz używać.

Rallly i DayOtter rozwiązują kwestię TLS automatycznie. Zintegrowany stos Rallly zawiera Traefik i wystawia certyfikaty Let's Encrypt przy użyciu adresu z ACME_EMAIL. Instalator DayOtter uruchamia Caddy z automatycznym HTTPS. Cal.com i Easy!Appointments nie posiadają takich funkcji, więc należy umieścić przed nimi nginx i samodzielnie wystawić certyfikat, w taki sam sposób, jak w przypadku certyfikatu Let's Encrypt na nginx z użyciem Certbot. Powiąż kontener aplikacji z 127.0.0.1, aby jedyną drogą dostępu był kontrolowany przez Ciebie proxy. Jeśli na tym samym serwerze działa już alternatywa dla Trello do wewnętrznych tablic, pozostaw ją za istniejącym uwierzytelnianiem, a publiczny blok serwera przypisz wyłącznie do hosta obsługującego rezerwacje.

Cal.com na Twoim VPS

Konfiguracja Docker znajduje się w dedykowanym repozytorium, a obrazy są wstępnie zbudowane w Docker Hub, więc należy je pobierać, a nie budować samodzielnie.

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

Pierwsza losowa wartość trafia do NEXTAUTH_SECRET, a druga do CALENDSO_ENCRYPTION_KEY. Obie są wymagane. Ustaw DATABASE_URL i skieruj NEXT_PUBLIC_WEBAPP_URL na swój publiczny adres. Pakiet zawiera aplikację webową, PostgreSQL oraz Prisma Studio; dokumentacja podaje docker compose up -d calcom dla uruchomienia samej aplikacji z bazą danych hostowaną zewnętrznie, co jest zalecanym rozwiązaniem po zakończeniu instalacji.

Pobierz obraz, nie buduj go na VPS. Instrukcje projektu zalecają eksport NODE_OPTIONS="--max-old-space-size=16384" podczas budowania ze źródeł, co wymaga 16 GB pamięci tylko dla Node. Na architekturze ARM dodaj sufiks -arm do tagu obrazu. Projekt nie określa minimalnych wymagań dla gotowego obrazu, więc przyjmij 2 GB dla aplikacji wraz z PostgreSQL jako wartość roboczą, a nie udokumentowaną, i monitoruj zużycie pamięci w pierwszym tygodniu.

Sprawdź, czy usługa działa:

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

Polecenie curl powinno zwrócić HTTP/2 200. Błąd 502 Bad Gateway z nginx, mimo że kontener jest uruchomiony, zazwyczaj oznacza, że podczas pierwszego uruchomienia trwa migracja bazy danych. Odczekaj kilka minut i przejrzyj logi, zanim uznasz, że wystąpiła awaria. Webhooki Cal.com są wyzwalane przy każdej potwierdzonej rezerwacji, więc rezerwacja może uruchomić dowolną automatyzację, na przykład instancję n8n dostępną przez HTTPS na Twoim VPS.

Rdzeń oprogramowania jest na licencji AGPLv3, przy czym niektóre funkcje znajdują się w katalogu enterprise objętym oddzielną licencją komercyjną. Zapoznaj się z tą licencją przed oparciem płatnych procesów biznesowych na funkcjach zespołowych.

Easy!Appointments na serwerze 1 GB

Wymagania to Apache lub Nginx, PHP 8.2 lub nowszy oraz MySQL. Oficjalny obraz znajduje się pod adresem alextselegidis/easyappointments.

Najpierw ostrzeżenie. Plik docker-compose.yml w repozytorium służy do środowiska programistycznego. Zakłada on otwarcie powłoki w kontenerze i uruchomienie npm install && composer install && npm start. Nie jest to konfiguracja produkcyjna. Zamiast tego należy użyć opublikowanego obrazu:

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 musi być publicznym adresem HTTPS. Błędne ustawienie spowoduje, że linki do rezerwacji w wiadomościach potwierdzających będą wskazywać na hosta niedostępnego dla klienta. Obraz obsługuje zwykły protokół HTTP na porcie 80 bez własnego certyfikatu, dlatego port jest powiązany z 127.0.0.1, a Nginx wykonuje terminację TLS przed aplikacją. Jeśli składnia compose jest nowością, należy zacząć od Podstawy Docker Compose na VPS i wrócić tutaj.

Jest to zdecydowanie najlżejsza opcja w zestawieniu. Dwa kontenery, aplikacja PHP oraz MySQL, działają bez problemów na VPS z 1 GB pamięci RAM. Ceną za to jest ograniczona funkcjonalność: Google Calendar jest jedynym obsługiwanym backendem kalendarza, a interfejs to tradycyjny panel administracyjny, a nie nowoczesny proces rezerwacji. Jeśli używany kalendarz to Microsoft 365, Fastmail lub Nextcloud, ta opcja nie będzie odpowiednia.

Rallly do ankiet grupowych

Rallly odpowiada na inne potrzeby. Nie publikuje Twojej dostępności. Prezentuje grupie zestaw proponowanych terminów i zbiera głosy, co jest przydatne podczas planowania spotkań zarządu, ale nie sprawdza się w przypadku linków do rezerwacji dla klientów.

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

Przed przekazaniem skryptu do powłoki należy zapoznać się z jego treścią. Zamień bash na less, sprawdź działanie skryptu, a następnie go uruchom. Ręczna instalacja wykonuje te same czynności w widocznych krokach:

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

Wymagania techniczne obejmują co najmniej 2 GB pamięci RAM, Docker 19.03 lub nowszy z Compose v2, wolne porty 80 i 443 oraz domenę skierowaną na serwer. Pakiet zawiera Traefik do obsługi HTTPS, aplikację webową, PostgreSQL oraz Garage jako pamięć obiektową zgodną z S3. Skonfiguruj DOMAIN, SECRET_PASSWORD o długości co najmniej 32 znaków, SUPPORT_EMAIL oraz INITIAL_ADMIN_EMAIL. Jeśli na serwerze działa już reverse proxy, ustaw PROXY_MODE=external oraz WEB_PORT, aby Traefik nie kolidował z istniejącą konfiguracją. Jeśli korzystasz już z własnego serwera pamięci obiektowej zgodnej z S3, takiego jak MinIO, wskaż na niego zmienne S3_* i usuń kontener Garage.

SMTP jest w tym przypadku wymagane, ponieważ logowanie odbywa się za pomocą magicznego linku. Bez działającego przekaźnika nikt nie będzie mógł się zalogować, w tym konto administratora utworzone podczas instalacji. Jest to korzystny scenariusz awarii poczty: blokuje dostęp na etapie konfiguracji, zamiast doprowadzić do utraty rezerwacji klienta trzy tygodnie później.

DayOtter, nowy uczestnik rynku

DayOtter to platforma do harmonogramowania na licencji AGPLv3, wyposażona w zintegrowanego asystenta. Instalacja produkcyjna sprowadza się do jednego polecenia:

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

Należy zapoznać się z jego treścią przed uruchomieniem, zgodnie z powyższymi zaleceniami. Instalator konfiguruje Docker, generuje sekrety i uruchamia pełny stos: aplikację webową Next.js, proces w tle obsługujący przypomnienia, synchronizację kalendarza i webhooks, PostgreSQL, Redis oraz Caddy z automatycznym HTTPS.

Obsługa kalendarzy jest najszersza spośród czterech omawianych rozwiązań. Obejmuje Google, Microsoft 365, Apple poprzez CalDAV oraz kanały ICS, z zastrzeżeniem dotyczącym ICS wspomnianym wcześniej. Każda inna integracja jest opcjonalna i wymaga konfiguracji poprzez zmienne środowiskowe, w tym SMTP lub Resend dla poczty, ANTHROPIC_API_KEY dla asystenta, Twilio dla SMS oraz Stripe dla płatności. Asystent działa w trybie potwierdzenia: proponuje działanie, użytkownik je zatwierdza i żadna zmiana nie trafia do kalendarza bez wyraźnej zgody. Pozostawienie pustego klucza API powoduje, że ta część produktu po prostu nie jest uruchamiana.

Licencjonowanie jest przejrzyste dla użytkowników hostujących rozwiązanie samodzielnie. Rdzeń systemu objęty jest licencją AGPLv3, a katalog ee/ zawiera kod objęty komercyjną licencją przeznaczoną wyłącznie dla chmury, która pozostaje nieaktywna, dopóki nie zostanie ustawiona zmienna DAYOTTER_CLOUD=1. Oznacza to, że funkcje zespołowe, za które w planie hostowanym pobierana jest opłata w wysokości 9 USD za użytkownika miesięcznie (stan na sierpień 2026), są dostępne na własnym serwerze.

Jest to jednocześnie najcięższy stos w zestawieniu i najmłodszy projekt. Zaleca się uruchomienie go równolegle z dotychczasowym narzędziem do rezerwacji na okres dwóch tygodni, przyjmowanie rzeczywistych rezerwacji przez oba systemy oraz analizę dzienników procesu w tle (worker logs) przed przeniesieniem klientów.

Rzeczywiste koszty każdego stosu

Liczba kontenerów stanowi rzetelny wskaźnik zapotrzebowania stosu na zasoby małego serwera VPS, ponieważ każda usługa posiada własny minimalny próg zużycia pamięci. Poniższe wartości pochodzą z opublikowanych stosów Docker poszczególnych projektów, stan na sierpień 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 wymaga 2 kontenerów i mieści się w 1 GB pamięci RAM. Dołączony stos Rallly składa się z 4 kontenerów, a dokumentacja wskazuje na zapotrzebowanie 2 GB. Instalator DayOtter uruchamia 5 kontenerów, dlatego wymaga on największej maszyny spośród 4 wymienionych tutaj. Cal.com oraz DayOtter nie publikują żadnych minimalnych wymagań dotyczących pamięci, dlatego dla obu przyjąłem 2 GB jako punkt wyjścia, a nie jako oficjalnie wspieraną wartość.

Dwie z tych wartości mogą zostać zredukowane, jeśli infrastruktura jest już uruchomiona. Kontenery Traefik oraz Garage w Rallly można usunąć, korzystając z własnego proxy oraz pamięci obiektowej. Prisma Studio w Cal.com to narzędzie programistyczne, którego nie należy pozostawiać uruchomionego na publicznym serwerze.

Którą alternatywę dla Calendly wybrać do samodzielnego hostowania

Samodzielny konsultant powinien wybrać Cal.com. Jest to jedyny projekt w tym zestawieniu, który łączy rozpoznawalną stronę rezerwacji, gotowe obrazy (co oszczędza zasoby VPS przy budowaniu Node) oraz obsługę CalDAV dla osób niekorzystających z kalendarzy Google lub Microsoft. Jedna baza danych PostgreSQL i jeden kontener aplikacji to obciążenie utrzymaniowe, które można obsługiwać przez lata. Należy zarezerwować popołudnie na konfigurację klienta OAuth oraz przekaźnika poczty (mail relay). Warto pamiętać, że aplikacja CalDAV jest wciąż w fazie beta, dlatego przed udostępnieniem linku należy przetestować pełny proces rezerwacji.

Mały zespół powinien rozważyć DayOtter. Mechanizmy ważonego round robin oraz rezerwacji zbiorowych znajdują się w rdzeniu oprogramowania na licencji AGPLv3. Samodzielne hostowanie pozwala uzyskać funkcje, za które w usługach chmurowych pobierane są opłaty za każde stanowisko, a proces roboczy (worker) jest zoptymalizowany pod kątem przypomnień i webhooków, z których zespół faktycznie korzysta. Ceną jest dojrzałość rozwiązania: jest to najnowszy projekt na liście, dlatego warto uruchomić go równolegle i zachować stary link do czasu zweryfikowania pełnego miesiąca rezerwacji.

Dwa węższe przypadki. Jeśli jedynym celem jest ankieta w celu ustalenia terminu spotkania grupy, należy zainstalować Rallly i na tym poprzestać. Jeśli dysponujesz VPS o pojemności 1 GB, korzystasz z Google Calendar i szukasz najlżejszego rozwiązania do przyjmowania rezerwacji, Easy!Appointments przetrwa każdą bardziej rozbudowaną opcję, którą można zainstalować na tym serwerze. Szersze zestawienie usług, które warto hostować samodzielnie, znajduje się w sekcji co warto hostować samodzielnie w 2026.

FAQ

Czy mogę uruchomić własną stronę do rezerwacji bez nazwy domeny?

Nie. Każda z tych aplikacji zapisuje swój publiczny adres URL w linkach wewnątrz wiadomości e-mail z potwierdzeniem, a Google i Microsoft weryfikują adres URI przekierowania OAuth względem tej samej wartości, więc sam adres IP spowoduje wyświetlenie redirect_uri_mismatch na ekranie zgody. Let’s Encrypt również nie wystawi certyfikatu dla adresu IP, przez co strona będzie ładowana przez zwykły HTTP, a przeglądarka oznaczy formularz jako niezabezpieczony. Najpierw należy zakupić domenę, skierować rekord A na VPS, a następnie przeprowadzić instalację.

Dlaczego moje e-maile z potwierdzeniem rezerwacji nie docierają?

Prawie zawsze dlatego, że serwer próbuje dostarczyć pocztę samodzielnie. Większość dostawców VPS blokuje wychodzący port 25 na nowych kontach, przez co połączenie zawisa, a nawet jeśli jest otwarte, nowy adres nie posiada reputacji nadawcy i duże serwery pocztowe odrzucają takie wiadomości. Należy skonfigurować aplikację tak, aby korzystała z zewnętrznego przekaźnika poczty (SMTP relay) na porcie 587, sprawdzić dostępność portu za pomocą nc -vz -w 5 "$SMTP_HOST" 587, a następnie opublikować rekordy SPF i DKIM dostarczone przez przekaźnik. W przypadku korzystania z Cal.com należy upewnić się, że zastąpiono domyślne wartości EMAIL_SERVER_HOST=localhost oraz EMAIL_SERVER_PORT=1025, które wskazują na lokalną skrzynkę programistyczną.

Czy samodzielnie hostowany Cal.com synchronizuje się z CalDAV, czy tylko z Google?

Z oboma, choć na różnym poziomie dojrzałości. Aplikacja CalDAV jest oznaczona jako beta i została zweryfikowana pod kątem współpracy z serwerami takimi jak Baikal, Radicale, Nextcloud oraz Kerio Connect; Apple iCloud również działa poprzez tę metodę przy użyciu hasła specyficznego dla aplikacji. Google Calendar i Microsoft 365 synchronizują się w obu kierunkach, jednak w przypadku samodzielnej instalacji należy utworzyć własnego klienta OAuth i podać go poprzez GOOGLE_API_CREDENTIALS, ponieważ poświadczenia usługi hostowanej nie znajdują się w kodzie źródłowym.

Dlaczego moja synchronizacja z Google Calendar przestaje działać po tygodniu?

Ponieważ projekt w Google Cloud nadal posiada status publikacji Testing. Google wydaje tokeny odświeżania dla aplikacji w tym stanie, które wygasają po siedmiu dniach, więc połączenie działa, a następnie zrywa się przy kolejnym odświeżeniu tokena, co w dzienniku aplikacji objawia się błędem invalid_grant. Należy zmienić status ekranu zgody OAuth na In production i ponownie połączyć kalendarz. Ponowne łączenie bez zmiany statusu zapewnia jedynie kolejne siedem dni działania.

Która z tych aplikacji zadziała na VPS z 1 GB pamięci RAM?

Easy!Appointments zadziała, ponieważ jest to aplikacja PHP wraz z bazą MySQL. Rallly wymaga minimum 2 GB pamięci, a jego pakiet uruchamia cztery usługi. Cal.com i DayOtter nie podają wymagań minimalnych, jednak aplikacja Next.js z PostgreSQL, a w przypadku DayOtter także z Redis i procesem roboczym, oznacza, że należy zaplanować 2 GB lub więcej. Nigdy nie należy budować Cal.com ze źródeł na małej maszynie: instrukcje budowania projektu wymagają 16 GB pamięci dla stosu Node, dlatego należy pobrać gotowy obraz.