חלופות ל-Calendly באירוח עצמי: השוואה מקיפה

התשובה הקצרה

חלופה ל-Calendly באירוח עצמי חייבת לבצע פעולה אחת שהכלים הפנימיים ב-VPS שלכם לעולם לא מבצעים: להגיב לציבור. דף קביעת התורים הוא המוצר. הוא זקוק לשם מתחם אמיתי ול-TLS (אבטחת שכבת תעבורה) כבר מהיום הראשון, ועליו לשלוח דואר לאנשים שמעולם לא שמעו על השרת שלכם.

ארבעה פרויקטים מכסים את התחום הריאלי. Cal.com הוא הקרוב ביותר ל-Calendly ובחירת ברירת המחדל עבור יועץ עצמאי. פשוט! Easy!Appointments הוא הקל מביניהם, מבוסס PHP ו-MySQL, ופועל היטב על VPS עם 1 GB זיכרון. Rallly הוא כלי לסקרים קבוצתיים ואין לו דף קביעת תורים כלל. DayOtter הוא המצטרף החדש ביותר, פלטפורמת תזמון ברישיון AGPLv3 הכוללת עוזר אישי המאשר פגישות לפני קביעתן.

שתי שאלות יכריעו איזה מהם תוכלו להריץ בפועל. האם הוא מסתנכרן דו-כיוונית עם היומן שבו אתם משתמשים ביומיום? והאם הוא מסוגל לשלוח דואר? השאלה השנייה היא המקום שבו רוב הגדרות האירוח העצמי של מערכות תזמון נכשלות בשקט, לכן היא מופיעה ראשונה.

שליחת דואר אלקטרוני יוצא היא החלק שנכשל

אישור הזמנה נשלח לתיבת דואר של אדם זר. זהו דואר טרנזקציונלי המגיע ל-Gmail או ל-Microsoft 365, והמקבלים הללו שופטים אתכם על סמך כתובת ה-IP השולחת ורשומות ה-DNS שלכם.

שליחה ישירה מה-VPS כמעט לעולם אינה עובדת. רוב הספקיות חוסמות את פורט 25 היוצא בחשבונות חדשים, לכן החיבור נתקע ומסתיים ב-timeout. גם במקומות שבהם פורט 25 פתוח, לכתובת VPS חדשה אין היסטוריית שליחה, וספקיות דואר גדולות מתייחסות לכתובות מטווחים של שירותי אירוח כחשודות. ההזמנה נכתבת למסד הנתונים, הדף מציג אישור, אך איש אינו מקבל דואר. מהצד של השרת שום דבר לא נראה שבור, וזו הסיבה לכך שהבעיה מתגלה בדרך כלל שבועות לאחר מכן על ידי לקוח שלא הגיע.

השתמשו ב-relay. כל ספק דואר טרנזקציונלי יעבוד, והיישום זקוק רק לשם מארח, פורט, שם משתמש וסיסמה. בדקו שהפורט נגיש לפני שאתם נוגעים בתצורת היישום:

nc -vz -w 5 "$SMTP_HOST" 587

שורה מסוג succeeded משמעותה שהנתיב פתוח. תקיעה או Connection refused משמעותם שהפורט חסום ברמת הרשת, ושום עריכה של .env לא תתקן זאת. שירותי relay מאזינים בפורט 587 או 465 בדיוק בגלל שפורט 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 על localhost בפורט 1025, שהיא תיבת דואר לפיתוח מקומי. השאירו את ברירת המחדל כפי שהיא והיישום ישלח הודעות אל הלא-כלום ללא שגיאה. 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) ברגע ששניהם עוברים בהצלחה. שלחו הזמנת בדיקה לכתובת אמיתית אצל ספקית גדולה, פתחו את כותרות ההודעה (headers), וודאו ששורות האימות מציגות pass. דף הזמנות שאינו מסוגל לשלוח דואר גרוע יותר מדף הזמנות שאינו קיים, כיוון שהוא נכשל בשקט.

אילו מנגנוני סנכרון לוח שנה תומכים בסנכרון דו-כיווני אמיתי

