Self-hosted Calendly متبادل: Cal.com بمقابلہ دیگر

مختصر جواب

Self-hosted Calendly متبادل کو وہ کام کرنا ہوتا ہے جو آپ کے VPS پر موجود اندرونی tools کبھی نہیں کرتے: عوامی صارفین کو جواب دینا۔ Booking page ہی اصل product ہے۔ اسے پہلے دن سے حقیقی domain name اور TLS (transport layer security) درکار ہوتی ہے، اور اسے ایسے لوگوں تک mail پہنچانی ہوتی ہے جنہوں نے آپ کے server کا نام کبھی نہیں سنا۔

چار projects عملی اختیارات کا احاطہ کرتے ہیں۔ Cal.com، Calendly کے سب سے قریب ہے اور اکیلے consultant کے لیے default انتخاب ہے۔ Easy!Appointments ہلکا option ہے، PHP اور MySQL پر چلتا ہے، اور 1 GB VPS پر آسانی سے کام کرتا ہے۔ Rallly ایک group poll tool ہے اور اس میں booking page موجود ہی نہیں۔ DayOtter جدید ترین entrant ہے، ایک AGPLv3 scheduling platform جس کے سامنے confirm-first assistant موجود ہے۔

دو سوال طے کرتے ہیں کہ آپ حقیقتاً کون سا option چلا سکتے ہیں۔ کیا یہ اس calendar کے ساتھ دونوں سمتوں میں sync کرتا ہے جسے آپ پہلے ہی استعمال کرتے ہیں؟ اور کیا یہ mail بھیج سکتا ہے؟ زیادہ تر self-hosted booking setups خاموشی سے دوسرے سوال پر ناکام ہوتے ہیں، اس لیے اسی سے آغاز کیا گیا ہے۔

آؤٹ باؤنڈ ای میل وہ حصہ ہے جو ناکام ہوتا ہے

ایک booking confirmation کسی اجنبی کے inbox میں پہنچتی ہے۔ یہ transactional mail ہے جو Gmail یا Microsoft 365 تک پہنچ رہی ہے، اور یہ وصول کنندگان آپ کی sending IP address اور DNS records کی بنیاد پر آپ کا جائزہ لیتے ہیں۔

VPS سے براہِ راست ای میل بھیجنا تقریباً کبھی کام نہیں کرتا۔ زیادہ تر providers نئے accounts پر outbound TCP port 25 کو block کر دیتے ہیں، اس لیے connection معلق رہتا ہے اور آخرکار timeout ہو جاتا ہے۔ جہاں port 25 کھلا بھی ہو، وہاں نئی VPS address کی کوئی sending history نہیں ہوتی، اور بڑے وصول کنندگان نامعلوم hosting-range addresses کو مشتبہ سمجھتے ہیں۔ Booking database میں محفوظ ہو جاتی ہے، page پر confirmed دکھائی دیتا ہے، لیکن کسی کو ای میل نہیں ملتی۔ Server کی طرف سے کچھ بھی خراب دکھائی نہیں دیتا، اسی لیے یہ مسئلہ عموماً کئی ہفتوں بعد اس client کے ذریعے سامنے آتا ہے جو کبھی حاضر ہی نہیں ہوا۔

Relay استعمال کریں۔ کوئی بھی transactional mail provider کام کرے گا، اور app کو صرف hostname، port، user اور password درکار ہوتے ہیں۔ Application config تبدیل کرنے سے پہلے جانچیں کہ port قابلِ رسائی ہے:

nc -vz -w 5 "$SMTP_HOST" 587

succeeded line کا مطلب ہے کہ راستہ کھلا ہے۔ Hang یا Connection refused کا مطلب ہے کہ port network level پر block ہے، اور .env میں جتنی بھی editing کی جائے، اس سے مسئلہ حل نہیں ہوگا۔ Relays 587 یا 465 پر listen کرتے ہیں، کیونکہ 25 اکثر block ہوتا ہے۔

