En İyi Self-Hosted Calendly Alternatifleri Karşılaştırması

Kısa cevap

Self-hosted bir Calendly alternatifi, VPS üzerindeki dahili araçların asla yapmadığı bir şeyi yapmak zorundadır: halka açık bir yanıt vermek. Randevu sayfası ürünün kendisidir. İlk günden itibaren gerçek bir alan adına ve TLS (transport layer security) protokolüne ihtiyaç duyar; ayrıca sunucunuzu daha önce hiç duymamış kişilere e-posta iletebilmelidir.

Dört proje, gerçekçi seçenekleri kapsamaktadır. Cal.com, Calendly'ye en yakın eşleşmedir ve bireysel danışmanlar için varsayılan tercihtir. Easy!Appointments, PHP ve MySQL kullanan, 1 GB RAM'e sahip bir VPS üzerinde rahatça çalışan hafif bir seçenektir. Rallly bir grup anket aracıdır ve herhangi bir randevu sayfası içermez. DayOtter ise en yeni katılımcıdır; ön tarafında onay odaklı bir asistan bulunan, AGPLv3 lisanslı bir planlama platformudur.

Hangisini gerçekten çalıştırabileceğinize iki soru karar verir. Halihazırda kullandığınız takvimle çift yönlü senkronizasyon yapıyor mu? Ve e-posta gönderebiliyor mu? İkinci soru, çoğu self-hosted randevu kurulumunun sessizce başarısız olduğu noktadır, bu yüzden öncelik bu sorudadır.

Giden e-posta trafiğinin başarısız olması

Bir rezervasyon onayı yabancı birinin gelen kutusuna gider. Bu, Gmail veya Microsoft 365 gibi servislere ulaşan işlemsel bir postadır ve bu alıcılar sizi gönderen IP adresi ile DNS kayıtlarınıza göre değerlendirir.

Doğrudan VPS üzerinden gönderim yapmak neredeyse hiçbir zaman çalışmaz. Çoğu sağlayıcı yeni hesaplarda giden TCP 25 numaralı portu engeller; bu nedenle bağlantı askıda kalır ve zaman aşımına uğrar. 25 numaralı port açık olsa bile, yeni bir VPS adresinin gönderim geçmişi yoktur ve büyük alıcılar, bilinmeyen hosting aralığındaki adresleri şüpheli olarak değerlendirir. Rezervasyon veritabanına yazılır, sayfa onaylandığını belirtir ancak kimse e-posta almaz. Sunucu tarafında hiçbir şey bozuk görünmez; bu durum genellikle haftalar sonra gelmeyen bir müşteri tarafından fark edilir.

Bir aktarıcı (relay) kullanın. Herhangi bir işlemsel e-posta sağlayıcısı iş görür; uygulamanın yalnızca bir ana bilgisayar adı, port, kullanıcı adı ve parolaya ihtiyacı vardır. Uygulama yapılandırmasına dokunmadan önce portun erişilebilir olduğunu kontrol edin:

nc -vz -w 5 "$SMTP_HOST" 587

Bir succeeded satırı yolun açık olduğu anlamına gelir. Bir askıda kalma veya Connection refused durumu, portun ağ seviyesinde engellendiğini gösterir ve .env dosyasını düzenlemek bunu düzeltmeyecektir. Aktarıcılar 587 veya 465 numaralı portları dinler, çünkü 25 numaralı port sıklıkla engellenir.

Her proje aktarıcıyı kendi yöntemiyle kullanır. Cal.com; EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER ve EMAIL_SERVER_PASSWORD değerlerini okur, ayrıca bir RESEND_API_KEY değerini de kabul eder. Buna dikkat edin: yüklü gelen .env.example dosyası, EMAIL_SERVER_HOST değerini yerel bir geliştirme posta kutusu olan localhost adresine ve 1025 numaralı porta yönlendirir. Varsayılan ayarı olduğu gibi bırakırsanız uygulama hiçbir hata vermeden e-postaları boşluğa gönderir. Rallly; SMTP_HOST, SMTP_PORT, SMTP_USER ve SMTP_PWD değerlerini alır. DayOtter, SMTP ayarlarını veya bir Resend anahtarını kabul eder. Easy!Appointments bildirimlerini uygulamadan gönderir, bu yüzden gerçek bir rezervasyon kabul etmeden önce ayarlar sayfasından onu aynı aktarıcıya yönlendirin.

