ఉత్తమ సెల్ఫ్-హోస్టెడ్ Calendly ప్రత్యామ్నాయాలు

క్లుప్త సమాధానం

మీరు స్వయంగా హోస్ట్ చేసుకునే Calendly ప్రత్యామ్నాయం, మీ VPS లోని ఇతర అంతర్గత సాధనాలు చేయని ఒక పనిని చేయాలి: అది బహిరంగంగా అందుబాటులో ఉండాలి. బుకింగ్ పేజీయే అసలైన ఉత్పత్తి. దీనికి మొదటి రోజు నుంచే ఒక సరైన domain name మరియు TLS (transport layer security) అవసరం. అలాగే, మీ సర్వర్ గురించి ఏమాత్రం తెలియని వ్యక్తులకు ఇది ఇమెయిల్ పంపగలగాలి.

వాస్తవిక అవసరాలను తీర్చే నాలుగు ప్రాజెక్టులు ఇక్కడ ఉన్నాయి. Cal.com అనేది Calendly కి అత్యంత దగ్గరగా ఉంటుంది మరియు స్వతంత్ర కన్సల్టెంట్లకు ఇది ప్రాథమిక ఎంపిక. Easy!Appointments అనేది తేలికైనది; ఇది PHP మరియు MySQL లపై ఆధారపడి, 1 GB VPS లో కూడా సమర్థవంతంగా పనిచేస్తుంది. Rallly అనేది గ్రూప్ పోల్ సాధనం, దీనికి బుకింగ్ పేజీ ఉండదు. DayOtter అనేది కొత్తగా వచ్చిన AGPLv3 షెడ్యూలింగ్ ప్లాట్‌ఫారమ్, దీని ముందు భాగంలో 'confirm-first' అసిస్టెంట్ ఉంటుంది.

మీరు దేనిని అమలు చేయగలరో నిర్ణయించడానికి రెండు ప్రశ్నలు కీలకం. మీరు ఇప్పటికే వాడుతున్న క్యాలెండర్‌తో ఇది రెండు వైపులా (two-way) సింక్ అవుతుందా? మరియు ఇది ఇమెయిల్ పంపగలదా? రెండవ ప్రశ్న వద్దే చాలా వరకు self-hosted బుకింగ్ సెటప్‌లు విఫలమవుతాయి, కాబట్టి దానికే మొదటి ప్రాధాన్యత ఇవ్వాలి.

అవుట్‌బౌండ్ ఈమెయిల్ విఫలమవ్వడం

బుకింగ్ కన్ఫర్మేషన్ తెలియని వ్యక్తి ఇన్‌బాక్స్‌కు వెళ్తుంది. ఇది Gmail లేదా Microsoft 365 వంటి వాటికి పంపే transactional mail. ఈ స్వీకర్తలు మీ sending IP అడ్రస్ మరియు DNS రికార్డుల ఆధారంగా మీ విశ్వసనీయతను అంచనా వేస్తారు.

VPS నుండి నేరుగా మెయిల్ పంపడం దాదాపు ఎప్పుడూ పని చేయదు. చాలా ప్రొవైడర్లు కొత్త ఖాతాలపై అవుట్‌బౌండ్ TCP port 25 ను బ్లాక్ చేస్తారు, కాబట్టి కనెక్షన్ హ్యాంగ్ అయ్యి టైమ్ అవుట్ అవుతుంది. ఒకవేళ port 25 తెరిచి ఉన్నా, కొత్త VPS అడ్రస్‌కు పంపిన చరిత్ర ఉండదు. పెద్ద మెయిల్ ప్రొవైడర్లు తెలియని హోస్టింగ్-రేంజ్ అడ్రస్‌లను అనుమానాస్పదంగా పరిగణిస్తాయి. బుకింగ్ డేటాబేస్‌లో నమోదవుతుంది, పేజీ కన్ఫర్మ్ అని చూపిస్తుంది, కానీ ఎవరికీ ఈమెయిల్ అందదు. సర్వర్ వైపు ఏదీ విఫలమైనట్లు కనిపించదు, అందుకే క్లయింట్ రానప్పుడు వారాల తర్వాత ఈ సమస్య బయటపడుతుంది.