ہر 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 برقرار رہنے کی صورت میں app بغیر کسی error کے ای میلیں ایک غیر موجود mailbox میں بھیجتی ہے۔ Rallly SMTP_HOST، SMTP_PORT، SMTP_USER اور SMTP_PWD استعمال کرتا ہے۔ DayOtter SMTP settings یا Resend key استعمال کرتا ہے۔ Easy!Appointments اپنی notifications application سے بھیجتا ہے، اس لیے حقیقی booking قبول کرنے سے پہلے اس کے settings page میں اسے اسی relay کی طرف بھیجیں۔

اس کے بعد وہ DNS records publish کریں جو آپ کا relay فراہم کرتا ہے۔ 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 نہ ہونے سے بھی بدتر ہے، کیونکہ یہ خاموشی سے ناکام ہوتا ہے۔

کون سے calendar backends واقعی دونوں سمتوں میں sync کرتے ہیں

Sync کی دو سمتیں ہوتی ہیں، اور یہ الگ الگ ناکام ہو سکتی ہیں۔ read سمت availability کے لیے ہے: ایپ کو آپ کے پہلے سے موجود busy blocks نظر آنے چاہییں، ورنہ یہ آپ کو ایسا slot دے دے گی جس میں آپ پہلے ہی مصروف ہیں۔ write سمت booking کے لیے ہے: confirmed event اسی calendar میں ظاہر ہونا چاہیے جسے آپ واقعی دیکھتے ہیں، صرف booking tool کے اندر نہیں۔

Google Calendar اور Microsoft 365 دونوں سمتوں میں کام کرتے ہیں، لیکن self-hosted install میں ایک شرط ہے۔ OAuth (open authorization) client آپ کو خود بنانا ہوگا، کیونکہ hosted product کا client ID source code میں موجود نہیں ہوتا۔ Cal.com کے لیے یہ GOOGLE_API_CREDENTIALS میں .env ہے، جس میں Google Cloud console سے download کی گئی JSON موجود ہوتی ہے۔ DayOtter بھی Google اور Microsoft OAuth credentials اسی طرح لیتا ہے۔

یہاں دو مسائل پیدا ہوتے ہیں، اور شروع کرنے سے پہلے دونوں کو سمجھنا ضروری ہے۔ اول، رجسٹر کی گئی redirect URI کو آپ کے public URL سے بالکل مطابقت رکھنی چاہیے، جس میں scheme اور آخر میں موجود path بھی شامل ہیں، ورنہ Google consent screen پر redirect_uri_mismatch کے ساتھ connection روک دیتا ہے۔ دوم، Google project کو Testing publishing status میں چھوڑنے سے ایسے refresh tokens جاری ہوتے ہیں جو سات دن بعد expire ہو جاتے ہیں۔ پوری ہفتہ بھر Sync کام کرتی ہے، پھر رک جاتی ہے، اور اگلی refresh پر app logs میں invalid_grant ظاہر ہوتا ہے۔ Consent screen کو In production پر منتقل کریں، یا ہر Monday دستی طور پر دوبارہ connection بنانا قبول کریں۔

CalDAV (calendaring extensions to WebDAV) open option ہے، لیکن اس کی 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 کو بھی CalDAV کے ذریعے فہرست میں شامل کرتا ہے۔

ICS feed sync نہیں ہوتی۔ subscribed .ics URL ڈیزائن کے لحاظ سے read-only ہوتا ہے، اس لیے یہ آپ کے booking page پر وقت کو مصروف دکھا سکتا ہے، لیکن booking وصول نہیں کر سکتا۔ اگر کوئی tool آپ کے calendar کے لیے صرف ICS پیش کرتا ہے تو آپ کے پاس integration کا صرف نصف حصہ ہے، اور events پھر بھی دستی طور پر copy کرنے پڑیں گے۔

Easy!Appointments صرف Google Calendar کے ساتھ sync کرتا ہے، کسی اور کے ساتھ نہیں۔ Rallly availability بالکل نہیں پڑھتا؛ یہ ممکنہ dates کے ایک set پر votes جمع کرتا ہے۔ یہ اس سوال کے لیے درست tool ہے کہ "ہم چھ افراد کب مل سکتے ہیں"، لیکن اس سوال کے لیے غلط tool ہے کہ "میرے ساتھ 30 منٹ کی booking کریں"۔