Ardından aktarıcınızın size verdiği DNS kayıtlarını yayınlayın. Bir SPF (sender policy framework) kaydı, alan adınız adına hangi sunucuların gönderim yapabileceğini belirtir; bir DKIM (domainkeys identified mail) anahtarı ise her iletiyi imzalar, böylece alıcı iletinin değiştirilmediğini kanıtlayabilir. Her ikisi de başarılı olduktan sonra bir DMARC (domain-based message authentication, reporting and conformance) politikası ekleyin. Büyük bir sağlayıcıdaki gerçek bir adrese test rezervasyonu gönderin, ileti başlıklarını açın ve kimlik doğrulama satırlarının pass şeklinde göründüğünü doğrulayın. Gönderim yapamayan bir rezervasyon sayfası, hiç olmamasından daha kötüdür çünkü sessizce başarısız olur.

Hangi takvim arka uçları gerçekten çift yönlü senkronizasyon sağlar

Senkronizasyon iki yönlüdür ve her iki yön de birbirinden bağımsız olarak başarısız olabilir. Okuma yönü uygunluk durumudur: uygulama mevcut meşgul olduğunuz zaman dilimlerini görmelidir, aksi takdirde zaten dolu olduğunuz bir zaman dilimi için randevu oluşturulmasına izin verir. Yazma yönü ise randevunun kendisidir: onaylanan etkinlik, yalnızca randevu aracının içinde değil, fiilen kullandığınız takvimde de görünmelidir.

Google Calendar ve Microsoft 365, self-hosted kurulumlarda tek bir koşulla her iki yönde de çalışır. OAuth (açık yetkilendirme) istemcisini kendiniz oluşturmalısınız, çünkü barındırılan ürünün istemci kimliği kaynak kodunda yer almaz. Cal.com için bu, Google Cloud konsolundan indirdiğiniz JSON dosyasını içeren GOOGLE_API_CREDENTIALS dizinindeki .env dosyasıdır. DayOtter, Google ve Microsoft OAuth kimlik bilgilerini aynı şekilde kabul eder.

Burada iki nokta sorun çıkarabilir ve başlamadan önce her ikisini de bilmekte fayda vardır. Birincisi, kaydettiğiniz yönlendirme URI'si (redirect URI), şema ve varsa sondaki yol dahil olmak üzere genel URL'nizle tam olarak eşleşmelidir; aksi takdirde Google, onay ekranında redirect_uri_mismatch hatası vererek bağlantıyı durdurur. İkincisi, Test aşamasında bırakılan bir Google projesi, yedi gün sonra süresi dolan yenileme belirteçleri (refresh tokens) üretir. Senkronizasyon tüm hafta çalışır ve ardından durur; uygulama günlükleri bir sonraki yenilemede invalid_grant hatasını gösterir. Onay ekranını Yayında (In production) durumuna getirin ya da her Pazartesi manuel olarak yeniden bağlanmayı kabul edin.

CalDAV (WebDAV için takvim uzantıları) açık kaynaklı seçenektir ancak desteği daha kısıtlıdır. Cal.com, Baikal, Radicale, Nextcloud ve Kerio Connect gibi sunucularla doğrulanmış, hala beta olarak işaretlenen bir CalDAV uygulaması sunar. Apple iCloud aynı uygulama üzerinden çalışır ancak Apple ID parolanız yerine uygulamaya özel bir parola gerektirir. DayOtter, Apple'ı CalDAV aracılığıyla Google ve Microsoft 365'in yanında listeler.

