Self-hosted Calendly पर्याय: Cal.com, Rallly तुलना

थोडक्यात

Self-hosted Calendly पर्यायाने तुमच्या VPS वरील internal tools कधीही करत नसलेले एक काम करणे आवश्यक आहे: सार्वजनिक वापरकर्त्यांना प्रतिसाद देणे. Booking page हेच product आहे. पहिल्याच दिवसापासून त्यासाठी खरे domain name आणि TLS (transport layer security) आवश्यक आहे. तसेच तुमच्या server बद्दल कधीही ऐकले नसलेल्या लोकांपर्यंतही त्याने mail पोहोचवले पाहिजे.

चार projects या वास्तववादी पर्यायांमध्ये येतात. Cal.com हे Calendly शी सर्वाधिक जुळते आणि solo consultant साठी default पर्याय आहे. Easy!Appointments हा हलका पर्याय आहे. तो PHP आणि MySQL वर चालतो आणि 1 GB VPS वर सहज काम करतो. Rallly हे group poll tool आहे आणि त्यात booking page अजिबात नाही. DayOtter हा सर्वांत नवीन पर्याय आहे. हा AGPLv3 scheduling platform असून त्यासमोर confirm-first assistant आहे.

तुम्ही प्रत्यक्षात कोणता पर्याय चालवू शकता हे दोन प्रश्न ठरवतात. तुम्ही आधीपासून वापरत असलेल्या calendar सोबत तो दोन्ही दिशांनी sync करतो का? आणि तो mail पाठवू शकतो का? बहुतेक self-hosted booking setups याच दुसऱ्या प्रश्नामुळे शांतपणे अपयशी ठरतात. म्हणून त्याच्यापासून सुरुवात केली आहे.

बाहेर जाणारा ईमेल हा अपयशी ठरणारा भाग आहे

बुकिंगची पुष्टी एखाद्या अनोळखी व्यक्तीच्या inbox मध्ये जाते. हा transactional mail Gmail किंवा Microsoft 365 वर पोहोचतो. हे प्राप्तकर्ता तुमचे मूल्यांकन sending IP address आणि तुमच्या DNS records वर करतात.

VPS वरून थेट ईमेल पाठवणे जवळजवळ कधीही काम करत नाही. बहुतेक providers नवीन accounts साठी outbound TCP port 25 block करतात. त्यामुळे connection hang होतो आणि नंतर timeout होतो. port 25 उघडा असला तरी नवीन VPS address चा sending history नसतो. मोठे प्राप्तकर्ता unknown hosting-range addresses संशयास्पद मानतात. बुकिंग database मध्ये लिहिले जाते, page वर confirmed दिसते, पण कोणालाही ईमेल मिळत नाही. Server side वर काहीही बिघडलेले दिसत नाही. त्यामुळे ग्राहक उपस्थित न राहिल्याचे कळल्यावर अनेक आठवड्यांनी ही समस्या सापडते.

Relay वापरा. कोणताही transactional mail provider चालतो. अॅपला फक्त hostname, port, user आणि password आवश्यक असतात. Application config बदलण्यापूर्वी port reachable आहे का ते तपासा:

nc -vz -w 5 "$SMTP_HOST" 587

succeeded line दिसत असल्यास मार्ग खुला आहे. hang किंवा Connection refused म्हणजे network level वर port blocked आहे. .env संपादित केल्याने ही समस्या सुटणार नाही. Relays 587 किंवा 465 वर listen करतात, कारण 25 वारंवार blocked असतो.