Booking page عوامی ہے، اس لیے TLS پہلے آتا ہے

زیادہ تر self-hosted سافٹ ویئر نجی ہوتا ہے۔ Wiki، board اور dashboard کو VPN یا SSO login کے پیچھے رکھا جا سکتا ہے، اور وہ کبھی open internet پر ظاہر نہیں ہوتے۔ Booking link ایسا نہیں ہوتا۔ جس شخص کو آپ یہ link بھیجیں گے، اسے اسے load کرنا ہوگا۔ اس سے setup میں 3 عملی تبدیلیاں آتی ہیں۔

کسی بھی software کو install کرنے سے پہلے آپ کو ایک domain name درکار ہے، جس کا A record VPS کی طرف اشارہ کرے۔ پہلے دن ہی certificate درکار ہے، کیونکہ browsers عام HTTP form کو not secure دکھاتے ہیں اور آپ کا client اس میں اپنا نام اور email درج کر رہا ہوتا ہے۔ آپ کو app کا public URL بھی اس کی config میں درست طور پر set کرنا ہوگا، کیونکہ یہ value outgoing email کے links اور OAuth redirect URIs میں شامل کی جاتی ہے۔ Cal.com میں NEXT_PUBLIC_WEBAPP_URL، Rallly میں DOMAIN، Easy!Appointments میں BASE_URL، یا install کے وقت DAYOTTER_DOMAIN set کریں، اور اسے https:// کے اس address پر set کریں جسے آپ حقیقت میں استعمال کریں گے۔

Rallly اور DayOtter آپ کے لیے TLS کا انتظام کرتے ہیں۔ Rallly کے bundled stack میں Traefik شامل ہے، جو ACME_EMAIL میں موجود address استعمال کرتے ہوئے Let's Encrypt certificates جاری کرتا ہے۔ DayOtter کا installer خودکار HTTPS کے ساتھ Caddy چلا دیتا ہے۔ Cal.com اور Easy!Appointments ایسا نہیں کرتے، اس لیے آپ کو nginx کو سامنے رکھنا ہوگا اور certificate خود جاری کرنا ہوگا، بالکل اسی طرح جیسے آپ nginx پر Certbot کے ذریعے Let's Encrypt certificate کے لیے کرتے ہیں۔ App container کو 127.0.0.1 پر bind کریں تاکہ اندر آنے کا واحد راستہ آپ کے زیر انتظام proxy ہو۔ اگر اسی box پر پہلے ہی آپ کے داخلی boards کے لیے self-hosted Trello متبادل چل رہا ہے تو اسے موجودہ auth کے پیچھے رکھیں، اور صرف booking host کو public server block دیں۔

آپ کے VPS پر Cal.com

Docker configuration اپنی الگ repository میں موجود ہے، اور images Docker Hub پر پہلے سے build شدہ ہیں، اس لیے انہیں pull کریں، build نہ کریں۔

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 میں درج کریں۔ دونوں values ضروری ہیں۔ DATABASE_URL کو set کریں اور NEXT_PUBLIC_WEBAPP_URL کو اپنے public address کی طرف point کریں۔ bundled stack میں web app، PostgreSQL اور Prisma Studio شامل ہیں؛ docs میں docker compose up -d calcom دیا گیا ہے تاکہ app کو اس database کے ساتھ اکیلے چلایا جا سکے جسے آپ کسی اور جگہ host کرتے ہیں۔ Installation مکمل ہونے کے بعد آپ کو یہی طریقہ استعمال کرنا چاہیے۔

Image کو pull کریں، اسے VPS پر build نہ کریں۔ Project کی اپنی instructions کے مطابق source سے build کرتے وقت NODE_OPTIONS="--max-old-space-size=16384" export کرنا ہوتا ہے، جو صرف Node کے لیے 16 GB heap ہے۔ ARM hardware پر image tag کے آخر میں -arm suffix شامل کریں۔ Project پہلے سے build شدہ image چلانے کے لیے کم از کم system requirements شائع نہیں کرتا، اس لیے app اور PostgreSQL کے لیے 2 GB کو documented requirement نہیں بلکہ میری عملی working figure سمجھیں، اور پہلے ہفتے کے دوران memory monitor کریں۔