ఒక relay ఉపయోగించండి. ఏదైనా transactional mail ప్రొవైడర్ పనిచేస్తుంది. అప్లికేషన్‌కు కేవలం hostname, port, user మరియు password మాత్రమే అవసరం. అప్లికేషన్ కాన్ఫిగరేషన్ మార్చే ముందు port అందుబాటులో ఉందో లేదో తనిఖీ చేయండి:

nc -vz -w 5 "$SMTP_HOST" 587

succeeded లైన్ అంటే మార్గం తెరిచి ఉందని అర్థం. హ్యాంగ్ అవ్వడం లేదా Connection refused అంటే నెట్‌వర్క్ స్థాయిలో port బ్లాక్ చేయబడిందని అర్థం. .env ను ఎంత ఎడిట్ చేసినా ఇది పరిష్కారం కాదు. port 25 తరచుగా బ్లాక్ చేయబడుతుంది కాబట్టే relays 587 లేదా 465 పోర్టులలో వింటాయి.

ప్రతి ప్రాజెక్ట్ 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 ను సెట్ చేయండి.

ఆ తర్వాత మీ relay ఇచ్చే DNS రికార్డులను పబ్లిష్ చేయండి. SPF (sender policy framework) రికార్డ్ మీ డొమైన్ తరపున ఏ సర్వర్లు మెయిల్ పంపవచ్చో చెబుతుంది. DKIM (domainkeys identified mail) కీ ప్రతి సందేశాన్ని సంతకం చేస్తుంది, తద్వారా సందేశం మార్చబడలేదని స్వీకర్త నిర్ధారించుకోవచ్చు. రెండూ పూర్తయ్యాక DMARC (domain-based message authentication, reporting and conformance) పాలసీని జోడించండి. ఒక పెద్ద ప్రొవైడర్‌లోని నిజమైన అడ్రస్‌కు టెస్ట్ బుకింగ్ పంపి, మెసేజ్ హెడర్లను తెరిచి, అథెంటికేషన్ లైన్లు pass అని ఉన్నాయో లేదో నిర్ధారించుకోండి. మెయిల్ పంపలేని బుకింగ్ పేజీ అసలు బుకింగ్ పేజీ లేకపోవడం కంటే ప్రమాదకరం, ఎందుకంటే ఇది నిశ్శబ్దంగా విఫలమవుతుంది.

ఏ క్యాలెండర్ బ్యాకెండ్‌లు నిజంగా రెండు వైపులా (two-way) సింక్ అవుతాయి

సింక్ ప్రక్రియ రెండు దిశలలో జరుగుతుంది మరియు అవి విడివిడిగా విఫలం కావచ్చు. రీడ్ (read) దిశ అనేది లభ్యతకు (availability) సంబంధించినది: అప్లికేషన్ మీ ప్రస్తుత బిజీ బ్లాక్‌లను చూడాలి, లేకపోతే మీరు ఇప్పటికే బిజీగా ఉన్న సమయాన్ని కూడా అది ఖాళీగా చూపిస్తుంది. రైట్ (write) దిశ అనేది బుకింగ్ ప్రక్రియకు సంబంధించినది: నిర్ధారించబడిన ఈవెంట్ కేవలం బుకింగ్ టూల్‌లోనే కాకుండా, మీరు వాడే క్యాలెండర్‌లో కూడా కనిపించాలి.

Google Calendar మరియు Microsoft 365 ఈ రెండు దిశలలో పనిచేస్తాయి, అయితే self-hosted ఇన్‌స్టాలేషన్‌లో ఒక నిబంధన ఉంది. మీరు OAuth (open authorization) క్లయింట్‌ను మీరే సృష్టించుకోవాలి, ఎందుకంటే హోస్ట్ చేసిన ప్రోడక్ట్ యొక్క క్లయింట్ ID సోర్స్ కోడ్‌లో ఉండదు. Cal.com కోసం ఇది GOOGLE_API_CREDENTIALS, ఇది .env లో ఉంటుంది; ఇందులో మీరు Google Cloud కన్సోల్ నుండి డౌన్‌లోడ్ చేసిన JSON ఉంటుంది. 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 పాస్‌వర్డ్ కాకుండా, యాప్-నిర్దిష్ట పాస్‌వర్డ్ (app-specific password) అవసరం. DayOtter తన జాబితాలో Apple ను CalDAV ద్వారా Google మరియు Microsoft 365 పక్కన చూపిస్తుంది.

