सर्वश्रेष्ठ self-hosted Calendly विकल्प: एक तुलनात्मक गाइड

संक्षिप्त उत्तर

एक self-hosted Calendly विकल्प को वह एक काम करना होता है जो आपके VPS पर मौजूद आंतरिक tools कभी नहीं करते: सार्वजनिक रूप से उपलब्ध होना। बुकिंग पेज ही आपका product है। इसे पहले दिन से ही एक वास्तविक domain name और TLS (transport layer security) की आवश्यकता होती है, और इसे उन लोगों तक mail पहुँचाना होता है जिन्होंने आपके सर्वर का नाम कभी नहीं सुना है।

चार projects इस क्षेत्र की वास्तविक जरूरतों को पूरा करते हैं। Cal.com, Calendly का सबसे सटीक विकल्प है और एक solo consultant के लिए डिफ़ॉल्ट पसंद है। Easy!Appointments एक हल्का विकल्प है, जो PHP और MySQL पर आधारित है और 1 GB VPS पर आसानी से चलता है। Rallly एक group poll tool है और इसमें कोई बुकिंग पेज नहीं होता है। DayOtter सबसे नया entrant है, जो एक AGPLv3 शेड्यूलिंग प्लेटफॉर्म है और इसके सामने एक confirm-first assistant लगा हुआ है।

दो सवाल यह तय करते हैं कि आप वास्तव में किसे चला सकते हैं। क्या यह उस calendar के साथ two-way sync करता है जिसका आप पहले से उपयोग कर रहे हैं? और क्या यह mail भेज सकता है? दूसरा सवाल वह जगह है जहाँ अधिकांश self-hosted बुकिंग सेटअप चुपचाप विफल हो जाते हैं, इसलिए सबसे पहले इसी पर ध्यान दें।

Outbound email में विफलता

बुकिंग कन्फर्मेशन किसी अनजान व्यक्ति के इनबॉक्स में जाता है। यह एक ट्रांजेक्शनल ईमेल है जो Gmail या Microsoft 365 पर पहुँचता है, और ये प्राप्तकर्ता आपके भेजने वाले IP एड्रेस और DNS रिकॉर्ड्स के आधार पर आपका मूल्यांकन करते हैं।

सीधे VPS से ईमेल भेजना लगभग कभी काम नहीं करता है। अधिकांश प्रदाता नए अकाउंट्स पर आउटबाउंड TCP port 25 को ब्लॉक कर देते हैं, जिससे कनेक्शन हैंग हो जाता है और फिर टाइम आउट हो जाता है। जहाँ port 25 खुला भी हो, वहाँ एक नए VPS एड्रेस का कोई सेंडिंग इतिहास नहीं होता, और बड़े प्राप्तकर्ता अनजान होस्टिंग-रेंज एड्रेस को संदिग्ध मानते हैं। बुकिंग डेटाबेस में लिख दी जाती है, पेज पर 'कन्फर्म' लिखा आता है, और किसी को ईमेल नहीं मिलता। सर्वर साइड से कुछ भी टूटा हुआ नहीं दिखता, इसीलिए आमतौर पर इसका पता हफ्तों बाद उस क्लाइंट द्वारा चलता है जो कभी आया ही नहीं।

एक relay का उपयोग करें। कोई भी ट्रांजेक्शनल मेल प्रदाता काम करेगा, और ऐप को केवल एक hostname, एक port, एक user और एक password की आवश्यकता होती है। एप्लिकेशन कॉन्फ़िगरेशन को छूने से पहले जाँच लें कि port पहुँच योग्य है या नहीं:

nc -vz -w 5 "$SMTP_HOST" 587

एक succeeded लाइन का मतलब है कि रास्ता खुला है। हैंग होना या Connection refused का मतलब है कि port नेटवर्क स्तर पर ब्लॉक है, और .env को एडिट करने से यह ठीक नहीं होगा। Relays 587 या 465 पर इसलिए listen करते हैं क्योंकि 25 अक्सर ब्लॉक रहता है।