دیکھیں کہ یہ 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 ملے تو عموماً first boot کے دوران database migrations ابھی apply ہو رہی ہوتی ہیں۔ چند منٹ انتظار کریں اور اسے broken قرار دینے سے پہلے logs پڑھیں۔ Cal.com کے webhooks ہر confirmed booking پر fire ہوتے ہیں، اس لیے ایک booking آپ کی پہلے سے چلنے والی automation کو trigger کر سکتی ہے، مثلاً آپ کے 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 نہیں ہے۔ اس کے بجائے published 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 میں public HTTPS address ہونا چاہیے۔ اگر یہ غلط ہو تو confirmation emails میں موجود booking links ایسے host کی طرف اشارہ کریں گے جس تک آپ کا client رسائی حاصل نہیں کر سکتا۔ image port 80 پر سادہ HTTP فراہم کرتی ہے اور اس کا اپنا certificate نہیں ہوتا۔ اسی لیے 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 ایک مختلف مسئلے کو حل کرتا ہے۔ یہ آپ کی دستیابی شائع نہیں کرتا۔ یہ ممکنہ اوقات کی فہرست گروپ کے سامنے رکھتا ہے اور ووٹ جمع کرتا ہے۔ بورڈ میٹنگ کے لیے یہی مطلوب ہے، لیکن 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

دستاویز میں درج requirements کے مطابق کم از کم 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 راستے سے ہٹ جائے گا۔ اگر آپ پہلے ہی MinIO کے ساتھ self-hosted S3-compatible object store چلا رہے ہیں تو S3_* variables کو اس کی طرف point کریں اور Garage container ہٹا دیں۔

یہاں SMTP اختیاری نہیں ہے، کیونکہ sign-in magic link کے ذریعے ہوتا ہے۔ فعال relay کے بغیر کوئی بھی login نہیں کر سکتا، حتیٰ کہ وہ admin account بھی نہیں جو آپ نے ابھی بنایا ہے۔ email failure کی یہ بہتر صورت ہے: یہ آپ کو دروازے پر ہی روک دیتی ہے، بجائے اس کے کہ تین ہفتے بعد client کی booking ضائع ہو جائے۔

DayOtter، جدید ترین شامل ہونے والا

DayOtter ایک AGPLv3 شیڈولنگ پلیٹ فارم ہے جس کے ساتھ ایک اسسٹنٹ بھی شامل ہے۔ پروڈکشن انسٹالیشن کے لیے ایک کمانڈ کافی ہے:

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

اسے چلانے سے پہلے، اوپر دی گئی ہدایت کے مطابق اسے پڑھیں۔ انسٹالر Docker ترتیب دیتا ہے، secrets بناتا ہے، اور مکمل stack چلاتا ہے: Next.js web app، reminders، calendar sync اور webhooks سنبھالنے والا background worker، PostgreSQL، Redis، اور خودکار HTTPS کے ساتھ Caddy۔

چاروں میں اس کی calendar support سب سے وسیع ہے۔ Google، Microsoft 365، CalDAV کے ذریعے Apple، اور ICS feeds شامل ہیں، تاہم ICS کے لیے اوپر بیان کردہ caveat لاگو ہے۔ دیگر تمام integrations environment variables کے ذریعے opt-in ہیں، جن میں mail کے لیے SMTP یا Resend، اسسٹنٹ کے لیے ANTHROPIC_API_KEY، SMS کے لیے Twilio، اور payments کے لیے Stripe شامل ہیں۔ اسسٹنٹ confirm-first طریقہ استعمال کرتا ہے: یہ تجویز پیش کرتا ہے، آپ منظوری دیتے ہیں، اور واضح اجازت کے بغیر کوئی چیز آپ کے calendar میں شامل نہیں ہوتی۔ API key خالی چھوڑنے پر product کا یہ حصہ بالکل نہیں چلتا۔