Bir ICS beslemesi senkronizasyon değildir. Abone olunan bir .ics URL'si tasarımı gereği salt okunurdur; bu nedenle randevu sayfanızda zamanı engelleyebilir ancak randevuyu asla alamaz. Bir araç takviminiz için yalnızca ICS sunuyorsa, altyapının sadece yarısına sahipsiniz demektir ve etkinlikleri hala elle kopyalamanız gerekecektir.

Easy!Appointments yalnızca Google Calendar ile senkronize olur, başka hiçbir şeyle çalışmaz. Rallly ise uygunluk durumunu hiç okumaz: sadece aday tarihler üzerinde oylama toplar. Bu araç "altımız ne zaman buluşabiliriz" sorusu için doğru, "benimle 30 dakika randevu ayarla" durumu için ise yanlış bir araçtır.

Rezervasyon sayfası herkese açıktır, bu nedenle TLS önceliklidir

Kendi sunucunuzda barındırdığınız (self-host) çoğu şey özeldir. Bir wiki, bir pano veya bir kontrol paneli; bunların tamamı bir VPN veya SSO girişi arkasında kalabilir ve internete asla açık olmayabilir. Bir rezervasyon bağlantısı ise böyle olamaz. Bağlantıyı gönderdiğiniz herkesin sayfayı yükleyebilmesi gerekir; bu durum kurulumu üç somut şekilde değiştirir.

Herhangi bir kurulum yapmadan önce, VPS adresine yönlendirilmiş bir A kaydına sahip bir alan adına ihtiyacınız vardır. İlk günden itibaren bir sertifikaya sahip olmanız gerekir; çünkü tarayıcılar düz HTTP formlarını güvenli değil olarak işaretler ve müşteriniz adını ve e-postasını bu forma girer. Ayrıca uygulamanın genel URL'sinin yapılandırmasında doğru ayarlanmış olması gerekir; çünkü bu değer, giden e-postaların içindeki bağlantılara ve OAuth yönlendirme URI'lerine işlenir. Cal.com'da NEXT_PUBLIC_WEBAPP_URL, Rallly'de DOMAIN, Easy!Appointments'ta BASE_URL veya kurulum sırasında DAYOTTER_DOMAIN değerini ayarlayın ve bunu gerçekten kullanacağınız https:// adresi olarak belirleyin.

Rallly ve DayOtter, TLS sorununu sizin yerinize çözer. Rallly'nin paketlenmiş yığını Traefik içerir ve ACME_EMAIL içindeki adresi kullanarak Let's Encrypt sertifikaları oluşturur. DayOtter yükleyicisi, otomatik HTTPS ile Caddy'yi ayağa kaldırır. Cal.com ve Easy!Appointments bunu yapmaz; bu nedenle önlerine nginx koymalı ve sertifikayı kendiniz oluşturmalısınız. Bu işlemi, nginx üzerinde Certbot ile Let's Encrypt sertifikası oluştururken izlediğiniz yöntemle yapabilirsiniz. Uygulama container'ını 127.0.0.1 adresine bağlayın; böylece içeriye tek giriş yolu, kontrolünüz altındaki proxy üzerinden olur. Eğer aynı sunucu üzerinde hâlihazırda dahili panolarınız için kendi kendine barındırılan bir Trello alternatifi çalışıyorsa, onu mevcut kimlik doğrulamanızın arkasında tutun ve yalnızca rezervasyon sunucusuna genel bir server bloğu atayın.

VPS üzerinde Cal.com

Docker yapılandırması kendi deposunda yer alır ve imajlar Docker Hub üzerinde önceden oluşturulmuştur; bu nedenle imajı oluşturmak yerine çekmeniz gerekir.

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

İlk rastgele değer NEXTAUTH_SECRET içine, ikincisi ise CALENDSO_ENCRYPTION_KEY içine girilmelidir. Her ikisi de zorunludur. DATABASE_URL değerini ayarlayın ve NEXT_PUBLIC_WEBAPP_URL adresini genel IP adresinize yönlendirin. Birlikte gelen yığın; web uygulaması, PostgreSQL ve Prisma Studio'dan oluşur; belgeler, kurulum tamamlandıktan sonra tercih etmeniz gereken yöntem olan, uygulamayı başka bir yerde barındırdığınız bir veritabanına karşı tek başına çalıştırmak için docker compose up -d calcom komutunu önerir.