ICS ఫీడ్ అనేది సింక్ కాదు. సబ్‌స్క్రయిబ్ చేసుకున్న .ics URL డిజైన్ ప్రకారం కేవలం రీడ్-ఓన్లీ (read-only) మాత్రమే. కాబట్టి ఇది మీ బుకింగ్ పేజీలో సమయాన్ని బ్లాక్ చేయగలదు కానీ, బుకింగ్‌ను స్వీకరించలేదు. ఒక టూల్ మీ క్యాలెండర్ కోసం కేవలం ICS మాత్రమే అందిస్తే, మీకు సగం సౌకర్యం మాత్రమే ఉన్నట్లు లెక్క, మీరు ఈవెంట్లను మాన్యువల్‌గా కాపీ చేసుకోవాల్సిందే.

Easy!Appointments కేవలం Google Calendar ను మాత్రమే సింక్ చేస్తుంది, వేరే దేనినీ చేయదు. Rallly అసలు లభ్యతను (availability) చదవదు: ఇది కేవలం కొన్ని తేదీల ఎంపికలపై ఓట్లను సేకరిస్తుంది. "మన ఆరుగురం ఎప్పుడు కలవవచ్చు" అనే ప్రశ్నకు ఇది సరైన టూల్, కానీ "నాతో 30 నిమిషాలు బుక్ చేసుకోండి" అనే అవసరానికి ఇది సరైనది కాదు.

బుకింగ్ పేజీ పబ్లిక్‌గా ఉంటుంది, కాబట్టి TLS ప్రాధాన్యత కలిగి ఉంటుంది

చాలా వరకు ప్రజలు self-host చేసుకునేవి ప్రైవేట్‌గా ఉంటాయి. ఒక వికీ, బోర్డు, డాష్‌బోర్డ్ వంటివి VPN లేదా SSO లాగిన్ వెనుక ఉండి, ఇంటర్నెట్‌కు కనిపించకుండా ఉండవచ్చు. కానీ బుకింగ్ లింక్ అలా ఉండకూడదు. మీరు ఎవరికి పంపినా వారు దానిని లోడ్ చేయాల్సి ఉంటుంది, ఇది మీ సెటప్‌ను మూడు విధాలుగా మారుస్తుంది.

ఏదైనా ఇన్‌స్టాల్ చేసే ముందే, VPS కి పాయింట్ చేసిన A record తో కూడిన డొమైన్ నేమ్ మీకు ఉండాలి. మొదటి రోజే మీకు సర్టిఫికేట్ అవసరం, ఎందుకంటే సాధారణ HTTP ఫారమ్‌లను బ్రౌజర్‌లు సురక్షితం కాదని గుర్తిస్తాయి మరియు మీ క్లయింట్ అందులో వారి పేరు, ఈమెయిల్ నమోదు చేస్తారు. అలాగే, అప్లికేషన్ యొక్క పబ్లిక్ URL ను దాని కాన్ఫిగరేషన్‌లో సరిగ్గా సెట్ చేయాలి, ఎందుకంటే ఆ విలువ బయటకు వెళ్లే ఈమెయిల్‌లోని లింక్‌లలో మరియు OAuth రీడైరెక్ట్ URIలలో ఉంటుంది. Cal.com లో NEXT_PUBLIC_WEBAPP_URL ను, Rallly లో DOMAIN ను, Easy!Appointments లో BASE_URL ను లేదా ఇన్‌స్టాల్ చేసే సమయంలో DAYOTTER_DOMAIN ను సెట్ చేయండి, మరియు మీరు నిజంగా ఉపయోగించబోయే https:// అడ్రస్‌ను దానికి కేటాయించండి.