प्रत्येक प्रोजेक्ट relay को अपने तरीके से लेता है। Cal.com EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER और EMAIL_SERVER_PASSWORD को पढ़ता है, और इसके बजाय एक RESEND_API_KEY को भी स्वीकार करता है। उस पर ध्यान दें: शिप किया गया .env.example, EMAIL_SERVER_HOST को port 1025 पर localhost की ओर पॉइंट करता है, जो एक लोकल डेवलपमेंट मेलबॉक्स है। डिफ़ॉल्ट को वैसे ही रहने दें तो ऐप बिना किसी एरर के ईमेल को कहीं नहीं भेजेगा। Rallly SMTP_HOST, SMTP_PORT, SMTP_USER और SMTP_PWD लेता है। DayOtter SMTP सेटिंग्स या Resend की लेता है। आसान है! Easy!Appointments अपनी सूचनाएं एप्लिकेशन से भेजता है, इसलिए वास्तविक बुकिंग स्वीकार करने से पहले इसे इसके सेटिंग्स पेज से उसी relay पर पॉइंट करें।

फिर उन DNS रिकॉर्ड्स को प्रकाशित करें जो आपका relay आपको देता है। एक SPF (sender policy framework) रिकॉर्ड बताता है कि कौन से सर्वर आपके डोमेन के लिए ईमेल भेज सकते हैं, और एक DKIM (domainkeys identified mail) की प्रत्येक संदेश को साइन करती है ताकि प्राप्तकर्ता यह साबित कर सके कि इसमें कोई बदलाव नहीं किया गया है। जब दोनों पास हो जाएं, तो एक DMARC (domain-based message authentication, reporting and conformance) पॉलिसी जोड़ें। किसी बड़े प्रदाता के वास्तविक एड्रेस पर एक टेस्ट बुकिंग भेजें, संदेश के हेडर खोलें, और पुष्टि करें कि ऑथेंटिकेशन लाइनें pass पढ़ रही हैं। एक बुकिंग पेज जो ईमेल नहीं भेज सकता, वह बुकिंग पेज न होने से भी बदतर है, क्योंकि यह चुपचाप विफल हो जाता है।

कौन से कैलेंडर बैकएंड वास्तव में दोनों दिशाओं में सिंक (sync) करते हैं

सिंक की दो दिशाएँ होती हैं और वे अलग-अलग विफल हो सकती हैं। पढ़ने की दिशा उपलब्धता (availability) है: ऐप को आपके मौजूदा व्यस्त ब्लॉक देखने चाहिए, अन्यथा यह आपको ऐसा स्लॉट दे देगा जिसमें आप पहले से व्यस्त हैं। लिखने की दिशा स्वयं बुकिंग है: कन्फर्म इवेंट उस कैलेंडर पर दिखाई देना चाहिए जिसे आप वास्तव में देखते हैं, न कि केवल बुकिंग टूल के अंदर।

Google Calendar और Microsoft 365 दोनों दिशाओं में काम करते हैं, लेकिन self-hosted इंस्टॉलेशन पर एक शर्त है। आपको OAuth (open authorization) क्लाइंट स्वयं बनाना होगा, क्योंकि होस्ट किए गए प्रोडक्ट का क्लाइंट ID सोर्स कोड में नहीं होता है। Cal.com के लिए यह GOOGLE_API_CREDENTIALS है, जो .env में स्थित है, जिसमें वह JSON होता है जिसे आप Google Cloud कंसोल से डाउनलोड करते हैं। DayOtter भी Google और Microsoft OAuth क्रेडेंशियल्स को इसी तरह लेता है।

यहाँ दो चीजें खराब होती हैं, और शुरू करने से पहले दोनों को जानना जरूरी है। पहला, आपके द्वारा रजिस्टर किया गया redirect URI आपके पब्लिक URL से बिल्कुल मेल खाना चाहिए, जिसमें स्कीम और कोई भी ट्रेलिंग पाथ शामिल हो, अन्यथा Google सहमति स्क्रीन पर redirect_uri_mismatch के साथ कनेक्शन रोक देता है। दूसरा, Testing पब्लिशिंग स्टेटस में छोड़ा गया Google प्रोजेक्ट ऐसे रिफ्रेश टोकन जारी करता है जो सात दिनों के बाद समाप्त हो जाते हैं। सिंक पूरे सप्ताह काम करता है और फिर रुक जाता है, और ऐप लॉग अगले रिफ्रेश पर invalid_grant दिखाते हैं। सहमति स्क्रीन को In production पर ले जाएँ, या हर सोमवार को मैन्युअल रूप से फिर से कनेक्ट करना स्वीकार करें।