לסנכרון יש שני כיוונים, והם עלולים להיכשל בנפרד. כיוון הקריאה נוגע לזמינות: האפליקציה חייבת לראות את חסימות הזמן הקיימות שלכם, אחרת היא תציע משבצת זמן שבה אתם כבר תפוסים. כיוון הכתיבה נוגע לביצוע ההזמנה עצמה: האירוע המאושר חייב להופיע בלוח השנה שבו אתם משתמשים בפועל, ולא רק בתוך כלי ההזמנות.

Google Calendar ו־Microsoft 365 תומכים בשני הכיוונים, בתנאי אחד בהתקנה בניהול עצמי (self-hosted). עליכם ליצור את ה־OAuth (open authorization) client בעצמכם, כיוון ש־client ID של המוצר המנוהל אינו נמצא בקוד המקור. עבור Cal.com מדובר ב־GOOGLE_API_CREDENTIALS בתוך .env, המכיל את ה־JSON שאתם מורידים מתוך ה־Google Cloud console. האפליקציה DayOtter מקבלת אישורי OAuth של Google ושל Microsoft באותה הדרך.

שני דברים נוטים להשתבש כאן, וכדאי להכיר את שניהם לפני שמתחילים. ראשית, ה־redirect URI שאתם רושמים חייב להתאים בדיוק לכתובת הציבורית שלכם, כולל ה־scheme וכל נתיב סופי, אחרת Google תחסום את החיבור עם redirect_uri_mismatch במסך האישור. שנית, פרויקט Google שנשאר במצב פרסום Testing מנפיק אסימוני רענון (refresh tokens) שתוקפם פג לאחר שבעה ימים. הסנכרון יעבוד לאורך כל השבוע ואז ייעצר, ולוגי האפליקציה יציגו invalid_grant בניסיון הרענון הבא. העבירו את מסך האישור למצב In production, או שתצטרכו לבצע חיבור מחדש ידני בכל יום שני.

CalDAV (הרחבות לוח שנה ל־WebDAV) היא האופציה הפתוחה, אך התמיכה בה דלה יותר. Cal.com מפיצה אפליקציית CalDAV שעדיין מסומנת כ־beta, ואומתה מול שרתים הכוללים את Baikal, Radicale, Nextcloud ו־Kerio Connect. שירות Apple iCloud עובד דרך אותה אפליקציה, אך דורש סיסמה ייעודית לאפליקציה (app-specific password) ולא את סיסמת ה־Apple ID הרגילה שלכם. DayOtter מציגה את Apple דרך CalDAV לצד Google ו־Microsoft 365.

פיד ICS אינו סנכרון. כתובת .ics שאליה נרשמים היא לקריאה בלבד מעצם הגדרתה, לכן היא יכולה לחסום זמן בדף ההזמנות שלכם, אך היא לעולם לא תוכל לקבל את ההזמנה. אם כלי מסוים מציע רק ICS עבור לוח השנה שלכם, יש לכם רק חצי מהתשתית הנדרשת ותיאלצו להעתיק אירועים ידנית.

Easy!Appointments מסנכרן את Google Calendar ולא שום דבר אחר. Rallly אינו קורא זמינות כלל: הוא אוסף הצבעות על קבוצת תאריכים מועמדים. זהו הכלי הנכון עבור "מתי ששתנו יכולים להיפגש" והכלי הלא נכון עבור "קבעו איתי 30 דקות".

דף הזמנות הוא ציבורי, לכן TLS הוא בעדיפות עליונה

רוב השירותים שאנשים מארחים בעצמם הם פרטיים. ויקי, לוח מודעות או לוח בקרה יכולים כולם לשבת מאחורי VPN או אימות SSO ולעולם לא להיחשף לאינטרנט הפתוח. קישור להזמנות אינו יכול. כל מי שתשלחו לו את הקישור חייב להיות מסוגל לטעון אותו, מה שמשנה את ההגדרה בשלושה אופנים קונקרטיים.

עליכם להחזיק שם מתחם עם רשומת A המצביעה על ה-VPS, עוד לפני התקנת דבר מה. עליכם להצטייד בתעודה כבר ביום הראשון, כיוון שדפדפנים מסמנים טופס HTTP רגיל כלא מאובטח, והלקוח שלכם מזין בו את שמו ואת כתובת האימייל שלו. כמו כן, עליכם להגדיר את ה-URL הציבורי של היישום כראוי בקובץ התצורה שלו, כיוון שערך זה מוטמע בקישורים בתוך הודעות אימייל יוצאות ובכתובות ה-OAuth redirect. הגדירו את NEXT_PUBLIC_WEBAPP_URL ב-Cal.com, את DOMAIN ב-Rallly, את BASE_URL ב-Easy!Appointments, או את DAYOTTER_DOMAIN בזמן ההתקנה, וקבעו אותו לכתובת ה-https:// שבה תשתמשו בפועל.