İmajı çekin, VPS üzerinde oluşturmayın. Projenin kendi talimatları, kaynak koddan derleme yaparken NODE_OPTIONS="--max-old-space-size=16384" değerini dışa aktarmanızı söyler; bu sadece Node için 16 GB yığın belleği demektir. ARM donanım üzerinde, imaj etiketine -arm sonekini ekleyin. Proje, önceden oluşturulmuş imajı çalıştırmak için bir minimum değer belirtmemektedir; bu nedenle uygulama ve PostgreSQL için 2 GB değerini belgelenmiş bir değerden ziyade çalışma değerim olarak kabul edin ve ilk hafta boyunca bellek kullanımını izleyin.

Çalışıp çalışmadığını kontrol edin:

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

curl komutu HTTP/2 200 çıktısını vermelidir. Konteyner çalışıyor görünürken nginx üzerinden 502 Bad Gateway hatası alınması, genellikle ilk başlatma sırasında veritabanı migrasyonlarının uygulanmaya devam ettiği anlamına gelir. Sistemin bozuk olduğuna karar vermeden önce birkaç dakika bekleyin ve günlük kayıtlarını inceleyin. Cal.com web kancaları her onaylanmış rezervasyonda tetiklenir; bu sayede bir rezervasyon, halihazırda çalıştırdığınız otomasyonları tetikleyebilir; örneğin VPS üzerinde HTTPS üzerinden erişilebilen bir n8n örneği.

Çekirdek yapı AGPLv3 lisansına sahiptir, bazı özellikler ise ayrı bir ticari lisans altında kurumsal dizinde tutulur. Ekip özelliklerine dayalı ücretli bir iş süreci oluşturmadan önce bu lisansı okuyun.

1 GB sunucuda Easy!Appointments

Gereksinimler Apache veya Nginx, PHP 8.2 veya daha yeni bir sürüm ve MySQL'dir. alextselegidis/easyappointments adresinde resmi bir imaj bulunmaktadır.

Öncelikle bir uyarı: Depodaki docker-compose.yml bir geliştirme ortamıdır. Bu ortam, container içinde bir kabuk açıp npm install && composer install && npm start çalıştırmanızı bekler. Bu bir dağıtım (deployment) yöntemi değildir. Bunun yerine yayınlanmış imajı kullanın:

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, herkese açık HTTPS adresi olmalıdır. Bu ayarı yanlış yaparsanız, onay e-postalarındaki rezervasyon bağlantıları müşterinizin erişemeyeceği bir ana bilgisayarı işaret eder. İmaj, kendi sertifikası olmadan 80 numaralı port üzerinden düz HTTP sunar; bu nedenle port 127.0.0.1 adresine bağlanır ve Nginx TLS sonlandırmasını ön tarafta gerçekleştirir. Compose sözdizimi sizin için yeniyse, önce VPS üzerinde Docker Compose temelleri konusuna göz atıp geri dönün.

Bu seçenek, buradaki en hafif seçenektir. Bir PHP uygulaması ve MySQL olmak üzere iki container, 1 GB'lık bir VPS üzerinde rahatça çalışır. Maliyeti ise kapsamıdır: Google Calendar tek takvim arka ucudur ve arayüz, modern bir rezervasyon akışından ziyade geleneksel bir yönetici panelidir. Takviminiz Microsoft 365, Fastmail veya Nextcloud ise, bu seçenek başlamadan elenir.

Grup anketleri için Rallly

Rallly farklı bir ihtiyaca yanıt verir. Müsaitlik durumunuzu yayınlamaz. Bir grup için aday zaman dilimlerini sunar ve oyları toplar; bu, yönetim kurulu toplantıları için idealdir ancak müşteri randevu bağlantısı olarak kullanılamaz.

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