प्रत्येक project relay वेगळ्या पद्धतीने वापरतो. Cal.com EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER आणि EMAIL_SERVER_PASSWORD वाचतो. तो त्याऐवजी RESEND_API_KEY देखील स्वीकारतो. याकडे लक्ष द्या: shipped .env.example, port 1025 वरील localhost कडे EMAIL_SERVER_HOST निर्देशित करतो. हा local development mailbox आहे. Default तसाच ठेवल्यास अॅप कोणतीही error न देता ईमेल कुठेही पाठवत नाही. Rallly SMTP_HOST, SMTP_PORT, SMTP_USER आणि SMTP_PWD घेतो. DayOtter SMTP settings किंवा Resend key घेतो. Easy!Appointments आपली notifications application मधून पाठवते. त्यामुळे प्रत्यक्ष booking स्वीकारण्यापूर्वी settings page मधून ते त्याच relay कडे निर्देशित करा.

त्यानंतर relay ने दिलेली DNS records publish करा. SPF (sender policy framework) record तुमच्या domain साठी कोणते servers ईमेल पाठवू शकतात हे सांगतो. DKIM (domainkeys identified mail) key प्रत्येक message वर स्वाक्षरी करते, त्यामुळे तो बदललेला नाही हे प्राप्तकर्ता पडताळू शकतो. दोन्ही पडताळण्या यशस्वी झाल्यावर DMARC (domain-based message authentication, reporting and conformance) policy जोडा. मोठ्या provider वरील प्रत्यक्ष address वर test booking पाठवा. Message headers उघडा आणि authentication lines मध्ये pass दिसत असल्याची खात्री करा. ईमेल पाठवता न येणारे booking page नसलेल्या booking page पेक्षा अधिक वाईट असते, कारण ते कोणतीही error न दाखवता अपयशी ठरते.

कोणते calendar backend खरोखर दोन्ही दिशेने sync करतात

Sync ला दोन दिशा असतात आणि त्या स्वतंत्रपणे अपयशी ठरतात. Read दिशा म्हणजे availability: अॅपला तुमचे आधीपासूनचे busy blocks दिसले पाहिजेत. अन्यथा तुम्ही आधीच व्यस्त असलेला वेळ ते उपलब्ध म्हणून देईल. Write दिशा म्हणजे booking: confirmed event तुम्ही प्रत्यक्ष पाहत असलेल्या calendar वर दिसला पाहिजे. तो फक्त booking tool मध्ये दिसणे पुरेसे नाही.

Google Calendar आणि Microsoft 365 दोन्ही दिशेने sync करतात. मात्र self-hosted install साठी एक अट आहे. OAuth (open authorization) client तुम्हालाच तयार करावा लागतो, कारण hosted product चा client ID source code मध्ये नसतो. Cal.com साठी JSON तुम्ही Google Cloud console मधून download करून GOOGLE_API_CREDENTIALS मधील .env मध्ये ठेवता. DayOtter मध्येही Google आणि Microsoft OAuth credentials याच पद्धतीने घेतले जातात.

या ठिकाणी दोन समस्या येतात. सुरुवात करण्यापूर्वी दोन्ही समजून घेणे उपयुक्त आहे. प्रथम, तुम्ही नोंदवलेला redirect URI public URL शी अचूक जुळला पाहिजे. त्यात scheme आणि शेवटचा path असल्यास तोही समाविष्ट असला पाहिजे. अन्यथा consent screen वर Google redirect_uri_mismatch सह connection थांबवते. दुसरे म्हणजे, Testing publishing status मध्ये ठेवलेला Google project सात दिवसांनी expire होणारे refresh tokens जारी करतो. संपूर्ण आठवडा sync चालते आणि त्यानंतर थांबते. पुढील refresh वेळी app logs मध्ये invalid_grant दिसते. Consent screen In production वर हलवा. किंवा प्रत्येक सोमवारी manually reconnect करणे स्वीकारा.