Rallly ו-DayOtter פותרים עבורכם את נושא ה-TLS. ה-stack המצורף של Rallly כולל את Traefik ומנפיק תעודות Let's Encrypt באמצעות הכתובת ב-ACME_EMAIL. מתקין ה-DayOtter מקים את Caddy עם HTTPS אוטומטי. Cal.com ו-Easy!Appointments אינם עושים זאת, לכן עליכם להציב nginx בחזית ולהנפיק את התעודה בעצמכם, באותו אופן שבו הייתם עושים זאת עבור תעודת Let's Encrypt ב-nginx עם Certbot. קשרו את מכולת היישום ל-127.0.0.1 כך שהדרך היחידה פנימה תהיה דרך ה-proxy שבשליטתכם. אם על אותו שרת כבר רץ חלופה ל-Trello באירוח עצמי עבור הלוחות הפנימיים שלכם, השאירו אותה מאחורי מנגנון האימות הקיים שלכם והקצו רק למארח ההזמנות בלוק שרת (server block) ציבורי.

התקנת Cal.com על ה-VPS שלכם

תצורת ה-Docker נמצאת במאגר נפרד, וה-images מוכנים מראש ב-Docker Hub, לכן עליכם לבצע 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

הערך האקראי הראשון מוזן ב-NEXTAUTH_SECRET והשני ב-CALENDSO_ENCRYPTION_KEY. שניהם נדרשים. הגדירו את DATABASE_URL והפנו את NEXT_PUBLIC_WEBAPP_URL לכתובת הציבורית שלכם. ה-stack המצורף כולל את יישום ה-web, את PostgreSQL ואת Prisma Studio; התיעוד מספק את docker compose up -d calcom להרצת היישום לבדו מול מסד נתונים שאתם מארחים במקום אחר, וזהו המצב הרצוי לאחר סיום ההתקנה.

בצעו pull ל-image; אל תבנו אותו על ה-VPS. ההוראות של הפרויקט מנחות לייצא את NODE_OPTIONS="--max-old-space-size=16384" בעת בנייה מקוד המקור, מה שדורש 16 GB של heap עבור Node בלבד. בחומרה מבוססת ARM, הוסיפו את הסיומת -arm לתגית ה-image. הפרויקט לא מפרסם דרישות מינימום להרצת ה-image המוכן, לכן התייחסו ל-2 GB עבור היישום ו-PostgreSQL כאל הערכה לעבודה ולא כאל נתון רשמי, ועקבו אחר צריכת הזיכרון במהלך השבוע הראשון.

בדקו שהשירות עלה:

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

הפקודה curl אמורה להדפיס HTTP/2 200. קבלת 502 Bad Gateway מ-nginx בזמן שה-container מופיע כפעיל מעידה בדרך כלל על כך שהאתחול הראשון עדיין מבצע migrations למסד הנתונים. המתינו מספר דקות וקראו את הלוגים לפני שתסיקו שהשירות תקול. ה-webhooks של Cal.com מופעלים בכל הזמנה מאושרת, כך שהזמנה יכולה להפעיל כל אוטומציה שכבר קיימת אצלכם, לדוגמה מופע n8n הנגיש ב-HTTPS על ה-VPS שלכם.

ליבת המערכת מופצת תחת רישיון AGPLv3, כאשר חלק מהתכונות כלולות בספריית enterprise תחת רישיון מסחרי נפרד. קראו את הרישיון לפני שאתם בונים תהליך עסקי בתשלום על בסיס תכונות ה-team.

Easy!Appointments על שרת 1 GB

הדרישות הן Apache או Nginx, גרסת PHP 8.2 ומעלה, ו-MySQL. קיימת תמונה רשמית ב-alextselegidis/easyappointments.