Bir betiği shell ortamına yönlendirmeden önce mutlaka okuyun. bash yerine less kullanın, ne yaptığını inceleyin ve ardından çalıştırın. Manuel yol, aynı işlemleri görebileceğiniz adımlarla gerçekleştirir:

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

Belgelenen gereksinimler en az 2 GB RAM, Docker 19.03 veya daha yeni bir sürüm ile Compose v2, boş 80 ve 443 numaralı portlar ve sunucuya yönlendirilmiş bir alan adıdır. Pakete dahil olan yığın; HTTPS için Traefik, web uygulaması, PostgreSQL ve S3 uyumlu nesne depolama için Garage içerir. DOMAIN, en az 32 karakterlik bir SECRET_PASSWORD, SUPPORT_EMAIL ve INITIAL_ADMIN_EMAIL değerlerini ayarlayın. Hali hazırda bir reverse proxy çalıştırıyorsanız PROXY_MODE=external ve WEB_PORT ayarlarını yapılandırın; böylece Traefik devre dışı kalacaktır. Eğer halihazırda kendi barındırdığınız S3 uyumlu bir nesne deposu (MinIO) kullanıyorsanız, S3_* değişkenlerini bu depoya yönlendirin ve Garage container'ını kaldırın.

Giriş işlemi "magic link" (tek kullanımlık bağlantı) ile yapıldığından SMTP burada isteğe bağlı değildir. Çalışan bir relay (aktarıcı) olmadan, yeni oluşturduğunuz yönetici hesabı dahil hiç kimse giriş yapamaz. E-posta hatasının bu versiyonu aslında iyidir: Bir müşterinin randevusunu üç hafta sonra kaybetmek yerine, sizi daha en başta kapıda durdurur.

DayOtter, en yeni katılımcı

DayOtter, kendisine bağlı bir asistanı bulunan AGPLv3 lisanslı bir planlama platformudur. Üretim ortamı kurulumu tek bir komuttan ibarettir:

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

Çalıştırmadan önce yukarıda belirtildiği gibi okuyun. Yükleyici Docker kurulumunu yapar, gizli anahtarları oluşturur ve tüm yığını ayağa kaldırır: Next.js web uygulaması, hatırlatıcıları, takvim eşitlemeyi ve webhook'ları yöneten bir arka plan işçisi, PostgreSQL, Redis ve otomatik HTTPS özellikli Caddy.

Takvim desteği, bu dörtlü arasındaki en kapsamlı olanıdır. Google, Microsoft 365, CalDAV üzerinden Apple ve yukarıdaki ICS uyarısıyla birlikte ICS beslemeleri desteklenir. Diğer tüm entegrasyonlar, posta için SMTP veya Resend, asistan için ANTHROPIC_API_KEY, SMS için Twilio ve ödemeler için Stripe dahil olmak üzere ortam değişkenleri aracılığıyla isteğe bağlıdır. Asistan "önce onayla" prensibiyle çalışır: öneride bulunur, siz onaylarsınız ve açık bir "evet" yanıtı olmadan hiçbir şey takviminize ulaşmaz. API anahtarını boş bırakırsanız, ürünün o kısmı basitçe çalışmaz.

Lisanslama, kendi sunucusunda barındıranlar (self-hoster) için temizdir. Çekirdek AGPLv3 lisanslıdır ve ee/ dizini, DAYOTTER_CLOUD=1 ayarlanmadığı sürece etkisiz kalan ticari bir bulut lisansı içerir. Bu, Ağustos 2026 itibarıyla kullanıcı başına aylık 9 dolar olarak faturalandırılan ekip özelliklerinin kendi sunucunuzda kullanılabilir olduğu anlamına gelir.

Bu aynı zamanda buradaki en ağır yığın ve en genç projedir. İki hafta boyunca mevcut rezervasyon bağlantınızın yanında çalıştırın, her ikisi üzerinden gerçek rezervasyonlar alın ve müşterilerinizi taşımadan önce işçi (worker) günlüklerini okuyun.