CalDAV (WebDAV साठी calendaring extensions) हा open पर्याय आहे. मात्र त्याचे support अधिक मर्यादित आहे. Cal.com मध्ये CalDAV app उपलब्ध आहे. त्यावर अजून beta असा उल्लेख आहे. Baikal, Radicale, Nextcloud आणि Kerio Connect यांसह अनेक servers वर त्याची पडताळणी केली आहे. Apple iCloud त्याच app द्वारे चालते. मात्र त्यासाठी Apple ID password ऐवजी app-specific password आवश्यक आहे. DayOtter मध्ये Google आणि Microsoft 365 सोबत Apple via CalDAV देखील सूचीबद्ध आहे.

ICS feed म्हणजे sync नाही. Subscribe केलेली .ics URL रचनेनुसार read-only असते. त्यामुळे ती तुमच्या booking page वर वेळ busy दाखवू शकते. मात्र booking कधीही त्यावर पाठवू शकत नाही. एखादे tool तुमच्या calendar साठी फक्त ICS देत असेल, तर तुमची व्यवस्था अर्धवट आहे. Events अजूनही manually copy करावे लागतील.

Easy!Appointments फक्त Google Calendar सोबत sync करते. Rallly availability वाचतच नाही. ते संभाव्य dates च्या संचावर votes गोळा करते. “आम्हा सहा जणांना कधी भेटता येईल” यासाठी ते योग्य tool आहे. “माझ्यासोबत 30 मिनिटांची booking करा” यासाठी ते अयोग्य tool आहे.

बुकिंग पृष्ठ सार्वजनिक असते, त्यामुळे TLS ला प्राधान्य द्या

स्वतः होस्ट केलेल्या बहुतेक सेवा खाजगी असतात. Wiki, board किंवा dashboard यांसारख्या सेवा VPN किंवा SSO login मागे ठेवता येतात आणि त्यांना उघड्या इंटरनेटवर कधीही उपलब्ध करून द्यावे लागत नाही. Booking link तसा नसतो. तुम्ही तो ज्याला पाठवाल, त्याला तो उघडता आला पाहिजे. त्यामुळे रचनेत तीन ठोस बदल होतात.

काहीही install करण्यापूर्वी VPS कडे निर्देश करणारा A record असलेले domain name आवश्यक आहे. पहिल्याच दिवसापासून certificate आवश्यक आहे, कारण browsers साध्या HTTP form ला सुरक्षित नसल्याचे दाखवतात आणि तुमचा client त्यात त्याचे नाव आणि email लिहितो. तसेच अॅपची public URL त्याच्या config मध्ये योग्यरीत्या सेट करणे आवश्यक आहे, कारण outgoing email मधील links आणि OAuth redirect URIs मध्ये ही value समाविष्ट केली जाते. Cal.com मध्ये NEXT_PUBLIC_WEBAPP_URL, Rallly मध्ये DOMAIN, Easy!Appointments मध्ये BASE_URL किंवा install वेळी DAYOTTER_DOMAIN सेट करा आणि तुम्ही प्रत्यक्षात वापरणार असलेल्या https:// address वर ती सेट करा.

Rallly आणि DayOtter तुमच्यासाठी TLS व्यवस्थापित करतात. Rallly च्या bundled stack मध्ये Traefik समाविष्ट आहे आणि ACME_EMAIL मधील address वापरून ते Let's Encrypt certificates जारी करते. DayOtter चा installer automatic HTTPS सह Caddy सुरू करतो. Cal.com आणि Easy!Appointments मध्ये ही सुविधा नाही. त्यामुळे nginx समोर ठेवून certificate स्वतः जारी करावे लागते. हे nginx वर Certbot वापरून Let's Encrypt certificate मिळवण्याप्रमाणे आहे. अॅप 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 करण्याऐवजी 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 सेट करा आणि NEXT_PUBLIC_WEBAPP_URL ला तुमच्या public address कडे निर्देशित करा. Bundled stack मध्ये web app, PostgreSQL आणि Prisma Studio आहेत. तुम्ही स्वतः host केलेल्या database विरुद्ध फक्त app चालवण्यासाठी documentation मध्ये docker compose up -d calcom दिले आहे. Installation स्थिर झाल्यानंतर तुम्हाला हाच पर्याय हवा असेल.

