ஆல் சிறந்த Self-hosted Calendly மாற்றுகள்: ஒப்பீடு
Cal.com, Easy!Appointments, Rallly மற்றும் DayOtter ஆகியவற்றை உங்கள் VPS-ல் நிறுவுவது எப்படி? இருவழி calendar sync மற்றும் outbound email வசதிகளை அடிப்படையாகக் கொண்டு ஒப்பிடுகிறோம்.
சுருக்கமான பதில்
ஒரு self-hosted Calendly மாற்றானது, உங்கள் VPS-ல் உள்ள பிற internal கருவிகள் செய்யாத ஒரு வேலையைச் செய்ய வேண்டும்: அது பொதுமக்களின் அணுகலுக்குப் பதிலளிக்க வேண்டும். அந்த booking page-தான் அந்த product. அதற்குத் தொடக்கத்திலிருந்தே ஒரு முறையான domain name மற்றும் TLS (transport layer security) அவசியம். மேலும், உங்கள் server-ஐப் பற்றி அறியாத நபர்களுக்கு அது மின்னஞ்சல்களை அனுப்ப வேண்டியிருக்கும்.
நான்கு திட்டங்கள் இந்தத் தேவையைப் பூர்த்தி செய்கின்றன. Cal.com என்பது Calendly-க்கு மிக நெருக்கமான மாற்றாகும், இது தனிப்பட்ட ஆலோசகர்களுக்குச் சிறந்த தேர்வாகும். Easy!Appointments என்பது இலகுவானது; இது PHP மற்றும் MySQL-ஐப் பயன்படுத்துவதால், 1 GB VPS-ல் சிறப்பாக இயங்கும். Rallly என்பது குழுக்களுக்கான வாக்கெடுப்பு கருவி, இதில் booking page வசதி இல்லை. DayOtter என்பது புதிய வரவு; இது AGPLv3 உரிமம் கொண்ட scheduling platform, இதில் confirm-first assistant வசதி உள்ளது.
எந்த மென்பொருளை நீங்கள் இயக்கலாம் என்பதை இரண்டு கேள்விகள் தீர்மானிக்கின்றன. நீங்கள் ஏற்கனவே பயன்படுத்தும் calendar-உடன் அது இருவழி ஒத்திசைவை (two-way sync) செய்கிறதா? அது மின்னஞ்சல்களை அனுப்ப முடியுமா? இரண்டாவது கேள்விதான் பெரும்பாலான self-hosted booking அமைப்புகள் தோல்வியடையும் இடமாகும், எனவே அதற்கு முன்னுரிமை அளிக்க வேண்டும்.
வெளியேறும் மின்னஞ்சல் (Outbound email) தோல்வியடையும் பகுதி
முன்பதிவு உறுதிப்படுத்தல் மின்னஞ்சல் அந்நியரின் இன்பாக்ஸிற்குச் செல்கிறது. இது Gmail அல்லது Microsoft 365-க்குச் செல்லும் transactional மின்னஞ்சல் ஆகும். அந்த மின்னஞ்சல் பெறுநர்கள், உங்கள் sending IP முகவரி மற்றும் DNS பதிவுகளைக் கொண்டு உங்களை மதிப்பிடுவார்கள்.
VPS-லிருந்து நேரடியாக மின்னஞ்சல் அனுப்புவது பெரும்பாலும் வேலை செய்யாது. பெரும்பாலான சேவை வழங்குநர்கள் புதிய கணக்குகளில் வெளியேறும் TCP port 25-ஐத் தடுப்பார்கள், எனவே இணைப்பு துண்டிக்கப்பட்டு காலாவதியாகும் (times out). port 25 திறந்திருந்தாலும், புதிய VPS முகவரிக்கு மின்னஞ்சல் அனுப்பிய வரலாறு இருக்காது. பெரிய மின்னஞ்சல் சேவை வழங்குநர்கள், தெரியாத ஹோஸ்டிங் முகவரிகளைச் சந்தேகத்திற்குரியதாகக் கருதுவார்கள். முன்பதிவு தரவுத்தளத்தில் எழுதப்படும், பக்கம் உறுதிப்படுத்தப்பட்டதாகக் காட்டும், ஆனால் யாருக்கும் மின்னஞ்சல் கிடைக்காது. சர்வர் பக்கத்தில் எந்தப் பிழையும் தெரியாது என்பதால், வாடிக்கையாளர் வராதபோதுதான் இது பல வாரங்களுக்குப் பிறகு கண்டறியப்படுகிறது.
ஒரு relay-ஐப் பயன்படுத்தவும். எந்தவொரு transactional மின்னஞ்சல் சேவை வழங்குநரும் இதற்குப் பயன்படுவார்கள். உங்கள் application-க்கு hostname, port, பயனர் பெயர் மற்றும் கடவுச்சொல் மட்டுமே தேவை. application அமைப்புகளை மாற்றுவதற்கு முன், அந்த port-ஐ அணுக முடியுமா என்று சரிபார்க்கவும்:
nc -vz -w 5 "$SMTP_HOST" 587succeeded வரி என்பது பாதை திறந்திருப்பதைக் குறிக்கிறது. இணைப்பு நீண்ட நேரம் தொங்கிக்கொண்டிருந்தாலோ அல்லது Connection refused என்று வந்தாலோ, அந்த port நெட்வொர்க் அளவில் தடுக்கப்பட்டுள்ளது என்று அர்த்தம். .env கோப்பை எவ்வளவு திருத்தினாலும் இது சரியாகாது. port 25 அடிக்கடி தடுக்கப்படுவதால்தான், relays 587 அல்லது 465 ஆகிய port-களில் இயங்குகின்றன.
ஒவ்வொரு திட்டமும் 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-ஐ 1025 port-ல் உள்ள localhost-க்குச் சுட்டிக்காட்டுகிறது, இது ஒரு உள்ளூர் மேம்பாட்டு மின்னஞ்சல் பெட்டியாகும் (local development mailbox). இயல்புநிலை அமைப்பை அப்படியே விட்டால், எந்தப் பிழையும் காட்டாமல் மின்னஞ்சல் எங்கும் செல்லாது. Rallly ஆனது SMTP_HOST, SMTP_PORT, SMTP_USER மற்றும் SMTP_PWD ஆகியவற்றை எடுத்துக்கொள்ளும். DayOtter ஆனது SMTP அமைப்புகளை அல்லது Resend key-ஐ ஏற்கும். Easy!Appointments அதன் அறிவிப்புகளை application-லிருந்து அனுப்புகிறது, எனவே உண்மையான முன்பதிவுகளை ஏற்கும் முன், அதன் அமைப்புகள் பக்கத்தில் அதே relay-ஐக் குறிப்பிடவும்.
பிறகு, உங்கள் relay வழங்கும் DNS பதிவுகளைப் பதிவேற்றவும். ஒரு SPF (sender policy framework) பதிவு, உங்கள் டொமைனுக்காக எந்தெந்த சர்வர்கள் மின்னஞ்சல் அனுப்பலாம் என்பதைத் தெரிவிக்கும். ஒரு DKIM (domainkeys identified mail) key ஒவ்வொரு செய்தியையும் கையொப்பமிடும், இதன் மூலம் செய்தி மாற்றப்படவில்லை என்பதைப் பெறுநர் உறுதிப்படுத்த முடியும். இவை இரண்டும் சரியாக அமைந்த பிறகு, ஒரு DMARC (domain-based message authentication, reporting and conformance) கொள்கையைச் சேர்க்கவும். ஒரு பெரிய மின்னஞ்சல் சேவை வழங்குநரின் உண்மையான முகவரிக்கு ஒரு சோதனை முன்பதிவை அனுப்பி, செய்தியின் தலைப்புகளை (headers) திறந்து, அங்கீகார வரிகள் pass என்று இருப்பதைக் உறுதிப்படுத்தவும். மின்னஞ்சல் அனுப்ப முடியாத முன்பதிவுப் பக்கம், முன்பதிவுப் பக்கமே இல்லாததை விட மோசமானது, ஏனெனில் அது அமைதியாகத் தோல்வியடையும்.
எந்தெந்த calendar backends இருவழி ஒத்திசைவை (sync) சரியாகச் செய்கின்றன
Sync என்பது இரண்டு திசைகளில் நடக்கும் செயல்முறை, இவை தனித்தனியாகத் தோல்வியடையக்கூடும். வாசிப்புத் திசை (read direction) என்பது கிடைக்கும் நேரத்தைக் குறிக்கும் (availability): உங்கள் ஏற்கனவே உள்ள பிஸியான நேரங்களை application பார்க்க வேண்டும், இல்லையெனில் நீங்கள் ஏற்கனவே பிஸியாக இருக்கும் நேரத்தை அது முன்பதிவுக்கு அனுமதித்துவிடும். எழுதும் திசை (write direction) என்பது முன்பதிவு செய்வதைக் குறிக்கும்: உறுதிசெய்யப்பட்ட நிகழ்வு, முன்பதிவு கருவிக்குள் மட்டும் இல்லாமல், நீங்கள் வழக்கமாகப் பார்க்கும் calendar-லும் தோன்ற வேண்டும்.
Google Calendar மற்றும் Microsoft 365 ஆகிய இரண்டும் இரு திசைகளிலும் செயல்படுகின்றன, ஆனால் self-hosted முறையில் ஒரு நிபந்தனை உள்ளது. நீங்கள் OAuth (open authorization) client-ஐ நீங்களே உருவாக்க வேண்டும், ஏனெனில் hosted product-ன் client ID source code-ல் இருக்காது. Cal.com-க்கு இது GOOGLE_API_CREDENTIALS, இது .env-ல் உள்ளது; Google Cloud console-லிருந்து நீங்கள் பதிவிறக்கும் JSON கோப்பை இதில் உள்ளிட வேண்டும். DayOtter-ம் Google மற்றும் Microsoft OAuth சான்றுகளை இதே முறையில் பெற்றுக்கொள்கிறது.
இங்கு இரண்டு விஷயங்கள் சிக்கலை ஏற்படுத்தலாம், தொடங்குவதற்கு முன் இவற்றைத் தெரிந்துகொள்வது அவசியம். முதலாவதாக, நீங்கள் பதிவு செய்யும் redirect URI உங்கள் public URL-உடன் சரியாகப் பொருந்த வேண்டும்; இதில் scheme மற்றும் trailing path உட்பட அனைத்தும் சரியாக இருக்க வேண்டும், இல்லையெனில் Google consent screen-ல் redirect_uri_mismatch பிழையைக் காட்டி இணைப்பைத் துண்டித்துவிடும். இரண்டாவதாக, Google project-ஐ Testing publishing நிலையில் வைத்திருந்தால், அது வழங்கும் refresh tokens ஏழு நாட்களில் காலாவதியாகிவிடும். Sync வாரம் முழுவதும் வேலை செய்யும், ஆனால் அடுத்த முறை refresh செய்யும்போது app logs-ல் invalid_grant பிழையைக் காட்டும். எனவே, consent screen-ஐ In production நிலைக்கு மாற்றவும், அல்லது ஒவ்வொரு திங்கட்கிழமையும் கைமுறையாக மீண்டும் இணைக்க ஒப்புக்கொள்ளவும்.
CalDAV (calendaring extensions to WebDAV) என்பது திறந்தநிலை விருப்பமாகும், ஆனால் இதற்கான ஆதரவு குறைவாகவே உள்ளது. Cal.com ஒரு CalDAV app-ஐ வழங்குகிறது, இது இன்னும் beta நிலையிலேயே உள்ளது; இது Baikal, Radicale, Nextcloud மற்றும் Kerio Connect போன்ற servers-ல் சரிபார்க்கப்பட்டுள்ளது. Apple iCloud இதே app மூலம் வேலை செய்கிறது, ஆனால் இதற்கு உங்கள் Apple ID password-க்கு பதிலாக app-specific password தேவைப்படும். DayOtter, Apple-ஐ CalDAV மூலம் Google மற்றும் Microsoft 365-க்கு இணையாகப் பட்டியலிடுகிறது.
ICS feed என்பது sync கிடையாது. சந்தா செய்யப்பட்ட (subscribed) .ics URL என்பது வடிவமைப்பிலேயே read-only ஆகும், எனவே இது உங்கள் முன்பதிவு பக்கத்தில் நேரத்தைத் தடுக்க (block) முடியுமே தவிர, முன்பதிவை ஒருபோதும் பெற்றுக்கொள்ள முடியாது. ஒரு கருவி உங்கள் calendar-க்கு ICS-ஐ மட்டுமே வழங்கினால், அதன் பாதி வசதிகள் மட்டுமே உங்களிடம் உள்ளன என்று அர்த்தம்; நீங்கள் நிகழ்வுகளைக் கைமுறையாகவே நகலெடுக்க வேண்டியிருக்கும்.
Easy!Appointments, Google Calendar-ஐ மட்டுமே sync செய்கிறது, வேறு எதையும் செய்யாது. Rallly, கிடைக்கும் நேரத்தை (availability) வாசிப்பதே இல்லை: இது பரிந்துரைக்கப்பட்ட தேதிகளில் வாக்குகளை மட்டுமே சேகரிக்கிறது. "நம்மில் ஆறு பேர் எப்போது சந்திக்கலாம்" என்பதற்கு இது சரியான கருவி, ஆனால் "என்னுடன் 30 நிமிடங்கள் முன்பதிவு செய்யுங்கள்" என்பதற்கு இது தவறான கருவி.
முன்பதிவுப் பக்கம் பொதுவானது, எனவே TLS முதன்மையானது
மக்கள் தாங்களே ஹோஸ்ட் செய்யும் பெரும்பாலானவை தனிப்பட்டவை. ஒரு விக்கி, ஒரு போர்டு, ஒரு டேஷ்போர்டு என அனைத்தும் VPN அல்லது SSO லாகின் பின்னால் இருக்கலாம், அவை பொது இணையத்தில் தெரிய வேண்டிய அவசியமில்லை. ஆனால் முன்பதிவு இணைப்பு அப்படி இருக்க முடியாது. நீங்கள் யாருக்கு அனுப்புகிறீர்களோ அவர்கள் அதைத் திறக்க வேண்டும், இது அமைப்பை மூன்று வழிகளில் மாற்றுகிறது.
எதையும் நிறுவும் முன்பே, VPS-ஐச் சுட்டிக்காட்டும் A record கொண்ட டொமைன் பெயர் உங்களுக்குத் தேவை. முதல் நாளிலேயே சான்றிதழ் (certificate) அவசியம், ஏனெனில் சாதாரண HTTP படிவங்களை உலாவிகள் பாதுகாப்பற்றவை எனக் குறிக்கும், மேலும் உங்கள் வாடிக்கையாளர் அதில் தங்கள் பெயர் மற்றும் மின்னஞ்சலை உள்ளிடுவார்கள். மேலும், அந்த ஆப்-ன் பொது URL அதன் அமைப்பில் சரியாக இருக்க வேண்டும், ஏனெனில் அந்த மதிப்பு மின்னஞ்சல்களில் உள்ள இணைப்புகளிலும் OAuth redirect 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-ன் நிறுவி Caddy-ஐ தானியங்கி HTTPS-உடன் கொண்டு வருகிறது. Cal.com மற்றும் Easy!Appointments அவ்வாறு செய்வதில்லை, எனவே நீங்கள் nginx-ஐ முன்னால் வைத்து நீங்களே சான்றிதழை வழங்க வேண்டும், இது nginx-ல் Certbot மூலம் Let's Encrypt சான்றிதழ் பெறுவது போன்றதே. ஆப் கன்டெய்னரை 127.0.0.1-ல் பிணைக்கவும் (bind), அப்போதுதான் நீங்கள் கட்டுப்படுத்தும் ப்ராக்ஸி வழியாக மட்டுமே உள்ளே வர முடியும். அதே சர்வரில் ஏற்கனவே உங்கள் உள்நாட்டுப் பயன்பாட்டிற்கான Trello போன்ற ஒரு ஆப் இயங்கிக்கொண்டிருந்தால், அதை உங்கள் தற்போதைய அங்கீகாரத்திற்குப் பின்னால் வைத்து, முன்பதிவு ஹோஸ்டிற்கு மட்டும் பொதுவான சர்வர் பிளாக்கை (server block) வழங்கவும்.
உங்கள் VPS-ல் Cal.com
Docker கட்டமைப்பு அதன் சொந்த repository-ல் உள்ளது, மேலும் images ஏற்கனவே Docker Hub-ல் உருவாக்கப்பட்டுள்ளன (prebuilt), எனவே நீங்கள் அவற்றை 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 முகவரிக்குச் சுட்டிக்காட்டவும். இந்த தொகுப்பில் web app, PostgreSQL மற்றும் Prisma Studio ஆகியவை உள்ளன; நீங்கள் ஏற்கனவே வேறொரு இடத்தில் வைத்திருக்கும் 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 hardware-ல், image tag-உடன் -arm suffix-ஐச் சேர்க்கவும். Prebuilt image-ஐ இயக்குவதற்குத் தேவையான குறைந்தபட்ச அளவு குறித்து திட்டம் எதையும் குறிப்பிடவில்லை, எனவே 2 GB என்பது app மற்றும் PostgreSQL ஆகிய இரண்டிற்கும் போதுமானது என்று நான் கருதுகிறேன்; முதல் வாரம் முழுவதும் memory பயன்பாட்டைக் கண்காணிக்கவும்.
அது இயங்குகிறதா எனச் சரிபார்க்கவும்:
docker compose ps
docker compose logs -f calcom
curl -sI https://cal.example.com | head -n 1Curl கட்டளை HTTP/2 200-ஐ அச்சிட வேண்டும். Container இயங்கிக்கொண்டிருக்கும்போது nginx-லிருந்து 502 Bad Gateway கிடைத்தால், முதல் boot-ன் போது database migrations நடைபெறுகிறது என்று அர்த்தம். அது பழுதடைந்துவிட்டது என்று முடிவெடுக்கும் முன், சில நிமிடங்கள் காத்திருந்து logs-ஐப் படிக்கவும். Cal.com-ன் webhooks ஒவ்வொரு உறுதிப்படுத்தப்பட்ட முன்பதிவின் போதும் இயங்கும், எனவே ஒரு முன்பதிவு நீங்கள் ஏற்கனவே இயக்கும் எந்தவொரு automation-ஐயும் தூண்டலாம், உதாரணமாக உங்கள் VPS-ல் HTTPS மூலம் அணுகக்கூடிய n8n instance.
இதன் அடிப்படை AGPLv3 உரிமத்தின் கீழ் உள்ளது, சில அம்சங்கள் தனி வணிக உரிமத்தின் கீழ் enterprise directory-ல் வைக்கப்பட்டுள்ளன. குழு அம்சங்களை (team features) அடிப்படையாகக் கொண்டு ஒரு கட்டண வணிகச் செயல்பாட்டை உருவாக்கும் முன் அந்த உரிமத்தைப் படிக்கவும்.
1 GB VPS-ல் Easy!Appointments
இதற்கு Apache அல்லது Nginx, PHP 8.2 அல்லது அதற்குப் பிந்தைய பதிப்பு, மற்றும் MySQL தேவை. alextselegidis/easyappointments-ல் இதற்கான அதிகாரப்பூர்வ image உள்ளது.
முதலில் ஒரு எச்சரிக்கை. களஞ்சியத்தில் (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/mysqlBASE_URL என்பது பொதுவான HTTPS முகவரியாக இருக்க வேண்டும். இதைத் தவறாகக் குறிப்பிட்டால், உறுதிப்படுத்தல் மின்னஞ்சல்களில் உள்ள முன்பதிவு இணைப்புகள் உங்கள் வாடிக்கையாளர்களால் அணுக முடியாத host-ஐக் காட்டும். இந்த image port 80-ல் plain HTTP-ஐ மட்டுமே வழங்குகிறது, அதற்குத் தனியாகச் சான்றிதழ் (certificate) இல்லை. இதனால்தான் port 127.0.0.1-ல் இணைக்கப்பட்டு, Nginx முன்னால் TLS termination செய்கிறது. உங்களுக்கு compose syntax புதியது என்றால், Docker Compose basics on a VPS என்பதைப் படித்துவிட்டு மீண்டும் வரவும்.
இங்குள்ள விருப்பங்களில் இதுவே மிகக் குறைந்த வளங்களைப் பயன்படுத்தும் தேர்வாகும். இரண்டு containers, ஒரு PHP application மற்றும் MySQL, 1 GB VPS-ல் தாராளமாக இயங்கும். இதன் வரம்பு என்னவென்றால்: Google Calendar மட்டுமே இதற்கான calendar backend-ஆகச் செயல்படும். மேலும் இதன் இடைமுகம் நவீன முன்பதிவு முறையை விட, பாரம்பரியமான admin panel-ஆகவே இருக்கும். உங்கள் calendar Microsoft 365, Fastmail அல்லது Nextcloud ஆக இருந்தால், இதைத் தொடங்குவதற்கு முன்பே தவிர்க்கவும்.
குழு வாக்கெடுப்புகளுக்கான Rallly
Rallly ஒரு மாறுபட்ட தேவையை நிறைவு செய்கிறது. இது உங்கள் கிடைக்கும் நேரத்தை (availability) வெளியிடுவதில்லை. மாறாக, ஒரு குழுவின் முன் சில குறிப்பிட்ட நேர விருப்பங்களை வைத்து வாக்குகளைச் சேகரிக்கிறது. இது ஒரு குழு கூட்டத்திற்கு (board meeting) பொருத்தமானது, ஆனால் வாடிக்கையாளர் முன்பதிவு இணைப்பிற்கு (client 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, Docker 19.03 அல்லது அதற்குப் பிந்தைய பதிப்புடன் Compose v2, 80 மற்றும் 443 ports காலியாக இருக்க வேண்டும், மேலும் ஒரு domain அந்த server-ஐச் சுட்டிக்காட்ட வேண்டும். இதில் உள்ள 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 குறுக்கிடாது. நீங்கள் ஏற்கனவே MinIO மூலம் self-hosted S3-compatible object store-ஐப் பயன்படுத்துகிறீர்கள் என்றால், S3_* மாறிகளை (variables) அதற்குச் சுட்டிக்காட்டி, Garage container-ஐ நீக்கிவிடலாம்.
இங்கே SMTP கட்டாயமானது, ஏனெனில் உள்நுழைவு (sign-in) ஒரு magic link மூலமே நடைபெறுகிறது. சரியாகச் செயல்படும் relay இல்லையென்றால், நீங்கள் உருவாக்கிய admin account உட்பட யாராலும் உள்நுழைய முடியாது. மின்னஞ்சல் தோல்வியின் இந்த வடிவம் ஒரு வகையில் நல்லது: இது மூன்று வாரங்களுக்குப் பிறகு வாடிக்கையாளரின் முன்பதிவை இழப்பதற்குப் பதிலாக, தொடக்கத்திலேயே உங்களைத் தடுத்து நிறுத்திவிடுகிறது.
DayOtter, புதிய வரவு
DayOtter என்பது ஒரு உதவியாளருடன் இணைக்கப்பட்ட AGPLv3 scheduling தளமாகும். இதன் production install-க்கு ஒரே ஒரு கட்டளை போதும்:
curl -fsSL https://raw.githubusercontent.com/Dayotter/dayotter/main/deploy/install.sh \
| sudo DAYOTTER_DOMAIN=cal.example.com bashஇதை இயக்குவதற்கு முன் மேலே உள்ளவாறு படித்துப் பார்க்கவும். இந்த installer Docker-ஐ அமைத்து, secrets-ஐ உருவாக்கி, முழு stack-ஐயும் இயக்கும்: Next.js web app, நினைவூட்டல்கள், calendar sync மற்றும் webhooks-ஐக் கையாளும் background worker, PostgreSQL, Redis, மற்றும் தானியங்கி HTTPS வசதி கொண்ட Caddy.
நான்கு தளங்களில், இதில் தான் calendar ஆதரவு மிக விரிவானது. Google, Microsoft 365, CalDAV வழியாக Apple, மற்றும் ICS feeds ஆகியவை இதில் உள்ளன (ICS-க்கு மேலே உள்ள எச்சரிக்கையைப் பார்க்கவும்). மற்ற அனைத்து ஒருங்கிணைப்புகளும் environment variables மூலம் விருப்பத்தேர்வாகவே உள்ளன; இதில் மின்னஞ்சலுக்கான SMTP அல்லது Resend, உதவியாளருக்கான ANTHROPIC_API_KEY, SMS-க்கான Twilio, மற்றும் கட்டணங்களுக்கான Stripe ஆகியவை அடங்கும். உதவியாளர் 'confirm-first' முறையில் செயல்படுகிறது: அது பரிந்துரைக்கும், நீங்கள் ஒப்புதல் அளிக்க வேண்டும், உங்கள் தெளிவான சம்மதம் இன்றி எதுவும் உங்கள் calendar-ஐ அடையாது. API key-ஐ காலியாக விட்டால், அந்தப் பகுதி இயங்காது.
Self-hosters-க்கு உரிமம் (licensing) தெளிவாக உள்ளது. இதன் அடிப்படை AGPLv3 ஆகும், மேலும் ee/ கோப்பகத்தில் வணிக ரீதியான cloud-only உரிமம் உள்ளது, இது DAYOTTER_CLOUD=1 அமைக்கப்பட்டால் ஒழிய செயல்படாது. அதாவது, ஆகஸ்ட் 2026 நிலவரப்படி, ஒரு இருக்கைக்கு மாதம் $9 என வசூலிக்கப்படும் குழு அம்சங்களை உங்கள் சொந்த server-லேயே பயன்படுத்திக்கொள்ளலாம்.
இதுவே இங்குள்ளவற்றில் அதிக சுமை கொண்ட stack மற்றும் மிக இளைய திட்டமாகும். இதை உங்கள் தற்போதைய booking link-உடன் சேர்த்து இரண்டு வாரங்கள் இயக்கி, இரண்டிலும் உண்மையான bookings-ஐப் பெற்று, உங்கள் வாடிக்கையாளர்களை மாற்றும் முன் worker logs-ஐச் சரிபார்க்கவும்.
ஒவ்வொரு stack-ம் உங்களுக்கு ஏற்படுத்தும் உண்மையான செலவு
ஒரு சிறிய VPS-ல் ஒரு stack எவ்வளவு வளங்களைப் பயன்படுத்தும் என்பதைத் தீர்மானிப்பதில், அதில் உள்ள container-களின் எண்ணிக்கையே சரியான அளவுகோலாகும். ஏனெனில், ஒவ்வொரு service-க்கும் ஒரு குறிப்பிட்ட அளவு குறைந்தபட்ச memory தேவைப்படுகிறது. ஆகஸ்ட் 2026-ல் அந்தந்த திட்டங்களின் அதிகாரப்பூர்வ Docker stack-களில் இருந்து பெறப்பட்ட எண்ணிக்கைகள் கீழே கொடுக்கப்பட்டுள்ளன.
The data behind this chart
[
{
"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 container-கள் தேவைப்படுகின்றன, இது 1 GB memory-ல் இயங்கும். Rallly-ன் bundled stack-க்கு 4 தேவைப்படுகிறது, அதன் ஆவணங்கள் 2 GB-ஐப் பரிந்துரைக்கின்றன. DayOtter-ன் installer 5 container-களை உருவாக்குகிறது, இதனால்தான் இங்குள்ள 4 stack-களில் இதுவே அதிக memory-ஐக் கோருகிறது. Cal.com மற்றும் DayOtter ஆகிய இரண்டும் குறைந்தபட்ச memory அளவை வெளியிடுவதில்லை, எனவே இவை இரண்டிற்கும் 2 GB-ஐ எனது தொடக்கப்புள்ளியாகக் கொண்டுள்ளேன்; இது அதிகாரப்பூர்வமாக ஆதரிக்கப்படும் எண் அல்ல.
நீங்கள் ஏற்கனவே உள்கட்டமைப்பை (infrastructure) வைத்திருந்தால், இந்த எண்ணிக்கையில் இரண்டைக் குறைக்கலாம். Rallly-ன் Traefik மற்றும் Garage container-களை உங்கள் சொந்த proxy மற்றும் object storage-க்கு மாற்றும்போது அவற்றை நீக்கிவிடலாம். Cal.com-ன் Prisma Studio என்பது ஒரு development கருவியாகும், இதை பொது server-ல் எப்போதும் இயங்க விடக்கூடாது.
எந்த self-hosted Calendly மாற்றீட்டை நீங்கள் தேர்ந்தெடுக்க வேண்டும்
தனிப்பட்ட ஆலோசகர்கள் Cal.com-ஐப் பயன்படுத்த வேண்டும். இதுவே இங்குள்ள ஒரே திட்டமாகும்; இது மக்கள் எளிதில் அடையாளம் காணக்கூடிய முன்பதிவுப் பக்கத்தையும், உங்கள் VPS-ல் Node build செய்வதைத் தவிர்க்கும் முன்கூட்டியே கட்டமைக்கப்பட்ட (prebuilt) images-களையும், Google அல்லது Microsoft-ல் நாட்காட்டியைப் பராமரிக்காதவர்களுக்கான CalDAV வசதியையும் வழங்குகிறது. ஒரு PostgreSQL database மற்றும் ஒரு application container ஆகியவற்றை நீங்கள் பல ஆண்டுகள் பராமரிக்க முடியும். OAuth client மற்றும் mail relay அமைப்பிற்கு ஒரு மதிய நேரத்தை ஒதுக்குங்கள். CalDAV செயலி இன்னும் beta நிலையில் உள்ளது என்பதை நினைவில் கொள்ளுங்கள், எனவே இணைப்பை வெளியிடும் முன் ஒரு உண்மையான முன்பதிவை முழுமையாகச் சோதித்துப் பாருங்கள்.
சிறிய குழுக்கள் DayOtter-ஐப் பரிசீலிக்க வேண்டும். Weighted round robin மற்றும் கூட்டு முன்பதிவு (collective booking) வசதிகள் இதன் AGPLv3 core-ல் உள்ளன. எனவே, self-hosting செய்வதன் மூலம், கட்டணச் சேவைகளில் மட்டுமே கிடைக்கும் அம்சங்களை நீங்கள் இலவசமாகப் பெறலாம். குழுக்கள் சார்ந்த reminders மற்றும் webhooks-க்காகவே இதன் worker process கட்டமைக்கப்பட்டுள்ளது. இதில் உள்ள குறைபாடு முதிர்ச்சி (maturity) மட்டுமே: இதுவே இந்தப் பட்டியலில் உள்ள புதிய திட்டம் என்பதால், முதலில் பழைய முன்பதிவு இணைப்பைத் தொடர்ந்து வைத்துக்கொண்டு, ஒரு மாதம் முழுமையாகச் சோதித்த பிறகு இதற்கு மாறுங்கள்.
குறுகிய தேவைகளுக்கான இரண்டு விருப்பங்கள்: குழுவினர் சந்திப்பதற்கான நேரத்தைத் தீர்மானிக்க ஒரு poll மட்டுமே தேவை என்றால், Rallly-ஐ நிறுவி அதோடு நிறுத்திக்கொள்ளுங்கள். உங்களிடம் 1 GB VPS இருந்து, நீங்கள் Google Calendar-ஐப் பயன்படுத்துபவர் மற்றும் மிகக் குறைந்த வளங்களைப் பயன்படுத்தும் முன்பதிவுத் தளம் தேவை என்றால், Easy!Appointments உங்களுக்குச் சிறந்த தேர்வாகும்; இது மற்ற சிக்கலான விருப்பங்களை விட நீண்ட காலம் நிலைத்து நிற்கும். ஒரே server-ல் வேறு எவற்றை நிறுவலாம் என்பது குறித்த விரிவான தகவலுக்கு, 2026-ல் எவற்றை self-hosting செய்வது பயனுள்ளது என்பதைப் பார்க்கவும்.
FAQ
டொமைன் பெயர் இல்லாமல் என்னால் self-hosted booking பக்கத்தை இயக்க முடியுமா?
முடியாது. இத்தகைய ஒவ்வொரு செயலியும் அதன் பொதுவான URL-ஐ உறுதிப்படுத்தல் மின்னஞ்சல்களில் உள்ள இணைப்புகளில் எழுதும். Google மற்றும் Microsoft ஆகிய இரண்டுமே OAuth redirect URI-ஐ அதே மதிப்போடு ஒப்பிடுகின்றன, எனவே வெறும் IP முகவரியைப் பயன்படுத்தினால் consent திரையில் redirect_uri_mismatch பிழை ஏற்படும். Let’s Encrypt ஒரு IP முகவரிக்குச் சான்றிதழை வழங்காது, எனவே பக்கம் plain HTTP வழியாகவே இயங்கும் மற்றும் உலாவி அந்தப் படிவத்தைப் பாதுகாப்பற்றது எனக் காட்டும். முதலில் டொமைனை வாங்கி, அதன் A record-ஐ VPS-க்குச் சுட்டிக்காட்டி, அதன் பிறகு நிறுவுங்கள்.
எனது முன்பதிவு உறுதிப்படுத்தல் மின்னஞ்சல்கள் ஏன் வருவதில்லை?
பெரும்பாலான நேரங்களில், server மின்னஞ்சலைத் தானே அனுப்ப முயற்சிப்பதே இதற்குக் காரணம். பெரும்பாலான VPS நிறுவனங்கள் புதிய கணக்குகளில் outbound port 25-ஐத் தடுக்கும், இதனால் இணைப்பு முடங்கும். அந்த port திறந்திருந்தாலும், புதிய முகவரிக்கு மின்னஞ்சல் அனுப்பும் நற்பெயர் (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 ஆகிய default மதிப்புகளை மாற்றியுள்ளீர்களா என்று சரிபார்க்கவும்; அவை உள்ளூர் development mailbox-ஐச் சுட்டிக்காட்டுகின்றன.
Self-hosted Cal.com, CalDAV-உடன் sync ஆகுமா அல்லது Google-உடன் மட்டுமா?
இரண்டுமே சாத்தியம், ஆனால் அவற்றின் முதிர்ச்சி நிலை மாறுபடும். CalDAV செயலி beta நிலையில் உள்ளது; இது Baikal, Radicale, Nextcloud மற்றும் Kerio Connect போன்ற server-களுடன் சரிபார்க்கப்பட்டுள்ளது. Apple iCloud-ஐ, app-specific password பயன்படுத்தி இதன் மூலம் இணைக்கலாம். Google Calendar மற்றும் Microsoft 365 ஆகிய இரண்டுமே இரு திசைகளிலும் sync ஆகும். ஆனால், self-hosted நிறுவலில் நீங்கள் சொந்தமாக OAuth client-ஐ உருவாக்கி, அதை GOOGLE_API_CREDENTIALS மூலம் வழங்க வேண்டும், ஏனெனில் hosted சேவையின் credentials மூலக் குறியீட்டில் (source) இருக்காது.
ஒரு வாரத்திற்குப் பிறகு எனது Google Calendar sync ஏன் நின்றுவிடுகிறது?
ஏனெனில் உங்கள் Google Cloud project இன்னும் Testing என்ற publishing நிலையிலேயே உள்ளது. அந்த நிலையில் உள்ள செயலிகளுக்கு Google வழங்கும் refresh tokens ஏழு நாட்களில் காலாவதியாகிவிடும். எனவே, இணைப்பு முதலில் வேலை செய்யும், ஆனால் அடுத்த முறை token புதுப்பிக்கப்படும்போது நின்றுவிடும். செயலியின் பதிவில் (application log) invalid_grant பிழை தோன்றும். OAuth consent திரையை In production நிலைக்கு மாற்றி, calendar-ஐ ஒருமுறை மீண்டும் இணைக்கவும். நிலையை மாற்றாமல் மீண்டும் இணைத்தால், உங்களுக்கு மேலும் ஏழு நாட்கள் மட்டுமே கிடைக்கும்.
இவற்றில் எது 1 GB VPS-ல் இயங்கும்?
Easy!Appointments இயங்கும், ஏனெனில் இது PHP செயலி மற்றும் MySQL-ஐ மட்டுமே சார்ந்தது. Rallly குறைந்தபட்சம் 2 GB தேவை என்று குறிப்பிடுகிறது, அதன் தொகுப்பில் நான்கு சேவைகள் உள்ளன. Cal.com மற்றும் DayOtter ஆகியவை குறைந்தபட்சத் தேவையை அறிவிக்கவில்லை, ஆனால் PostgreSQL-உடன் கூடிய Next.js செயலி, மற்றும் DayOtter-ன் விஷயத்தில் Redis மற்றும் worker process ஆகியவற்றுக்கு 2 GB அல்லது அதற்கு மேற்பட்ட நினைவகம் தேவைப்படும். சிறிய server-ல் Cal.com-ஐ source-லிருந்து ஒருபோதும் build செய்யாதீர்கள்: அந்தத் திட்டத்தின் build வழிமுறைகளே 16 GB Node heap-ஐக் கேட்கின்றன, எனவே அதற்குப் பதிலாக prebuilt image-ஐப் பதிவிறக்கவும்.