Her bir yığının gerçek maliyeti

Konteyner sayısı, her servis kendi bellek tabanını beraberinde getirdiği için küçük bir VPS'in ne kadar kaynak tüketeceğinin en dürüst göstergesidir. Bu sayılar, Ağustos 2026 itibarıyla her projenin kendi yayınladığı Docker yığınından alınmıştır.

[
  {
    "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 2 adet konteyner gerektirir ve 1 GB bellek üzerinde çalışabilir. Rallly'nin paketlenmiş yığını 4 adet konteyner içerir ve dokümantasyonu 2 GB bellek talep eder. DayOtter yükleyicisi 5 adet konteyner başlatır; bu nedenle buradaki 4 seçenek arasında en büyük sunucuyu gerektirir. Cal.com ve DayOtter herhangi bir minimum bellek değeri yayınlamadığından, her ikisi için de desteklenen bir değer yerine 2 GB başlangıç noktası olarak alınmıştır.

Eğer halihazırda bir altyapı çalıştırıyorsanız, bu sayıların ikisi düşebilir. Rallly'nin Traefik ve Garage konteynerleri, kendi proxy ve nesne depolama (object storage) biriminizi kullandığınızda devre dışı bırakılabilir. Cal.com'un Prisma Studio aracı, halka açık bir sunucuda çalışır durumda bırakılmaması gereken bir geliştirme aracıdır.

Hangi self-hosted Calendly alternatifini seçmelisiniz

Bireysel bir danışman Cal.com kullanmalıdır. Bu listede, insanların aşina olduğu bir rezervasyon sayfasını, VPS üzerinde Node derleme yükünden kurtaran hazır imajları ve Google veya Microsoft dışında takvim tutanlar için CalDAV yolunu birleştiren tek proje budur. Bir adet PostgreSQL veritabanı ve bir adet uygulama container'ı, yıllarca sürdürebileceğiniz bir bakım yüküdür. OAuth istemcisi ve posta aktarıcısı (mail relay) için bir öğleden sonranızı ayırın; CalDAV uygulamasının henüz beta aşamasında olduğunu unutmayın, bu nedenle bağlantıyı yayınlamadan önce gerçek bir rezervasyonla uçtan uca test yapın.

Küçük bir ekip DayOtter'ı değerlendirmelidir. Ağırlıklı round robin ve toplu rezervasyon özellikleri AGPLv3 çekirdeğinde yer alır; bu sayede self-hosting ile bulut tabanlı servislerin ücretli sunduğu özellikleri ücretsiz kullanabilirsiniz. Worker süreci, bir ekibin ihtiyaç duyduğu hatırlatıcılar ve webhook'lar için optimize edilmiştir. Bunun karşılığında ödenen bedel olgunluk seviyesidir: Bu listedeki en yeni proje olduğu için, önce mevcut sisteminizle paralel çalıştırın ve bir ay boyunca rezervasyonları gözlemleyene kadar eski bağlantınızı aktif tutun.

İki özel durum daha mevcuttur. Eğer tek ihtiyacınız grubun buluşabileceği bir zamanı belirlemek için anket yapmaksa, Rallly kurun ve başka bir şeyle uğraşmayın. Eğer 1 GB RAM'li bir VPS'niz varsa, Google Calendar kullanıyorsanız ve rezervasyon alan en küçük aracı arıyorsanız, Easy!Appointments bu sunucuya kurabileceğiniz tüm karmaşık seçeneklerden daha uzun ömürlü olacaktır. Aynı sunucuda başka nelerin yer alabileceğine dair daha geniş bir perspektif için 2026 yılında self-hosting için neler değerlidir bölümüne bakın.

FAQ

Bir alan adı olmadan self-hosted bir randevu sayfası çalıştırabilir miyim?

Hayır. Bu uygulamaların her biri, genel URL adresini onay e-postalarının içindeki bağlantılara yazar. Google ve Microsoft, OAuth yönlendirme URI değerini bu URL ile karşılaştırır; bu nedenle çıplak bir IP adresi kullanırsanız onay ekranında redirect_uri_mismatch hatası alırsınız. Let’s Encrypt de bir IP adresi için sertifika düzenlemez; bu durumda sayfa şifrelenmemiş HTTP üzerinden yüklenir ve tarayıcı formu güvenli değil olarak işaretler. Önce alan adını satın alın, bir A kaydını VPS adresinize yönlendirin ve ardından kurulumu yapın.

Randevu onay e-postalarım neden hiç ulaşmıyor?

Bunun nedeni neredeyse her zaman sunucunun postayı kendi başına göndermeye çalışmasıdır. Çoğu VPS sağlayıcısı, yeni hesaplarda 25 numaralı giden portu engeller; bu nedenle bağlantı askıda kalır. Port açık olsa bile, yeni bir IP adresinin gönderim itibarı yoktur ve büyük e-posta sağlayıcıları bu postaları reddeder. Uygulamayı 587 numaralı port üzerinden bir işlemsel e-posta aktarıcısına (mail relay) yönlendirin, nc -vz -w 5 "$SMTP_HOST" 587 ile portun erişilebilir olduğunu doğrulayın ve ardından aktarıcının size verdiği SPF ve DKIM kayıtlarını yayınlayın. Eğer Cal.com çalıştırıyorsanız, yerel geliştirme posta kutusuna yönlendiren varsayılan EMAIL_SERVER_HOST=localhost ve EMAIL_SERVER_PORT=1025 değerlerini değiştirip değiştirmediğinizi kontrol edin.

Self-hosted Cal.com, CalDAV ile mi yoksa sadece Google ile mi senkronize olur?

Her ikisiyle de, ancak olgunluk seviyeleri farklıdır. CalDAV uygulaması beta olarak işaretlenmiştir ve Baikal, Radicale, Nextcloud ve Kerio Connect gibi sunucularla doğrulanmıştır; Apple iCloud ise uygulama özelinde bir parola kullanılarak bu uygulama üzerinden çalışır. Google Calendar ve Microsoft 365 her iki yönde de senkronize olur, ancak self-hosted bir kurulumda kendi OAuth istemcinizi oluşturmalı ve bunu GOOGLE_API_CREDENTIALS üzerinden sağlamalısınız; çünkü barındırılan hizmetin kimlik bilgileri kaynak kodda bulunmaz.

Google Calendar senkronizasyonum neden bir hafta sonra çalışmayı durduruyor?

Çünkü Google Cloud projeniz hala Test aşamasında yayınlanıyor. Google, bu durumdaki uygulamalara yedi gün sonra geçerliliğini yitiren yenileme jetonları (refresh tokens) verir. Bu nedenle bağlantı çalışır, ancak bir sonraki jeton yenilemesinde kopar ve uygulama günlüğünde invalid_grant hatası görünür. OAuth onay ekranını Üretim (In production) aşamasına taşıyın ve takvimi bir kez yeniden bağlayın. Durumu değiştirmeden yeniden bağlanmak size sadece yedi gün daha kazandırır, fazlasını değil.

Bunlardan hangileri 1 GB RAM'li bir VPS üzerinde çalışır?

Easy!Appointments, bir PHP uygulaması ve MySQL gerektirdiği için çalışır. Rallly, 2 GB minimum gereksinim belirtir ve paketlenmiş yığını dört servis çalıştırır. Cal.com ve DayOtter minimum bir gereksinim belirtmez; ancak PostgreSQL kullanan bir Next.js uygulaması ve DayOtter özelinde Redis ile bir işçi süreci (worker process) göz önüne alındığında, 2 GB veya daha fazlasını planlamalısınız. Cal.com'u asla küçük bir sunucuda kaynak koddan derlemeyin: projenin kendi derleme talimatları 16 GB Node yığını (heap) gerektirir, bu yüzden önceden derlenmiş imajı çekin.