CalDAV (calendaring extensions to WebDAV) एक ओपन विकल्प है, और इसका सपोर्ट सीमित है। Cal.com एक CalDAV ऐप के साथ आता है जो अभी भी बीटा में है, जिसे Baikal, Radicale, Nextcloud और Kerio Connect जैसे सर्वरों पर सत्यापित किया गया है। Apple iCloud उसी ऐप के माध्यम से काम करता है लेकिन इसके लिए आपके Apple ID पासवर्ड के बजाय ऐप-विशिष्ट पासवर्ड की आवश्यकता होती है। DayOtter, Google और Microsoft 365 के साथ CalDAV के माध्यम से Apple को लिस्ट करता है।

ICS फीड सिंक नहीं है। एक सब्सक्राइब किया गया .ics URL डिज़ाइन के अनुसार केवल पढ़ने (read-only) के लिए होता है, इसलिए यह आपके बुकिंग पेज पर समय को ब्लॉक तो कर सकता है लेकिन यह कभी भी बुकिंग प्राप्त नहीं कर सकता। यदि कोई टूल आपके कैलेंडर के लिए केवल ICS प्रदान करता है, तो आपके पास केवल आधी सुविधा है और आपको अभी भी इवेंट्स को मैन्युअल रूप से कॉपी करना होगा।

Easy!Appointments केवल Google Calendar को सिंक करता है और कुछ नहीं। Rallly उपलब्धता को बिल्कुल भी नहीं पढ़ता है: यह संभावित तारीखों के सेट पर वोट इकट्ठा करता है। "हम छह लोग कब मिल सकते हैं" के लिए यह सही टूल है, लेकिन "मेरे साथ 30 मिनट बुक करें" के लिए यह गलत टूल है।

बुकिंग पेज सार्वजनिक होता है, इसलिए TLS सबसे पहले आता है

ज्यादातर चीजें जिन्हें लोग self-host करते हैं, वे निजी होती हैं। एक wiki, एक board, या एक dashboard, ये सभी VPN या SSO login के पीछे रह सकते हैं और इन्हें कभी भी open internet पर आने की आवश्यकता नहीं होती। एक booking link ऐसा नहीं कर सकता। जिसे भी आप यह लिंक भेजेंगे, उसे इसे load करना होगा, जो सेटअप को तीन ठोस तरीकों से बदल देता है।

किसी भी चीज को install करने से पहले, आपके पास एक domain name होना चाहिए जिसका A record VPS की ओर point कर रहा हो। आपको पहले दिन से ही एक certificate की आवश्यकता है, क्योंकि browsers एक plain HTTP form को not secure के रूप में चिह्नित करते हैं और आपका client उसमें अपना नाम और email डाल रहा होता है। और आपको app का public URL उसके config में सही ढंग से set करना होगा, क्योंकि वह मान outgoing email के भीतर के links और OAuth redirect URIs में शामिल हो जाता है। Cal.com में NEXT_PUBLIC_WEBAPP_URL, Rallly में DOMAIN, Easy!Appointments में BASE_URL, या install के समय DAYOTTER_DOMAIN set करें, और इसे उस https:// पते पर set करें जिसका आप वास्तव में उपयोग करेंगे।

Rallly और DayOtter आपके लिए TLS की समस्या हल करते हैं। Rallly के bundled stack में Traefik शामिल है और यह ACME_EMAIL में दिए गए पते का उपयोग करके Let's Encrypt certificates जारी करता है। DayOtter का installer Caddy को automatic HTTPS के साथ लाता है। Cal.com और Easy!Appointments ऐसा नहीं करते हैं, इसलिए आप nginx को सामने रखें और certificate खुद जारी करें, उसी तरह जैसे आप nginx पर Certbot के साथ Let's Encrypt certificate के लिए करते हैं। App container को 127.0.0.1 पर bind करें ताकि अंदर आने का एकमात्र रास्ता आपके द्वारा नियंत्रित proxy हो। यदि उसी box पर पहले से ही आपके internal boards के लिए एक self-hosted Trello विकल्प चल रहा है, तो उसे अपने मौजूदा auth के पीछे रखें और केवल booking host को ही public server block दें।

अपने VPS पर Cal.com

Docker configuration अपनी खुद की repository में रहती है, और images Docker Hub पर पहले से ही build की हुई होती हैं, इसलिए आपको उन्हें build करने के बजाय pull करना चाहिए।

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