Image pull करा. VPS वर ती build करू नका. Source मधून build करताना project च्या सूचनांनुसार NODE_OPTIONS="--max-old-space-size=16384" export करावे लागते. यासाठी फक्त Node ला 16 GB heap लागतो. ARM hardware वर image tag ला -arm suffix जोडा. Prebuilt image चालवण्यासाठी project ने कोणतीही minimum requirement प्रकाशित केलेली नाही. त्यामुळे app आणि PostgreSQL साठी 2 GB हा documented आकडा नसून माझ्या वापरातील अंदाज समजा. पहिल्या आठवड्यात memory वर लक्ष ठेवा.

ते सुरू झाले आहे का ते तपासा:

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 अजून लागू होत असण्याची शक्यता असते. ते broken आहे असा निष्कर्ष काढण्यापूर्वी काही मिनिटे थांबा आणि logs वाचा. Cal.com चे webhooks प्रत्येक confirmed booking वर trigger होतात. त्यामुळे booking मुळे तुम्ही आधीपासून चालवत असलेले automation सुरू होऊ शकते. उदाहरणार्थ, तुमच्या VPS वर HTTPS द्वारे उपलब्ध असलेले n8n instance.

Core AGPLv3 अंतर्गत आहे. काही features स्वतंत्र commercial licence अंतर्गत enterprise directory मध्ये ठेवलेली आहेत. Team features वर आधारित paid business process तयार करण्यापूर्वी ती licence वाचा.

1 GB सर्व्हरवर Easy!Appointments

आवश्यकता म्हणून Apache किंवा Nginx, PHP 8.2 किंवा त्याहून नवीन आवृत्ती आणि MySQL आवश्यक आहेत. अधिकृत image alextselegidis/easyappointments येथे उपलब्ध आहे.

प्रथम एक महत्त्वाची सूचना. Repository मधील docker-compose.yml हे development environment आहे. त्यामध्ये container मध्ये shell उघडून npm install && composer install && npm start चालवणे अपेक्षित आहे. हे deployment नाही. त्याऐवजी प्रकाशित 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 हा सार्वजनिक HTTPS पत्ता असणे आवश्यक आहे. तो चुकीचा दिल्यास confirmation email मधील booking links अशा host कडे निर्देश करतील, ज्यापर्यंत तुमचा client पोहोचू शकत नाही. Image कोणतेही स्वतःचे certificate न वापरता port 80 वर साधे HTTP पुरवते. म्हणूनच port 127.0.0.1 शी bind केला आहे आणि समोर nginx TLS termination करते. Compose syntax तुमच्यासाठी नवीन असल्यास, VPS वरील Docker Compose ची मूलतत्त्वे पासून सुरुवात करा आणि नंतर येथे परत या.

येथील पर्यायांमध्ये हा सर्वांत हलका पर्याय आहे. PHP application आणि MySQL असलेले दोन containers 1 GB VPS वर सहजपणे चालतात. मात्र याची कार्यक्षमता मर्यादित आहे: Google Calendar हा एकमेव calendar backend आहे आणि interface आधुनिक booking flow ऐवजी पारंपरिक admin panel आहे. तुमचे calendar Microsoft 365, Fastmail किंवा Nextcloud असल्यास, सुरुवातीपासूनच हा पर्याय वगळा.

गट मतदानासाठी Rallly

Rallly वेगळ्या प्रश्नाचे उत्तर देते. ते तुमची उपलब्धता प्रकाशित करत नाही. ते संभाव्य वेळांची यादी गटासमोर ठेवते आणि मते गोळा करते. बोर्ड बैठकीसाठी हेच आवश्यक आहे; मात्र क्लायंटसाठी booking link देताना याचा उपयोग नाही.

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