אזהרה אחת לפני שמתחילים: ה-docker-compose.yml במאגר הוא סביבת פיתוח. הוא מצפה שתפתחו shell בתוך המכולה ותריצו את npm install && composer install && npm start. זה אינו פריסה (deployment). השתמשו בתמונה המפורסמת במקום זאת:

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 הציבורית. טעות כאן תגרום לקישורי הזמנת התורים בתוך הודעות האישור להצביע על מארח שהלקוח שלכם לא יכול להגיע אליו. התמונה מגישה HTTP רגיל בפורט 80 ללא תעודה משלה, וזו הסיבה שהפורט ממופה ל-127.0.0.1 ו-Nginx מבצע TLS termination בחזית. אם תחביר ה-compose חדש לכם, התחילו ב-יסודות Docker Compose על שרת VPS וחזרו לכאן.

זוהי האופציה הקלה ביותר כאן בפער ניכר. שתי מכולות, יישום PHP ו-MySQL, יושבות בנוחות על VPS של 1 GB. המחיר הוא בנגישות: Google Calendar הוא ה-backend היחיד ליומן, והממשק הוא לוח בקרה ניהולי מסורתי ולא תהליך הזמנה מודרני. אם היומן שלכם הוא Microsoft 365, Fastmail או Nextcloud, האופציה הזו נפסלת עוד לפני שהתחלתם.

Rallly עבור סקרים קבוצתיים

Rallly עונה על צורך שונה. הוא אינו מפרסם את הזמינות שלך. הוא מציג קבוצת מועדים אפשריים בפני קבוצה ואוסף הצבעות; זהו הכלי המתאים לישיבות הנהלה, אך הוא אינו שימושי עבור קישור לתיאום פגישות עם לקוחות.

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

קרא כל סקריפט לפני שאתה מזרים אותו (pipe) למעטפת (shell). החלף את 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 פנויים, ודומיין המצביע אל השרת. ה-stack המצורף כולל את Traefik עבור HTTPS, את יישום ה-web, את PostgreSQL, ואת Garage עבור אחסון אובייקטים תואם S3. הגדר את DOMAIN, SECRET_PASSWORD באורך של לפחות 32 תווים, את SUPPORT_EMAIL ואת INITIAL_ADMIN_EMAIL. אם אתה כבר מריץ reverse proxy, הגדר את PROXY_MODE=external ואת WEB_PORT, ו-Traefik לא יתערב. אם אתה כבר מריץ אחסון אובייקטים תואם S3 בניהול עצמי עם MinIO, כוון את משתני ה-S3_* אליו והסר את ה-container של Garage.

SMTP אינו אופציונלי כאן, כיוון שהכניסה למערכת מתבצעת באמצעות magic link. ללא relay תקין, אף אחד לא יוכל להתחבר, כולל חשבון ה-admin שיצרת זה עתה. זוהי הגרסה ה"טובה" של כשל בדואר אלקטרוני: הוא עוצר אותך כבר בכניסה, במקום לגרום לאובדן הזמנה של לקוח שלושה שבועות מאוחר יותר.

DayOtter, המצטרפת החדשה ביותר

DayOtter היא פלטפורמת תזמון ברישיון AGPLv3 הכוללת עוזר אישי מובנה. התקנת ה-production מתבצעת באמצעות פקודה אחת:

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

קראו את הפקודה לפני הרצתה, כפי שצוין לעיל. המתקין מגדיר את Docker, מייצר secrets ומעלה את כל ה-stack: יישום ה-web מבוסס Next.js, תהליך רקע (worker) המטפל בתזכורות, סנכרון יומנים ו-webhooks, מסד נתונים PostgreSQL, שרת Redis, ו-Caddy עם HTTPS אוטומטי.

התמיכה ביומנים היא הרחבה ביותר מבין הארבע. היא כוללת את Google, Microsoft 365, Apple דרך CalDAV, ועדכוני ICS (בכפוף להסתייגות לגבי ICS שצוינה לעיל). כל אינטגרציה אחרת דורשת הפעלה אקטיבית באמצעות משתני סביבה, כולל SMTP או Resend עבור דואר אלקטרוני, ANTHROPIC_API_KEY עבור העוזר האישי, Twilio עבור SMS, ו-Stripe עבור תשלומים. העוזר האישי פועל במודל של אישור תחילה: הוא מציע הצעה, אתם מאשרים, ושום דבר לא מגיע ליומן שלכם ללא אישור מפורש. השאירו את ה-API key ריק, וחלק זה של המוצר פשוט לא יפעל.