Rallly మరియు DayOtter మీ కోసం TLS సమస్యను పరిష్కరిస్తాయి. Rallly యొక్క బండిల్డ్ స్టాక్‌లో Traefik ఉంటుంది మరియు అది ACME_EMAIL లోని అడ్రస్‌ను ఉపయోగించి Let's Encrypt సర్టిఫికేట్‌లను జారీ చేస్తుంది. DayOtter ఇన్‌స్టాలర్ ఆటోమేటిక్ HTTPS తో Caddy ని సిద్ధం చేస్తుంది. Cal.com మరియు Easy!Appointments అలా చేయవు, కాబట్టి మీరు ముందుగా nginx ని ఉంచి, మీరే సర్టిఫికేట్‌ను జారీ చేయాలి. ఇది nginx పై Certbot తో Let's Encrypt సర్టిఫికేట్ పొందే విధానం లాగే ఉంటుంది. అప్లికేషన్ కంటైనర్‌ను 127.0.0.1 కి బైండ్ చేయండి, తద్వారా మీరు నియంత్రించే ప్రాక్సీ ద్వారా మాత్రమే లోపలికి ప్రవేశం ఉంటుంది. ఒకవేళ అదే సర్వర్‌లో ఇప్పటికే మీ అంతర్గత బోర్డుల కోసం self-hosted Trello ప్రత్యామ్నాయం నడుస్తుంటే, దానిని మీ ప్రస్తుత అథెంటికేషన్ వెనుక ఉంచి, బుకింగ్ హోస్ట్‌కు మాత్రమే పబ్లిక్ సర్వర్ బ్లాక్‌ను కేటాయించండి.

మీ VPSలో Cal.com

Docker కాన్ఫిగరేషన్ దాని స్వంత రిపోజిటరీలో ఉంటుంది మరియు 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 విలువను NEXTAUTH_SECRETలో మరియు రెండవ దానిని CALENDSO_ENCRYPTION_KEYలో ఉంచండి. రెండూ తప్పనిసరి. DATABASE_URLని సెట్ చేయండి మరియు NEXT_PUBLIC_WEBAPP_URLని మీ public address వైపు మళ్లించండి. ఈ bundled stackలో web app, PostgreSQL మరియు Prisma Studio ఉంటాయి; మీరు వేరే చోట host చేసిన databaseతో ఈ appను మాత్రమే రన్ చేయడానికి డాక్యుమెంటేషన్ docker compose up -d calcomని సూచిస్తుంది, ఇన్‌స్టాలేషన్ పూర్తయ్యాక మీరు ఇదే చేయాలి.

Imageను pull చేయండి, VPSలో build చేయవద్దు. source నుంచి build చేసేటప్పుడు NODE_OPTIONS="--max-old-space-size=16384"ని export చేయమని ప్రాజెక్ట్ సూచనలు చెబుతున్నాయి, ఇది కేవలం Node కోసమే 16 GB heapని తీసుకుంటుంది. ARM హార్డ్‌వేర్‌పై అయితే, image tagకు -arm suffixని జోడించండి. ముందే build చేసిన imageను రన్ చేయడానికి ప్రాజెక్ట్ ఎటువంటి కనీస అవసరాలను పేర్కొనలేదు, కాబట్టి 2 GBని app మరియు PostgreSQL కోసం నా పనితీరు అంచనాగా భావించండి, డాక్యుమెంట్ చేసిన విలువగా కాదు, మరియు మొదటి వారం మెమరీ వినియోగాన్ని గమనించండి.

అది రన్ అవుతుందో లేదో తనిఖీ చేయండి:

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

curl కమాండ్ HTTP/2 200ని ప్రింట్ చేయాలి. కంటైనర్ రన్ అవుతున్నట్లు కనిపిస్తున్నా nginx నుంచి 502 Bad Gateway వస్తుంటే, మొదటిసారి boot అయ్యేటప్పుడు database migrations జరుగుతున్నాయని అర్థం. అది విఫలమైందని నిర్ధారించుకునే ముందు కొన్ని నిమిషాలు వేచి ఉండి logs పరిశీలించండి. ప్రతి confirmed bookingపై Cal.com webhooks పనిచేస్తాయి, కాబట్టి ఒక booking మీరు ఇప్పటికే రన్ చేస్తున్న ఏదైనా ఆటోమేషన్‌ను ప్రేరేపించగలదు, ఉదాహరణకు మీ VPSలో HTTPS ద్వారా అందుబాటులో ఉన్న n8n instance.

దీని కోర్ AGPLv3 లైసెన్స్‌తో ఉంటుంది, కొన్ని ఫీచర్లు విడిగా commercial లైసెన్స్ కింద enterprise డైరెక్టరీలో ఉంటాయి. టీమ్ ఫీచర్లపై మీరు ఏదైనా చెల్లింపు వ్యాపార ప్రక్రియను నిర్మించే ముందు ఆ లైసెన్స్‌ను చదవండి.

1 GB సర్వర్‌లో 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 termination చేస్తాము. మీకు compose సింటాక్స్ కొత్త అయితే, ముందుగా Docker Compose basics on a VPS చదివి, ఆపై ఇక్కడికి తిరిగి రండి.