पहला random value NEXTAUTH_SECRET में और दूसरा CALENDSO_ENCRYPTION_KEY में डालें। दोनों अनिवार्य हैं। DATABASE_URL को set करें और NEXT_PUBLIC_WEBAPP_URL को अपने public address पर point करें। बंडल किए गए stack में web app, PostgreSQL और Prisma Studio शामिल हैं; docs में कहीं और host किए गए database के साथ app को अकेले चलाने के लिए docker compose up -d calcom दिया गया है, जो कि install पूरा होने के बाद आपको करना चाहिए।

Image को pull करें, इसे VPS पर build न करें। project के अपने निर्देश आपको source से build करते समय NODE_OPTIONS="--max-old-space-size=16384" export करने के लिए कहते हैं, जो केवल Node के लिए 16 GB heap है। ARM hardware पर, image tag में -arm suffix जोड़ें। project prebuilt image को चलाने के लिए कोई न्यूनतम आवश्यकता प्रकाशित नहीं करता है, इसलिए 2 GB को app और PostgreSQL के लिए मेरा working figure मानें, न कि कोई documented आंकड़ा, और पहले सप्ताह के दौरान memory पर नज़र रखें।

जाँचें कि यह start हुआ या नहीं:

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

curl को HTTP/2 200 print करना चाहिए। container के running दिखने के दौरान nginx से 502 Bad Gateway मिलने का मतलब आमतौर पर यह होता है कि पहली boot अभी भी database migrations apply कर रही है। इसे कुछ मिनट दें और यह निष्कर्ष निकालने से पहले कि यह broken है, logs पढ़ें। Cal.com के webhooks हर confirmed booking पर fire होते हैं, इसलिए एक booking किसी भी ऐसी automation को चला सकती है जिसे आप पहले से चला रहे हैं, उदाहरण के लिए आपके VPS पर HTTPS के माध्यम से पहुँच योग्य एक n8n instance।

इसका core AGPLv3 है, जिसमें कुछ features एक अलग commercial licence के तहत enterprise directory में रखे गए हैं। team features पर आधारित कोई paid business process बनाने से पहले उस licence को पढ़ें।

1 GB VPS पर Easy!Appointments

इसके लिए Apache या Nginx, PHP 8.2 या उससे नया वर्ज़न, और MySQL की आवश्यकता होती है। alextselegidis/easyappointments पर एक आधिकारिक इमेज उपलब्ध है।

सबसे पहले एक चेतावनी। रिपॉजिटरी में मौजूद docker-compose.yml एक डेवलपमेंट एनवायरनमेंट है। यह अपेक्षा करता है कि आप कंटेनर में शेल खोलें और npm install && composer install && npm start चलाएं। यह डिप्लॉयमेंट के लिए नहीं है। इसके बजाय पब्लिश की गई इमेज का उपयोग करें:

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 आपका पब्लिक HTTPS एड्रेस होना चाहिए। यदि आप इसे गलत सेट करते हैं, तो कन्फर्मेशन ईमेल में मौजूद बुकिंग लिंक ऐसे होस्ट पर पॉइंट करेंगे जिसे आपका क्लाइंट एक्सेस नहीं कर पाएगा। यह इमेज पोर्ट 80 पर प्लेन HTTP सर्व करती है और इसमें अपना कोई सर्टिफिकेट नहीं होता, इसीलिए पोर्ट को 127.0.0.1 पर बाइंड किया गया है और Nginx इसके सामने TLS टर्मिनेशन करता है। यदि आप Compose सिंटैक्स के लिए नए हैं, तो VPS पर Docker Compose की बुनियादी जानकारी से शुरुआत करें और फिर वापस आएं।

यह यहाँ मौजूद सबसे हल्का विकल्प है। दो कंटेनर, एक PHP एप्लिकेशन और MySQL, 1 GB VPS पर आसानी से चल जाते हैं। इसकी कीमत इसकी पहुंच है: Google Calendar ही एकमात्र कैलेंडर बैकएंड है, और इंटरफ़ेस एक आधुनिक बुकिंग फ्लो के बजाय एक पारंपरिक एडमिन पैनल है। यदि आपका कैलेंडर Microsoft 365, Fastmail या Nextcloud है, तो शुरुआत करने से पहले ही यह विकल्प बाहर हो जाता है।

ग्रुप पोल के लिए Rallly

Rallly एक अलग तरह की समस्या का समाधान करता है। यह आपकी उपलब्धता को प्रकाशित नहीं करता है। यह एक समूह के सामने संभावित समय के विकल्प रखता है और वोट एकत्र करता है, जो बोर्ड मीटिंग के लिए तो उपयोगी है, लेकिन क्लाइंट बुकिंग लिंक के लिए व्यर्थ है।

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