Self-hosting کے لیے licensing واضح ہے۔ بنیادی حصہ AGPLv3 کے تحت ہے، جبکہ ee/ directory میں commercial cloud-only licence موجود ہے جو DAYOTTER_CLOUD=1 سیٹ ہونے تک غیر فعال رہتی ہے۔ اس کا مطلب ہے کہ hosted plan میں $9 فی seat فی ماہ کے حساب سے billed ہونے والی team features، August 2026 تک، آپ کے اپنے server پر دستیاب ہیں۔

یہ یہاں موجود تمام stacks میں سب سے بھاری اور project کے لحاظ سے سب سے نیا بھی ہے۔ اسے اپنے موجودہ booking link کے ساتھ دو ہفتے چلائیں، دونوں کے ذریعے حقیقی bookings لیں، اور clients کو منتقل کرنے سے پہلے worker logs دیکھیں۔

ہر stack کی اصل لاگت

Container count اس بات کا قابلِ اعتماد اندازہ ہے کہ کوئی stack ایک چھوٹے VPS سے کتنے وسائل طلب کرے گا، کیونکہ ہر service کے لیے memory کی اپنی کم از کم مقدار درکار ہوتی ہے۔ یہ counts ہر project کے اپنے شائع کردہ 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 میں سب سے بڑے server کی ضرورت ہوتی ہے۔ Cal.com اور DayOtter نے minimum memory کی کوئی مقدار شائع نہیں کی، اس لیے دونوں کے لیے 2 GB کو supported number کے بجائے میری ابتدائی تجویز سمجھیں۔

اگر infrastructure پہلے سے چل رہا ہو تو ان میں سے دو counts کم ہو جاتے ہیں۔ Rallly کے Traefik اور Garage containers اس وقت ہٹا دیے جا سکتے ہیں جب آپ اسے اپنے proxy اور object storage کی طرف point کریں۔ Cal.com کا Prisma Studio development tool ہے، جسے public server پر running نہیں چھوڑنا چاہیے۔

کون سا self-hosted Calendly متبادل منتخب کرنا چاہیے

اکیلے کام کرنے والے consultant کو Cal.com استعمال کرنا چاہیے۔ اس فہرست میں یہی واحد project ہے جو ایسا booking page فراہم کرتا ہے جسے لوگ فوراً پہچان لیتے ہیں، ایسی prebuilt images فراہم کرتا ہے جن سے آپ کے VPS پر Node build کرنے کی ضرورت نہیں رہتی، اور ہم جیسے صارفین کے لیے CalDAV کا راستہ فراہم کرتا ہے جو Google یا Microsoft پر calendar نہیں رکھتے۔ ایک PostgreSQL database اور ایک application container کئی سال تک قابلِ انتظام maintenance load رہتے ہیں۔ OAuth client اور mail relay کے لیے ایک دوپہر مختص کریں، اور یاد رکھیں کہ CalDAV app اب بھی beta ہے؛ اس لیے link شائع کرنے سے پہلے ایک حقیقی booking کو ابتدا سے آخر تک test کریں۔

چھوٹی team کو DayOtter کا جائزہ لینا چاہیے۔ Weighted round robin اور collective booking، AGPLv3 core میں شامل ہیں؛ اس لیے self-hosting سے آپ کو وہ features ملتے ہیں جن کے لیے hosted seat فیس وصول کرتا ہے، اور worker process ان reminders اور webhooks کے لیے بنایا گیا ہے جن پر team عملی طور پر انحصار کرتی ہے۔ اس کا نقصان maturity ہے: یہ اس فہرست کا newest project ہے۔ اس لیے پہلے اسے parallel چلائیں اور پرانا link اس وقت تک فعال رکھیں جب تک آپ bookings کا پورا ایک ماہ monitor نہ کر لیں۔