הרישוי ברור עבור מי שמארח את השירות בעצמו. הליבה מופצת תחת רישיון AGPLv3, וספריית ee/ מכילה רישיון מסחרי המיועד לענן בלבד, אשר נותר לא פעיל אלא אם כן מוגדר המשתנה DAYOTTER_CLOUD=1. המשמעות היא שתכונות הצוות, אשר בתוכנית המנוהלת עולות 9 דולר למשתמש בכל חודש (נכון לאוגוסט 2026), זמינות להפעלה על השרת שלכם.

זהו גם ה-stack הכבד ביותר ברשימה זו והפרויקט הצעיר ביותר. הריצו אותו לצד קישור התזמון הקיים שלכם למשך שבועיים, קבלו הזמנות אמיתיות דרך שניהם, וקראו את הלוגים של ה-worker לפני שתעבירו את הלקוחות שלכם אליו.

מה העלות האמיתית של כל stack

מספר המכולות הוא המדד האמין ביותר לצריכת המשאבים של stack בשרת VPS קטן, שכן כל שירות דורש כמות זיכרון בסיסית משלו. אלו הם המספרים מתוך ה-Docker stack הרשמי של כל פרויקט, כפי שנבדקו באוגוסט 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 מכולות ומתאים ל-1 GB. ה-stack המצורף של Rallly כולל 4 מכולות, והתיעוד שלו דורש 2 GB. תוכנית ההתקנה של DayOtter מפעילה 5 מכולות, וזו הסיבה שהיא דורשת את השרת החזק ביותר מבין ה-4 המפורטים כאן. Cal.com ו-DayOtter אינם מפרסמים דרישת זיכרון מינימלית כלל, לכן 2 GB הוא נקודת המוצא שלי עבור שניהם, ולא נתון נתמך רשמית.

שניים מהמספרים הללו יורדים אם כבר יש לכם תשתית פעילה. המכולות של Traefik ו-Garage ב-Rallly אינן נחוצות כאשר מפנים את השירות ל-proxy ולאחסון אובייקטים קיימים. הכלי Prisma Studio של Cal.com הוא כלי פיתוח שאין להשאיר פעיל בשרת ציבורי.

באיזו חלופה ל-Calendly לאירוח עצמי כדאי לבחור

יועץ עצמאי צריך להריץ את Cal.com. זהו הפרויקט היחיד כאן שמשלב דף זימון תורים מוכר, תמונות (images) מוכנות מראש שחוסכות ל-VPS שלכם תהליך build של Node, ונתיב CalDAV עבור מי מאיתנו שלא מנהל יומן ב-Google או ב-Microsoft. מסד נתונים אחד מסוג PostgreSQL ומכולת (container) יישום אחת הם נטל תחזוקה שתוכלו לשאת במשך שנים. הקצו אחר צהריים אחד עבור ה-OAuth client וממסר הדואר (mail relay), ושימו לב שאפליקציית ה-CalDAV עדיין נמצאת בשלב בטא, לכן בצעו בדיקה מלאה של זימון תור אחד מקצה לקצה לפני שתפרסמו את הקישור.

צוות קטן צריך לבחון את DayOtter. אלגוריתם round robin משוקלל וזימון תורים קבוצתי כלולים בליבת ה-AGPLv3, כך שאירוח עצמי מעניק לכם תכונות שעבורן שירותים מנוהלים גובים תשלום לפי משתמש, ותהליך ה-worker בנוי עבור התזכורות וה-webhooks שצוותים באמת מסתמכים עליהם. המחיר הוא בשלות: זהו הפרויקט החדש ביותר ברשימה זו, לכן הריצו אותו במקביל בתחילה ושמרו על הקישור הישן פעיל עד שתעקבו אחר חודש מלא של זימונים.

שני מקרים מצומצמים יותר: אם כל מה שאתם צריכים הוא סקר למציאת זמן שבו הקבוצה יכולה להיפגש, התקינו את Rallly ועצרו שם. אם יש לכם VPS של 1 GB, אתם חיים בתוך Google Calendar, ואתם רוצים את הכלי הקטן ביותר שמקבל זימונים, Easy!Appointments יאריך ימים יותר מכל אפשרות מהודרת אחרת שתוכלו לשים על השרת הזה. לשאלה הרחבה יותר מה עוד ראוי למקום על אותו שרת, ראו מה כדאי לארח באופן עצמי ב-2026.