कोणतीही script shell मध्ये pipe करण्यापूर्वी ती वाचा. bash ऐवजी less वापरा, ती काय करते ते समजून घ्या आणि त्यानंतर चालवा. Manual पद्धतीत हेच काम तुम्हाला दिसतील अशा टप्प्यांमध्ये केले जाते:

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

दस्तऐवजीकरणानुसार किमान 2 GB RAM, Compose v2 सह Docker 19.03 किंवा त्यानंतरची आवृत्ती, मोकळे ports 80 आणि 443, तसेच server कडे निर्देश करणारा domain आवश्यक आहे. या bundled stack मध्ये HTTPS साठी Traefik, web application, PostgreSQL आणि S3-compatible object storage साठी Garage समाविष्ट आहेत. DOMAIN, किमान 32 characters लांबीचा SECRET_PASSWORD, SUPPORT_EMAIL आणि INITIAL_ADMIN_EMAIL सेट करा. तुम्ही आधीच reverse proxy चालवत असल्यास PROXY_MODE=external आणि WEB_PORT सेट करा. त्यामुळे Traefik मध्ये हस्तक्षेप करणार नाही. तुम्ही आधीच self-hosted S3-compatible object store म्हणून MinIO चालवत असल्यास S3_* variables त्याकडे निर्देशित करा आणि Garage container काढून टाका.

येथे SMTP ऐच्छिक नाही, कारण sign-in साठी magic link वापरला जातो. कार्यरत relay नसल्यास कोणीही login करू शकणार नाही, अगदी तुम्ही नुकतेच तयार केलेले admin account देखील नाही. Email अपयशाची ही चांगली बाजू आहे: ते तुम्हाला सुरुवातीलाच थांबवते, तीन आठवड्यांनंतर client ची booking गमावण्यापेक्षा.

DayOtter, सर्वात नवीन पर्याय

DayOtter हे assistant जोडलेले AGPLv3 scheduling platform आहे. Production install करण्यासाठी एकच command आहे:

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

वरीलप्रमाणे, command चालवण्यापूर्वी तो वाचा. Installer Docker सेट अप करतो, secrets तयार करतो आणि संपूर्ण stack सुरू करतो: Next.js web app, reminders, calendar sync आणि webhooks हाताळणारा background worker, PostgreSQL, Redis आणि automatic HTTPS असलेला Caddy.

या चार पर्यायांपैकी calendar support सर्वाधिक व्यापक आहे. Google, Microsoft 365, CalDAV द्वारे Apple आणि ICS feeds उपलब्ध आहेत. मात्र ICS बाबत वर नमूद केलेली मर्यादा लागू आहे. इतर सर्व integrations environment variables द्वारे opt-in आहेत. यामध्ये mail साठी SMTP किंवा Resend, assistant साठी ANTHROPIC_API_KEY, SMS साठी Twilio आणि payments साठी Stripe यांचा समावेश आहे. Assistant confirm-first पद्धतीने काम करतो: तो प्रस्ताव देतो, तुम्ही मंजुरी देता आणि स्पष्ट होकाराशिवाय काहीही तुमच्या calendar मध्ये जोडले जात नाही. API key रिकामी ठेवल्यास product चा हा भाग कार्यरत होत नाही.

Self-hosters साठी licensing स्पष्ट आहे. Core AGPLv3 अंतर्गत आहे. ee/ directory मध्ये commercial cloud-only licence आहे. DAYOTTER_CLOUD=1 सेट केल्याशिवाय ती licence निष्क्रिय राहते. त्यामुळे hosted plan मध्ये $9 प्रति seat दरमहा आकारली जाणारी team features, August 2026 पर्यंतच्या माहितीनुसार, तुमच्या स्वतःच्या server वर उपलब्ध आहेत.