دو محدود صورتیں بھی ہیں۔ اگر آپ کو صرف ایسا poll چاہیے جس سے معلوم ہو سکے کہ group کب مل سکتا ہے، تو Rallly install کریں اور وہیں رک جائیں۔ اگر آپ کے پاس 1 GB VPS ہے، آپ Google Calendar استعمال کرتے ہیں، اور آپ کو booking لینے والی سب سے چھوٹی چیز چاہیے، تو Easy!Appointments اس box پر آپ کے نصب کیے جانے والے ہر زیادہ پیچیدہ option سے زیادہ عرصہ چلتا رہے گا۔ اسی server پر مزید کیا self-host کرنا مفید ہے، اس وسیع سوال کے لیے دیکھیں 2026 میں کیا self-host کرنا مفید ہے۔

FAQ

کیا میں domain name کے بغیر self-hosted booking page چلا سکتا ہوں؟

نہیں۔ یہ تمام ایپس confirmation emails کے اندر موجود links میں اپنا public URL درج کرتی ہیں، اور Google اور Microsoft دونوں OAuth redirect URI کو اسی value سے ملاتے ہیں، اس لیے bare IP address استعمال کرنے پر consent screen پر redirect_uri_mismatch ظاہر ہوتا ہے۔ Let's Encrypt کسی IP address کے لیے certificate بھی جاری نہیں کرتا، اس لیے page سادہ HTTP پر کھلتا ہے اور browser form کو غیر محفوظ قرار دیتا ہے۔ پہلے domain خریدیں، VPS کی طرف A record point کریں، پھر installation کریں۔

میری booking confirmation emails کبھی کیوں نہیں پہنچتیں؟

تقریباً ہمیشہ اس لیے کہ server خود mail deliver کرنے کی کوشش کر رہا ہوتا ہے۔ زیادہ تر VPS providers نئے accounts پر outbound port 25 بلاک کرتے ہیں، اس لیے connection معطل رہتا ہے۔ جہاں یہ port کھلا بھی ہو، وہاں نئے address کی sending reputation نہیں ہوتی اور بڑے receivers اسے مسترد کر دیتے ہیں۔ App کو port 587 پر transactional mail relay کے لیے configure کریں، nc -vz -w 5 "$SMTP_HOST" 587 سے تصدیق کریں کہ port قابل رسائی ہے، پھر relay کی فراہم کردہ SPF اور DKIM records publish کریں۔ اگر آپ Cal.com چلا رہے ہیں تو تصدیق کریں کہ آپ نے فراہم کردہ 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 کے ساتھ کی گئی ہے۔ Apple iCloud بھی app-specific password کے ذریعے اس کے ساتھ کام کرتا ہے۔ Google Calendar اور Microsoft 365 دونوں دو طرفہ sync کرتے ہیں، لیکن self-hosted installation میں آپ کو اپنا OAuth client بنانا ہوگا اور اسے GOOGLE_API_CREDENTIALS کے ذریعے فراہم کرنا ہوگا، کیونکہ hosted service کے credentials source میں شامل نہیں ہیں۔

میرا Google Calendar sync ایک ہفتے بعد کیوں رک جاتا ہے؟

کیونکہ Google Cloud project ابھی بھی Testing publishing status میں ہے۔ Google اس status والی apps کو ایسے refresh tokens جاری کرتا ہے جو سات دن بعد expire ہو جاتے ہیں۔ اس لیے connection پہلے کام کرتا ہے، پھر اگلے token refresh پر ختم ہو جاتا ہے، اور application log میں invalid_grant ظاہر ہوتا ہے۔ OAuth consent screen کو In production پر منتقل کریں اور calendar کو ایک بار دوبارہ connect کریں۔ Status تبدیل کیے بغیر دوبارہ connect کرنے سے مزید سات دن ملتے ہیں، اس سے زیادہ نہیں۔

ان میں سے کون سی app 1 GB VPS پر چل جائے گی؟

Easy!Appointments چل جائے گی، کیونکہ یہ MySQL کے ساتھ PHP application ہے۔ Rallly میں 2 GB minimum درج ہے اور اس کا bundled stack چار services چلاتا ہے۔ Cal.com اور DayOtter کوئی minimum شائع نہیں کرتے، لیکن 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 استعمال کریں۔