ఇక్కడ ఉన్న వాటిలో ఇది అత్యంత తేలికైన ఆప్షన్. రెండు కంటైనర్లు, ఒక PHP అప్లికేషన్ మరియు MySQL, 1 GB VPSలో సులభంగా నడుస్తాయి. దీని పరిమితి ఏమిటంటే: Google Calendar మాత్రమే దీనికి బ్యాకెండ్, మరియు దీని ఇంటర్‌ఫేస్ ఆధునిక బుకింగ్ ఫ్లో కంటే సాంప్రదాయ అడ్మిన్ ప్యానెల్ లాగా ఉంటుంది. మీ క్యాలెండర్ Microsoft 365, Fastmail లేదా Nextcloud అయితే, ఇది మీకు సరిపడదు.

గ్రూప్ పోల్స్ కోసం Rallly

Rallly భిన్నమైన అవసరానికి పరిష్కారం చూపుతుంది. ఇది మీ లభ్యతను (availability) ప్రచురించదు. ఇది ఒక సమూహం ముందు కొన్ని సంభావ్య సమయాలను ఉంచి ఓట్లను సేకరిస్తుంది. బోర్డు సమావేశాలకు ఇది ఉపయోగపడుతుంది, కానీ క్లయింట్ బుకింగ్ లింక్‌గా ఇది పనికిరాదు.

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

ఏదైనా స్క్రిప్ట్‌ను షెల్‌లోకి పైప్ (pipe) చేసే ముందు దానిని చదవండి. 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-అనుకూల ఆబ్జెక్ట్ స్టోరేజ్ కోసం Garage. DOMAINని, కనీసం 32 అక్షరాలున్న SECRET_PASSWORDని, SUPPORT_EMAILని మరియు INITIAL_ADMIN_EMAILని సెట్ చేయండి. మీరు ఇప్పటికే రివర్స్ ప్రాక్సీని వాడుతుంటే, PROXY_MODE=external మరియు WEB_PORTని సెట్ చేయండి, అప్పుడు Traefik జోక్యం చేసుకోదు. మీరు ఇప్పటికే MinIOతో సెల్ఫ్-హోస్టెడ్ S3-అనుకూల ఆబ్జెక్ట్ స్టోర్ వాడుతుంటే, 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 వెబ్ యాప్, రిమైండర్‌లు, క్యాలెండర్ సింక్ మరియు వెబ్‌హుక్‌లను నిర్వహించే బ్యాక్‌గ్రౌండ్ వర్కర్, PostgreSQL, Redis మరియు ఆటోమేటిక్ HTTPS తో కూడిన Caddy.

ఈ నాలుగింటిలో క్యాలెండర్ సపోర్ట్ అత్యంత విస్తృతమైనది. Google, Microsoft 365, CalDAV ద్వారా Apple మరియు ICS ఫీడ్‌లు ఇందులో ఉన్నాయి (ICS విషయంలో పైన పేర్కొన్న పరిమితిని గమనించండి). మిగిలిన అన్ని ఇంటిగ్రేషన్‌లు ఎన్విరాన్‌మెంట్ వేరియబుల్స్ ద్వారా ఆప్ట్-ఇన్ పద్ధతిలో ఉంటాయి. ఇందులో మెయిల్ కోసం SMTP లేదా Resend, అసిస్టెంట్ కోసం ANTHROPIC_API_KEY, SMS కోసం Twilio మరియు పేమెంట్స్ కోసం Stripe ఉన్నాయి. అసిస్టెంట్ 'ముందుగా నిర్ధారణ' పద్ధతిలో పనిచేస్తుంది: ఇది ప్రతిపాదిస్తుంది, మీరు ఆమోదిస్తారు, మీ స్పష్టమైన అనుమతి లేకుండా ఏదీ మీ క్యాలెండర్‌లోకి చేరదు. API కీని ఖాళీగా వదిలేస్తే, ఆ భాగానికి సంబంధించిన ఫీచర్ రన్ అవ్వదు.