हा या यादीतील सर्वाधिक मोठा stack आणि सर्वात नवीन project देखील आहे. तुमच्या विद्यमान booking link च्या शेजारी तो दोन आठवडे चालवा. दोन्ही माध्यमांतून प्रत्यक्ष bookings घ्या. Clients स्थलांतरित करण्यापूर्वी worker logs तपासा.

या प्रत्येक stack साठी प्रत्यक्षात किती संसाधने लागतात

लहान VPS वर एखादा stack किती संसाधने मागेल, याचा प्रामाणिक अंदाज container count वरून येतो, कारण प्रत्येक सेवेसाठी किमान memory वेगळी राखावी लागते. खालील संख्या प्रत्येक प्रकल्पाने प्रकाशित केलेल्या स्वतःच्या Docker stack मधून घेतल्या आहेत. ही माहिती 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 ला 2 containers लागतात आणि ते 1 GB मध्ये चालते. Rallly च्या bundled stack मध्ये 4 containers आहेत आणि त्याच्या documentation मध्ये 2 GB आवश्यक असल्याचे नमूद केले आहे. DayOtter चा installer 5 containers सुरू करतो. त्यामुळे येथे दिलेल्या 4 पर्यायांमध्ये त्याला सर्वांत मोठा VPS आवश्यक आहे. Cal.com आणि DayOtter यांनी किमान memory ची कोणतीही संख्या प्रकाशित केलेली नाही. त्यामुळे दोन्हीसाठी मी 2 GB पासून सुरुवात करतो; हा समर्थित आकडा नाही.

तुम्ही infrastructure आधीपासून चालवत असल्यास, यापैकी दोन counts कमी होतात. Rallly ला स्वतःच्या proxy आणि object storage कडे निर्देशित केल्यावर त्याचे Traefik आणि Garage containers काढता येतात. Cal.com चे Prisma Studio हे development tool आहे. ते सार्वजनिक server वर सुरू ठेवू नये.

तुम्ही कोणता self-hosted Calendly पर्याय निवडावा

एकट्या सल्लागाराने Cal.com चालवावे. ओळखीचे booking page, तुमच्या VPS वर Node build करण्याची गरज टाळणाऱ्या prebuilt images आणि Google किंवा Microsoft वर calendar न ठेवणाऱ्या वापरकर्त्यांसाठी CalDAV मार्ग, ही तिन्ही वैशिष्ट्ये एकत्र देणारा या यादीतील हा एकमेव project आहे. एक PostgreSQL database आणि एक application container यांचा maintenance भार अनेक वर्षे सांभाळता येतो. OAuth client आणि mail relay साठी एका दुपारचा वेळ राखून ठेवा. CalDAV app अजून beta मध्ये आहे, त्यामुळे link publish करण्यापूर्वी एक प्रत्यक्ष booking सुरुवातीपासून शेवटपर्यंत तपासा.

लहान टीमने DayOtter चा विचार करावा. Weighted round robin आणि collective booking ही वैशिष्ट्ये AGPLv3 core मध्येच आहेत. त्यामुळे self-hosting केल्यास hosted seat साठी शुल्क आकारली जाणारी वैशिष्ट्ये मिळतात. Worker process टीम प्रत्यक्षात वापरत असलेल्या reminders आणि webhooks साठी तयार केलेला आहे. मात्र त्याची maturity कमी आहे. या यादीतील हा सर्वात नवीन project आहे. त्यामुळे सुरुवातीला तो parallel मध्ये चालवा आणि bookings चा पूर्ण महिना निरीक्षणात घेतल्याशिवाय जुना link बंद करू नका.

दोन अधिक विशिष्ट परिस्थिती आहेत. समूहाला भेटण्यासाठी योग्य वेळ शोधण्यासाठी फक्त poll आवश्यक असेल, तर Rallly install करून थांबा. तुमच्याकडे 1 GB VPS असेल, तुम्ही Google Calendar वापरत असाल आणि booking स्वीकारणारी सर्वात लहान system हवी असेल, तर त्या VPS वर तुम्ही install करू शकणाऱ्या अधिक गुंतागुंतीच्या प्रत्येक पर्यायापेक्षा Easy!Appointments अधिक काळ टिकेल. त्याच server वर आणखी कोणत्या सेवा self-host करणे योग्य आहे, या व्यापक प्रश्नासाठी 2026 मध्ये self-host करणे योग्य काय आहे हे पहा.