किसी भी स्क्रिप्ट को शेल में पाइप करने से पहले उसे पढ़ें। bash को less से बदलें, देखें कि वह क्या करती है, और फिर उसे चलाएं। मैनुअल पाथ वही काम उन चरणों में करता है जिन्हें आप देख सकते हैं:

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

दस्तावेजीकृत आवश्यकताओं में कम से कम 2 GB RAM, Docker 19.03 या उससे नया वर्जन Compose v2 के साथ, पोर्ट 80 और 443 का खाली होना, और सर्वर पर पॉइंट किया गया एक डोमेन शामिल है। बंडल किए गए स्टैक में HTTPS के लिए Traefik, वेब एप्लिकेशन, PostgreSQL और S3-compatible ऑब्जेक्ट स्टोरेज के लिए Garage शामिल हैं। DOMAIN, कम से कम 32 कैरेक्टर का SECRET_PASSWORD, SUPPORT_EMAIL और INITIAL_ADMIN_EMAIL सेट करें। यदि आप पहले से ही एक reverse proxy चला रहे हैं, तो PROXY_MODE=external और WEB_PORT सेट करें, और Traefik हस्तक्षेप नहीं करेगा। यदि आप पहले से ही MinIO के साथ एक self-hosted S3-compatible ऑब्जेक्ट स्टोर चला रहे हैं, तो S3_* वेरिएबल्स को उसकी ओर पॉइंट करें और Garage कंटेनर को हटा दें।

यहाँ SMTP वैकल्पिक नहीं है, क्योंकि साइन-इन एक मैजिक लिंक के माध्यम से होता है। यदि कोई वर्किंग रिले नहीं है, तो कोई भी लॉग इन नहीं कर पाएगा, जिसमें आपके द्वारा अभी बनाया गया एडमिन अकाउंट भी शामिल है। यह ईमेल विफलता का एक अच्छा पहलू है: यह आपको तीन सप्ताह बाद किसी क्लाइंट की बुकिंग खोने के बजाय शुरुआत में ही रोक देता है।

DayOtter, नया प्रवेशक

DayOtter एक AGPLv3 शेड्यूलिंग प्लेटफॉर्म है जिसके साथ एक असिस्टेंट भी जुड़ा है। इसका प्रोडक्शन इंस्टॉलेशन केवल एक कमांड है:

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

इसे चलाने से पहले ऊपर दिए गए निर्देशानुसार इसे पढ़ें। इंस्टॉलर Docker सेटअप करता है, secrets जनरेट करता है, और पूरे स्टैक को चालू करता है: Next.js वेब ऐप, एक बैकग्राउंड वर्कर जो रिमाइंडर, कैलेंडर सिंक और webhooks को संभालता है, PostgreSQL, Redis, और ऑटोमैटिक HTTPS के साथ Caddy।

इन चारों में कैलेंडर सपोर्ट सबसे व्यापक है। इसमें Google, Microsoft 365, CalDAV के माध्यम से Apple, और ICS फीड शामिल हैं, जिसमें ऊपर दी गई ICS संबंधी चेतावनी लागू होती है। अन्य सभी इंटीग्रेशन environment variables के माध्यम से opt-in हैं, जिसमें मेल के लिए SMTP या Resend, असिस्टेंट के लिए ANTHROPIC_API_KEY, SMS के लिए Twilio, और भुगतान के लिए Stripe शामिल हैं। असिस्टेंट 'confirm-first' मॉडल पर काम करता है: यह प्रस्ताव देता है, आप उसे स्वीकार करते हैं, और आपकी स्पष्ट सहमति के बिना कुछ भी आपके कैलेंडर तक नहीं पहुँचता। यदि आप API key को खाली छोड़ देते हैं, तो प्रोडक्ट का वह हिस्सा चलता ही नहीं है।

सेल्फ-होस्टर्स के लिए लाइसेंसिंग स्पष्ट है। इसका कोर AGPLv3 है, और एक ee/ डायरेक्टरी में कमर्शियल क्लाउड-ओनली लाइसेंस है जो तब तक निष्क्रिय रहता है जब तक DAYOTTER_CLOUD=1 सेट न हो। इसका मतलब है कि अगस्त 2026 तक, $9 प्रति सीट प्रति माह की दर से उपलब्ध टीम फीचर्स वाले होस्टेड प्लान के लाभ आप अपने सर्वर पर भी ले सकते हैं।