FAQ

האם ניתן להריץ דף הזמנות בניהול עצמי ללא שם מתחם?

לא. כל אחד מהיישומים הללו כותב את ה-URL הציבורי שלו בתוך הקישורים שבמיילים לאישור, וגם Google וגם Microsoft משוות את ה-OAuth redirect URI מול אותו ערך בדיוק, לכן כתובת IP חשופה תציג לכם redirect_uri_mismatch במסך האישור. בנוסף, Let’s Encrypt לא תנפיק תעודה עבור כתובת IP, כך שהדף ייטען ב-HTTP רגיל והדפדפן יסמן את הטופס כלא מאובטח. רכשו תחילה שם מתחם, הצביעו עם רשומת A אל ה-VPS, ורק אז בצעו את ההתקנה.

מדוע מיילים לאישור הזמנה לא מגיעים?

כמעט תמיד בגלל שהשרת מנסה לשלוח את הדואר בעצמו. רוב ספקי ה-VPS חוסמים את פורט 25 היוצא בחשבונות חדשים, לכן החיבור נתקע. גם במקומות שבהם הפורט פתוח, לכתובת חדשה אין מוניטין שליחה וספקי דואר גדולים יסרבו לקבל ממנה הודעות. הגדירו ביישום ממסר דואר (transactional mail relay) בפורט 587, ודאו שהפורט נגיש באמצעות nc -vz -w 5 "$SMTP_HOST" 587, ולאחר מכן פרסמו את רשומות ה-SPF וה-DKIM שהממסר מספק לכם. אם אתם מריצים את Cal.com, ודאו שהחלפתם את ערכי ברירת המחדל EMAIL_SERVER_HOST=localhost ו-EMAIL_SERVER_PORT=1025 שמגיעים עם התוכנה, שכן הם מצביעים על תיבת דואר מקומית לפיתוח.

האם Cal.com בניהול עצמי מסתנכרן עם CalDAV, או רק עם Google?

עם שניהם, ברמות בשלות שונות. אפליקציית ה-CalDAV מסומנת כ-beta ועברה אימות מול שרתים הכוללים את Baikal, Radicale, Nextcloud ו-Kerio Connect, וגם Apple iCloud עובד דרכה באמצעות סיסמה ספציפית ליישום. Google Calendar ו-Microsoft 365 מסתנכרנים לשני הכיוונים, אך בהתקנה בניהול עצמי עליכם ליצור לקוח OAuth משלכם ולספק אותו דרך GOOGLE_API_CREDENTIALS, כיוון שהפרטים של השירות המנוהל אינם נמצאים בקוד המקור.

מדוע הסנכרון עם Google Calendar מפסיק לעבוד אחרי שבוע?

מכיוון שפרויקט ה-Google Cloud עדיין נמצא בסטטוס פרסום Testing. Google מנפיקה אסימוני רענון (refresh tokens) ליישומים במצב זה שתוקפם פג לאחר שבעה ימים, לכן החיבור עובד ואז קורס ברענון האסימון הבא, ויומן היישום מציג invalid_grant. העבירו את מסך הסכמת ה-OAuth למצב In production וחברו את היומן מחדש פעם אחת. חיבור מחדש ללא שינוי הסטטוס יקנה לכם שבעה ימים נוספים בלבד, ולא מעבר לכך.

אילו מהיישומים הללו ירוצו על VPS עם 1 GB זיכרון?

Easy!Appointments ירוץ, שכן מדובר ביישום PHP יחד עם MySQL. Rallly מציינת דרישת מינימום של 2 GB וה-stack המצורף שלה מריץ ארבעה שירותים. Cal.com ו-DayOtter לא מפרסמות דרישת מינימום, אך יישום Next.js עם PostgreSQL, ובמקרה של DayOtter גם Redis ותהליך עבודה (worker process), אומרים שעליכם לתכנן על 2 GB או יותר. לעולם אל תבנו את Cal.com מקוד המקור על שרת קטן: הוראות הבנייה של הפרויקט עצמו דורשות 16 GB עבור ה-Node heap, לכן משכו את ה-image המוכן מראש במקום זאת.