సెల్ఫ్-హోస్టర్ల కోసం లైసెన్సింగ్ స్పష్టంగా ఉంది. కోర్ భాగం AGPLv3 కింద ఉంటుంది, మరియు ee/ డైరెక్టరీలో కమర్షియల్ క్లౌడ్-ఓన్లీ లైసెన్స్ ఉంటుంది. ఇది DAYOTTER_CLOUD=1 సెట్ చేయనంత వరకు నిష్క్రియంగా ఉంటుంది. అంటే, ఆగస్టు 2026 నాటికి నెలకు ఒక్కో సీటుకు $9 చొప్పున వసూలు చేసే టీమ్ ఫీచర్లు, మీ స్వంత సర్వర్‌లో కూడా అందుబాటులో ఉంటాయి.

ఇది ఇక్కడ ఉన్న వాటిలో అత్యంత భారీ స్టాక్ మరియు అతి పిన్న వయస్సు గల ప్రాజెక్ట్. దీన్ని మీ ప్రస్తుత బుకింగ్ లింక్ పక్కన రెండు వారాల పాటు రన్ చేయండి, రెండింటి ద్వారా నిజమైన బుకింగ్‌లను స్వీకరించండి మరియు మీ క్లయింట్‌లను దీనికి మార్చే ముందు వర్కర్ లాగ్‌లను పరిశీలించండి.

ప్రతి stack మీకు వాస్తవానికి ఎంత ఖర్చు అవుతుంది

ఒక చిన్న VPS పై ఒక stack ఎంత భారాన్ని మోపుతుందో తెలుసుకోవడానికి container ల సంఖ్య ఒక సరైన కొలమానం, ఎందుకంటే ప్రతి సేవకు కొంత కనీస మెమరీ అవసరం ఉంటుంది. ఆగస్టు 2026లో సేకరించిన, ప్రతి ప్రాజెక్ట్ యొక్క అధికారిక Docker stack ల ఆధారంగా ఈ సంఖ్యలు ఇవ్వబడ్డాయి.