यह यहाँ मौजूद सबसे भारी स्टैक है और सबसे नया प्रोजेक्ट भी। इसे दो सप्ताह तक अपने मौजूदा बुकिंग लिंक के साथ चलाएं, दोनों के माध्यम से वास्तविक बुकिंग लें, और अपने क्लाइंट्स को शिफ्ट करने से पहले वर्कर logs को पढ़ें।

प्रत्येक स्टैक की वास्तविक लागत

कंटेनर की संख्या इस बात का सटीक पैमाना है कि एक छोटा VPS किसी स्टैक से कितनी मांग करेगा, क्योंकि प्रत्येक सर्विस की अपनी न्यूनतम मेमोरी खपत होती है। ये संख्याएँ अगस्त 2026 में प्रत्येक प्रोजेक्ट के प्रकाशित Docker स्टैक से ली गई हैं।

[
  {
    "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 कंटेनरों की आवश्यकता होती है और यह 1 GB पर चल जाता है। Rallly का बंडल स्टैक 4 है, और इसके दस्तावेज़ 2 GB की मांग करते हैं। DayOtter का इंस्टॉलर 5 कंटेनर शुरू करता है, इसीलिए इसे यहाँ मौजूद 4 विकल्पों में सबसे बड़े सर्वर की आवश्यकता होती है। Cal.com और DayOtter कोई न्यूनतम मेमोरी आंकड़ा प्रकाशित नहीं करते हैं, इसलिए मैंने इन दोनों के लिए समर्थित संख्या के बजाय 2 GB को शुरुआती बिंदु माना है।

यदि आप पहले से ही इंफ्रास्ट्रक्चर चला रहे हैं, तो इनमें से दो संख्याएँ कम हो जाती हैं। जब आप Rallly को अपने स्वयं के प्रॉक्सी और ऑब्जेक्ट स्टोरेज पर पॉइंट करते हैं, तो इसके Traefik और Garage कंटेनर हट जाते हैं। Cal.com का Prisma Studio एक डेवलपमेंट टूल है जिसे आपको पब्लिक सर्वर पर चालू नहीं छोड़ना चाहिए।

आपको कौन सा self-hosted Calendly विकल्प चुनना चाहिए

एक solo consultant को Cal.com चलाना चाहिए। यह इस सूची का एकमात्र प्रोजेक्ट है जो एक ऐसा booking page प्रदान करता है जिसे लोग पहचानते हैं, इसमें prebuilt images उपलब्ध हैं जो आपके VPS को Node build के बोझ से बचाती हैं, और उन लोगों के लिए एक CalDAV path भी है जो Google या Microsoft पर अपना calendar नहीं रखते हैं। एक PostgreSQL database और एक application container का maintenance load आप वर्षों तक उठा सकते हैं। OAuth client और mail relay के लिए एक दोपहर का समय निर्धारित करें, और ध्यान रखें कि CalDAV app अभी भी beta में है, इसलिए लिंक प्रकाशित करने से पहले एक वास्तविक booking का अंत से अंत तक परीक्षण करें।

एक छोटी टीम को DayOtter पर विचार करना चाहिए। Weighted round robin और collective booking इसके AGPLv3 core में शामिल हैं, इसलिए self-hosting करने से आपको वे फीचर्स मिल जाते हैं जिनके लिए hosted service में शुल्क देना पड़ता है, और इसका worker process उन reminders और webhooks के लिए बना है जिन पर एक टीम वास्तव में निर्भर करती है। इसकी कीमत परिपक्वता (maturity) है: यह इस सूची का सबसे नया प्रोजेक्ट है, इसलिए इसे पहले समानांतर (parallel) चलाएं और पुराने लिंक को तब तक चालू रखें जब तक आप एक महीने की bookings को पूरी तरह से मॉनिटर न कर लें।

दो सीमित मामले। यदि आपको केवल एक poll की आवश्यकता है ताकि यह पता चल सके कि समूह कब मिल सकता है, तो Rallly इंस्टॉल करें और वहीं रुक जाएं। यदि आपके पास 1 GB का VPS है, आप Google Calendar का उपयोग करते हैं, और आप सबसे छोटा टूल चाहते हैं जो booking ले सके, तो Easy!Appointments उस सर्वर पर मौजूद किसी भी अन्य फैंसी विकल्प से अधिक समय तक चलेगा। उसी सर्वर पर और क्या-क्या रखने योग्य है, इस व्यापक प्रश्न के लिए देखें 2026 में क्या self-host करना सार्थक है।

FAQ

क्या मैं बिना domain name के self-hosted booking page चला सकता हूँ?

नहीं। इनमें से प्रत्येक app अपने confirmation emails के भीतर मौजूद links में अपना public URL लिखता है, और Google तथा Microsoft दोनों ही OAuth redirect URI का मिलान उसी value से करते हैं, इसलिए consent screen पर bare IP address का उपयोग करने पर आपको redirect_uri_mismatch दिखाई देगा। Let’s Encrypt भी IP address के लिए certificate जारी नहीं करेगा, जिसके कारण page plain HTTP पर load होगा और browser form को असुरक्षित (not secure) के रूप में चिह्नित कर देगा। पहले domain खरीदें, VPS पर A record point करें, और फिर install करें।

मेरे booking confirmation emails क्यों नहीं पहुँचते?

इसका कारण लगभग हमेशा यह होता है कि सर्वर स्वयं mail deliver करने का प्रयास कर रहा है। अधिकांश VPS providers नए accounts पर outbound port 25 को block कर देते हैं, जिससे connection अटक जाता है। जहाँ यह port खुला भी होता है, वहाँ एक नए address की कोई sending reputation नहीं होती और बड़े email receivers उसे स्वीकार करने से मना कर देते हैं। App को port 587 पर किसी transactional mail relay से जोड़ें, nc -vz -w 5 "$SMTP_HOST" 587 के साथ पुष्टि करें कि port reachable है, और फिर relay द्वारा दिए गए SPF तथा DKIM records को publish करें। यदि आप Cal.com चला रहे हैं, तो जाँचें कि क्या आपने shipped EMAIL_SERVER_HOST=localhost और EMAIL_SERVER_PORT=1025 defaults को बदल दिया है, जो कि local development mailbox की ओर point करते हैं।

क्या self-hosted Cal.com CalDAV के साथ sync होता है, या केवल Google के साथ?

दोनों के साथ, लेकिन उनकी परिपक्वता (maturity) अलग-अलग है। CalDAV app को beta के रूप में चिह्नित किया गया है और इसे Baikal, Radicale, Nextcloud तथा Kerio Connect जैसे servers के साथ verify किया गया है; Apple iCloud भी app-specific password का उपयोग करके इसके माध्यम से काम करता है। Google Calendar और Microsoft 365 दोनों ही दिशाओं में sync होते हैं, लेकिन self-hosted install पर आपको अपना स्वयं का OAuth client बनाना होगा और उसे GOOGLE_API_CREDENTIALS के माध्यम से प्रदान करना होगा, क्योंकि hosted service के credentials source code में नहीं होते।

एक सप्ताह बाद मेरा Google Calendar sync काम करना क्यों बंद कर देता है?

क्योंकि Google Cloud project अभी भी Testing publishing status में है। Google इस स्थिति में मौजूद apps को ऐसे refresh tokens जारी करता है जो सात दिनों के बाद expire हो जाते हैं। इसलिए connection काम करता है, फिर अगले token refresh पर बंद हो जाता है, और application log में invalid_grant दिखाई देता है। OAuth consent screen को In production पर ले जाएँ और calendar को एक बार फिर से connect करें। status बदले बिना केवल reconnect करने से आपको केवल सात दिन और मिलेंगे, उससे अधिक नहीं।

इनमें से कौन सा 1 GB VPS पर चलेगा?

Easy!Appointments चलेगा, क्योंकि यह एक PHP application है जिसके साथ MySQL का उपयोग होता है। Rallly के documentation में 2 GB का न्यूनतम requirement दिया गया है और इसका bundled stack चार services चलाता है। Cal.com और DayOtter कोई न्यूनतम requirement प्रकाशित नहीं करते, लेकिन PostgreSQL के साथ एक Next.js application, और DayOtter के मामले में Redis तथा एक worker process होने के कारण, आपको 2 GB या उससे अधिक की योजना बनानी चाहिए। छोटे box पर कभी भी Cal.com को source से build न करें: project के स्वयं के build instructions में 16 GB Node heap की आवश्यकता होती है, इसलिए इसके बजाय prebuilt image का उपयोग करें।