FAQ

मी domain name शिवाय self-hosted booking page चालवू शकतो का?

नाही. या सर्व अॅप्स confirmation emails मधील links मध्ये public URL लिहितात. Google आणि Microsoft दोन्ही OAuth redirect URI ची तुलना त्याच मूल्याशी करतात. त्यामुळे bare IP address वापरल्यास consent screen वर redirect_uri_mismatch दिसते. Let's Encrypt IP address साठी certificate जारी करत नाही. त्यामुळे page plain HTTP वर लोड होते आणि browser form ला secure नसल्याचे दर्शवतो. आधी domain खरेदी करा. VPS कडे A record निर्देशित करा. त्यानंतर installation करा.

माझे booking confirmation emails कधीच का पोहोचत नाहीत?

बहुतेक वेळा server स्वतःच mail deliver करण्याचा प्रयत्न करत असतो. बहुतेक VPS providers नवीन accounts साठी outbound port 25 block करतात. त्यामुळे connection अडकते. Port खुला असला तरी नवीन address ची sending reputation नसते आणि मोठे 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 बदलले आहेत का ते तपासा. हे defaults local development mailbox कडे निर्देश करतात.

self-hosted Cal.com CalDAV सोबत sync होते का, की फक्त Google सोबत?

दोन्हींसोबत sync होते, परंतु maturity वेगवेगळी आहे. CalDAV app beta म्हणून चिन्हांकित आहे. त्याची Baikal, Radicale, Nextcloud आणि Kerio Connect यांसह अनेक servers विरुद्ध पडताळणी झाली आहे. Apple iCloud देखील app-specific password वापरून त्याद्वारे कार्य करते. Google Calendar आणि Microsoft 365 दोन्ही दिशांनी sync करतात. मात्र self-hosted install मध्ये स्वतःचा OAuth client तयार करून तो GOOGLE_API_CREDENTIALS द्वारे द्यावा लागतो. Hosted service ची credentials source मध्ये उपलब्ध नाहीत.

एका आठवड्यानंतर माझे Google Calendar sync का थांबते?

कारण Google Cloud project अजून Testing publishing status मध्ये आहे. या status मधील apps साठी Google refresh tokens जारी करते, पण ते सात दिवसांनी expire होतात. त्यामुळे connection सुरुवातीला कार्य करते, नंतर पुढील token refresh वेळी थांबते आणि application log मध्ये invalid_grant दिसते. OAuth consent screen In production वर हलवा आणि calendar एकदा पुन्हा connect करा. Status न बदलता पुन्हा connect केल्यास आणखी सात दिवस मिळतात; त्यापेक्षा अधिक नाही.

यापैकी कोणते 1 GB VPS वर चालेल?

Easy!Appointments चालेल, कारण ते MySQL सोबतचे PHP application आहे. Rallly मध्ये 2 GB minimum requirement नमूद आहे आणि त्याचा bundled stack चार services चालवतो. Cal.com आणि DayOtter कोणतीही minimum requirement प्रकाशित करत नाहीत. मात्र PostgreSQL सोबतचे Next.js application, तसेच DayOtter मध्ये Redis आणि worker process असल्यामुळे, तुम्ही 2 GB किंवा त्याहून अधिक memory ची योजना करावी. लहान server वर Cal.com source मधून कधीही build करू नका. Project च्या स्वतःच्या build instructions मध्ये 16 GB Node heap आवश्यक असल्याचे नमूद आहे. त्याऐवजी prebuilt image वापरा.