[
  {
    "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 యొక్క బండిల్డ్ stack కు 4 కంటైనర్లు అవసరం, దీని డాక్యుమెంటేషన్ 2 GB మెమరీని సిఫార్సు చేస్తుంది. DayOtter యొక్క ఇన్‌స్టాలర్ 5 కంటైనర్లను రన్ చేస్తుంది, అందుకే ఇక్కడ ఉన్న 4 సేవలలో ఇది అత్యధిక మెమరీని కోరుకుంటుంది. Cal.com మరియు DayOtter ఎటువంటి కనీస మెమరీ పరిమితిని పేర్కొనలేదు, కాబట్టి వీటి కోసం నేను 2 GBని ప్రాథమిక అవసరంగా పరిగణిస్తున్నాను.

మీరు ఇప్పటికే మౌలిక సదుపాయాలను (infrastructure) నిర్వహిస్తుంటే, ఈ సంఖ్యలలో రెండు తగ్గుతాయి. మీరు మీ స్వంత proxy మరియు object storage ను ఉపయోగిస్తే, Rallly యొక్క Traefik మరియు Garage కంటైనర్లను తొలగించవచ్చు. Cal.com యొక్క Prisma Studio అనేది ఒక డెవలప్‌మెంట్ సాధనం, దీన్ని పబ్లిక్ సర్వర్‌పై రన్ చేయకూడదు.

ఏ self-hosted Calendly ప్రత్యామ్నాయాన్ని ఎంచుకోవాలి

ఒంటరిగా పనిచేసే కన్సల్టెంట్ Cal.com ను ఎంచుకోవాలి. ఇది మాత్రమే ప్రజలకు తెలిసిన బుకింగ్ పేజీని, మీ VPS లో Node build అవసరం లేకుండా ముందే సిద్ధం చేసిన images ను, మరియు Google లేదా Microsoft క్యాలెండర్లను వాడని వారి కోసం CalDAV మార్గాన్ని అందిస్తుంది. ఒక PostgreSQL డేటాబేస్ మరియు ఒక అప్లికేషన్ కంటైనర్ నిర్వహణ భారం చాలా కాలం పాటు సులభంగా ఉంటుంది. OAuth క్లయింట్ మరియు మెయిల్ రిలే కోసం ఒక మధ్యాహ్నం సమయం కేటాయించండి. CalDAV యాప్ ఇంకా బీటా దశలోనే ఉందని గమనించండి, కాబట్టి మీ లింక్‌ను పబ్లిష్ చేసే ముందు ఒక నిజమైన బుకింగ్‌ను పూర్తిగా పరీక్షించండి.

చిన్న బృందాలు DayOtter ను పరిశీలించాలి. Weighted round robin మరియు collective booking వంటి ఫీచర్లు దీని AGPLv3 కోర్‌లో ఉన్నాయి. కాబట్టి, హోస్టెడ్ సర్వీసుల కోసం డబ్బు చెల్లించాల్సిన అవసరం లేకుండానే ఈ ఫీచర్లను మీరు సొంతంగా హోస్ట్ చేసుకోవచ్చు. టీమ్ సభ్యులు ఆధారపడే రిమైండర్లు మరియు వెబ్‌హుక్స్ కోసం దీని వర్కర్ ప్రాసెస్ రూపొందించబడింది. అయితే దీనికి ఉన్న పరిమితి పరిణతి (maturity): ఇది ఈ జాబితాలో అత్యంత కొత్త ప్రాజెక్ట్, కాబట్టి మొదట దీనిని పాత పద్ధతికి సమాంతరంగా రన్ చేయండి. ఒక నెల రోజుల పాటు బుకింగ్‌లను గమనించిన తర్వాతే పాత లింక్‌ను తొలగించండి.

మరికొన్ని ప్రత్యేక సందర్భాలు: మీకు కేవలం గ్రూప్ మీటింగ్ సమయాన్ని నిర్ణయించడానికి ఒక పోల్ మాత్రమే అవసరమైతే, Rallly ని ఇన్‌స్టాల్ చేయండి, అంతటితో సరిపోతుంది. మీ దగ్గర 1 GB VPS ఉండి, మీరు Google Calendar వాడుతూ, బుకింగ్ తీసుకోవడానికి అతి తక్కువ వనరులు ఖర్చయ్యే చిన్న అప్లికేషన్ కావాలనుకుంటే, Easy!Appointments మీకు ఉత్తమమైన ఎంపిక. అదే సర్వర్‌లో ఇంకా ఏమి హోస్ట్ చేయవచ్చు అనే దానిపై మరింత సమాచారం కోసం, 2026లో దేనిని self-host చేయడం విలువైనది చూడండి.

FAQ

డొమైన్ పేరు లేకుండా నేను self-hosted బుకింగ్ పేజీని నడపవచ్చా?

లేదు. ఇటువంటి ప్రతి అప్లికేషన్ తన పబ్లిక్ URLను కన్ఫర్మేషన్ ఈమెయిల్‌లోని లింకులలో రాస్తుంది. Google మరియు Microsoft రెండూ కూడా OAuth redirect URIని అదే విలువతో సరిపోల్చుతాయి, కాబట్టి కేవలం IP అడ్రస్‌ను ఉపయోగిస్తే consent స్క్రీన్ వద్ద మీకు redirect_uri_mismatch వస్తుంది. Let's Encrypt కూడా IP అడ్రస్‌కు సర్టిఫికేట్‌ను జారీ చేయదు, దీనివల్ల పేజీ plain HTTP ద్వారా లోడ్ అవుతుంది మరియు బ్రౌజర్ ఆ ఫారమ్‌ను సురక్షితం కానిదిగా చూపిస్తుంది. ముందుగా డొమైన్‌ను కొనుగోలు చేసి, దానికి సంబంధించిన A record ను VPSకి పాయింట్ చేసిన తర్వాతే ఇన్‌స్టాల్ చేయండి.

నా బుకింగ్ కన్ఫర్మేషన్ ఈమెయిల్‌లు ఎందుకు రావడం లేదు?

సర్వర్ స్వయంగా మెయిల్‌ను పంపడానికి ప్రయత్నించడం దీనికి ప్రధాన కారణం. చాలా VPS ప్రొవైడర్లు కొత్త అకౌంట్లపై అవుట్‌బౌండ్ port 25ని బ్లాక్ చేస్తాయి, దీనివల్ల కనెక్షన్ నిలిచిపోతుంది. ఒకవేళ అది తెరిచి ఉన్నా, కొత్త అడ్రస్‌కు పంపే సామర్థ్యం (reputation) ఉండదు కాబట్టి పెద్ద మెయిల్ సర్వీసులు దానిని తిరస్కరిస్తాయి. అప్లికేషన్‌ను port 587 ద్వారా transactional mail relayకి పాయింట్ చేయండి, nc -vz -w 5 "$SMTP_HOST" 587 ఉపయోగించి ఆ port అందుబాటులో ఉందో లేదో నిర్ధారించుకోండి, ఆపై ఆ relay మీకు ఇచ్చిన SPF మరియు DKIM రికార్డులను పబ్లిష్ చేయండి. మీరు Cal.com వాడుతుంటే, అందులో ఉన్న డిఫాల్ట్ EMAIL_SERVER_HOST=localhost మరియు EMAIL_SERVER_PORT=1025 లను మార్చారో లేదో సరిచూసుకోండి, ఎందుకంటే అవి లోకల్ డెవలప్‌మెంట్ మెయిల్‌బాక్స్‌కు పాయింట్ చేస్తాయి.

Self-hosted Cal.com CalDAVతో సింక్ అవుతుందా, లేక కేవలం Googleతోనేనా?

రెండింటితోనూ అవుతుంది, కానీ వాటి పరిణితి వేరుగా ఉంటుంది. CalDAV యాప్ beta దశలో ఉంది మరియు ఇది Baikal, Radicale, Nextcloud, Kerio Connect వంటి సర్వర్లతో పరీక్షించబడింది. Apple iCloud కూడా యాప్-నిర్దిష్ట పాస్‌వర్డ్ ద్వారా దీనితో పనిచేస్తుంది. Google Calendar మరియు Microsoft 365 రెండూ రెండు వైపులా సింక్ అవుతాయి, కానీ self-hosted ఇన్‌స్టాలేషన్‌లో మీరు సొంతంగా OAuth క్లయింట్‌ను సృష్టించి, దానిని GOOGLE_API_CREDENTIALS ద్వారా అందించాలి, ఎందుకంటే హోస్ట్ చేసిన సర్వీస్ యొక్క క్రెడెన్షియల్స్ సోర్స్ కోడ్‌లో ఉండవు.

ఒక వారం తర్వాత నా Google Calendar సింక్ ఎందుకు ఆగిపోతుంది?

ఎందుకంటే మీ Google Cloud ప్రాజెక్ట్ ఇంకా Testing పబ్లిషింగ్ స్టేటస్‌లోనే ఉంది. ఆ స్థితిలో ఉన్న యాప్‌లకు Google జారీ చేసే refresh tokens ఏడు రోజుల తర్వాత ఎక్స్‌పైర్ అవుతాయి. కాబట్టి కనెక్షన్ మొదట పనిచేస్తుంది, కానీ తదుపరి టోకెన్ రిఫ్రెష్ సమయంలో ఆగిపోతుంది, అప్పుడు అప్లికేషన్ లాగ్‌లో invalid_grant కనిపిస్తుంది. OAuth consent స్క్రీన్‌ను In production స్థితికి మార్చి, క్యాలెండర్‌ను ఒక్కసారి మళ్లీ కనెక్ట్ చేయండి. స్టేటస్ మార్చకుండా మళ్లీ కనెక్ట్ చేస్తే మీకు కేవలం మరో ఏడు రోజులు మాత్రమే సమయం లభిస్తుంది.

వీటిలో ఏవి 1 GB VPSపై నడుస్తాయి?

Easy!Appointments నడుస్తుంది, ఎందుకంటే ఇది PHP అప్లికేషన్ మరియు MySQLని ఉపయోగిస్తుంది. Rallly కనీసం 2 GB అవసరమని పేర్కొంది మరియు దానితో వచ్చే stack నాలుగు సేవలను నడుపుతుంది. Cal.com మరియు DayOtter ఎటువంటి కనీస అవసరాలను పేర్కొనలేదు, కానీ PostgreSQLతో కూడిన Next.js అప్లికేషన్, మరియు DayOtter విషయంలో Redis మరియు worker ప్రాసెస్ కూడా ఉంటాయి కాబట్టి, మీరు 2 GB లేదా అంతకంటే ఎక్కువ మెమరీని ప్లాన్ చేసుకోవాలి. చిన్న సర్వర్‌పై ఎప్పుడూ Cal.comను సోర్స్ నుండి బిల్డ్ చేయకండి: ప్రాజెక్ట్ యొక్క సొంత బిల్డ్ సూచనలు 16 GB Node heapని అడుగుతాయి, కాబట్టి దానికి బదులుగా ముందుగానే బిల్డ్ చేసిన (prebuilt) ఇమేజ్‌ను ఉపయోగించండి.