Mga Self-Hosted na Alternatibo sa Calendly, Ikumpara

Ang maikling sagot

May isang bagay na kailangang gawin ang isang self-hosted na alternatibo sa Calendly na hindi kailanman ginagawa ng internal tools sa iyong VPS: sumagot sa publiko. Ang booking page ang mismong produkto. Kailangan nito ng totoong domain name at TLS (transport layer security) mula sa unang araw, at kailangan nitong makapagpadala ng mail sa mga taong hindi pa nakarinig tungkol sa iyong server.

Apat na proyekto ang sumasaklaw sa mga makatotohanang opsyon. Ang Cal.com ang pinakamalapit sa Calendly at ang default na pili para sa isang solo consultant. Ang Easy!Appointments ang magaan na opsyon, gumagamit ng PHP at MySQL, at maayos na tumatakbo sa isang 1 GB VPS. Ang Rallly ay isang group poll tool at wala itong booking page. Ang DayOtter ang pinakabagong entrant, isang AGPLv3 scheduling platform na may confirm-first assistant sa unahan nito.

Dalawang tanong ang nagpapasya kung alin ang aktuwal mong mapapatakbo. Nagsi-sync ba ito sa dalawang direksiyon sa calendar na ginagamit mo na? At makakapagpadala ba ito ng mail? Dito tahimik na kadalasang pumapalya ang mga self-hosted booking setup, kaya ito ang unang tatalakayin.

Hindi gumagana ang outbound email

Napupunta ang booking confirmation sa inbox ng ibang tao. Transactional mail ito na dumarating sa Gmail o Microsoft 365, at sinusuri ka ng mga receiver batay sa sending IP address at sa iyong DNS records.

Halos hindi gumagana ang direktang pagpapadala mula sa VPS. Karamihan sa mga provider ay nagba-block ng outbound TCP port 25 sa mga bagong account, kaya nagha-hang ang connection at kalaunan ay nagti-time out. Kahit bukas ang port 25, walang sending history ang bagong VPS address, at itinuturing na kahina-hinala ng malalaking receiver ang mga address mula sa hindi kilalang hosting range. Naisusulat ang booking sa database, ipinapakitang confirmed ang page, pero walang nakatatanggap ng email. Walang mukhang sira sa server side, kaya karaniwan itong natutuklasan makalipas ang ilang linggo ng client na hindi kailanman dumating.

Gumamit ng relay. Gumagana ang anumang transactional mail provider, at kailangan lamang ng app ng hostname, port, user, at password. Tiyaking reachable ang port bago baguhin ang application config:

nc -vz -w 5 "$SMTP_HOST" 587

Ibig sabihin ng succeeded line ay bukas ang path. Ang pag-hang o Connection refused ay nangangahulugang naka-block ang port sa network level, at walang anumang pag-edit sa .env ang makapag-aayos nito. Nakikinig ang mga relay sa port 587 o 465 dahil madalas naka-block ang port 25.

Sariling paraan ng paggamit ng relay ang bawat project. Binabasa ng Cal.com ang EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER, at EMAIL_SERVER_PASSWORD, at tumatanggap din ito ng RESEND_API_KEY. Mag-ingat dito: itinuturo ng shipped .env.example ang EMAIL_SERVER_HOST sa localhost sa port 1025, na isang local development mailbox. Kapag iniwan ang default, nagpapadala ang app sa walang mailbox nang walang error. Ginagamit ng Rallly ang SMTP_HOST, SMTP_PORT, SMTP_USER, at SMTP_PWD. Gumagamit ang DayOtter ng SMTP settings o Resend key. Madali ito! Ipinapadala ng Easy!Appointments ang mga notification mula sa application, kaya ituro ito sa parehong relay mula sa settings page nito bago tumanggap ng totoong booking.

Pagkatapos, i-publish ang DNS records na ibinigay ng relay. Sinasabi ng SPF (sender policy framework) record kung aling mga server ang maaaring magpadala para sa iyong domain, at pinipirmahan ng DKIM (domainkeys identified mail) key ang bawat mensahe upang mapatunayan ng receiver na hindi ito binago. Magdagdag ng DMARC (domain-based message authentication, reporting and conformance) policy kapag parehong pumasa ang mga ito. Magpadala ng test booking sa totoong address sa isang malaking provider, buksan ang message headers, at tiyaking ang authentication lines ay pass. Mas masama ang booking page na hindi makapagpadala kaysa sa walang booking page, dahil tahimik itong nabibigo.

Aling calendar backend ang talagang nagse-sync sa parehong direksyon

Dalawa ang direksyon ng sync, at magkahiwalay silang maaaring mag-fail. Ang read direction ay para sa availability: dapat makita ng app ang mga dati mo nang busy block, kung hindi ay magbibigay ito ng slot na may naka-iskedyul ka na. Ang write direction naman ay ang booking mismo: dapat lumitaw ang nakumpirmang event sa calendar na aktuwal mong ginagamit, hindi lamang sa loob ng booking tool.

Parehong sinusuportahan ng Google Calendar at Microsoft 365 ang dalawang direksyon, pero may isang kondisyon sa self-hosted install. Ikaw mismo ang gagawa ng OAuth (open authorization) client dahil wala sa source code ang client ID ng hosted product. Para sa Cal.com, ito ang GOOGLE_API_CREDENTIALS sa .env, na naglalaman ng JSON na dina-download mo mula sa Google Cloud console. Tumatanggap din ang DayOtter ng Google at Microsoft OAuth credentials sa parehong paraan.

Dalawang bagay ang karaniwang nagdudulot ng problema rito, at mahalagang malaman ang mga ito bago magsimula. Una, dapat eksaktong tumugma ang redirect URI na nirerehistro mo sa public URL mo, kasama ang scheme at anumang trailing path. Kung hindi, ihihinto ng Google ang connection gamit ang redirect_uri_mismatch sa consent screen. Ikalawa, ang Google project na nananatili sa Testing publishing status ay nagbibigay ng refresh token na nag-e-expire pagkalipas ng pitong araw. Gumagana ang sync sa buong linggo, pagkatapos ay humihinto, at ipinapakita ng app logs ang invalid_grant sa susunod na refresh. Ilipat ang consent screen sa In production, o tanggapin na mano-mano kang magre-reconnect tuwing Lunes.

Ang CalDAV (calendaring extensions to WebDAV) ang open option, pero mas limitado ang support nito. May CalDAV app ang Cal.com na nakamarkang beta pa rin at na-verify laban sa mga server kabilang ang Baikal, Radicale, Nextcloud at Kerio Connect. Gumagana ang Apple iCloud sa parehong app, pero kailangan nito ng app-specific password sa halip na Apple ID password. Inililista ng DayOtter ang Apple sa pamamagitan ng CalDAV, kasama ng Google at Microsoft 365.

Hindi sync ang ICS feed. Read-only ayon sa disenyo ang subscribed .ics URL, kaya maaari nitong i-block ang oras sa booking page mo pero hindi nito kailanman matatanggap ang booking. Kung ICS lang ang iniaalok ng isang tool para sa calendar mo, kalahati lamang ng kailangan mong setup ang mayroon ka at kakailanganin mo pa ring mano-manong mag-copy ng mga event.

Google Calendar lang ang sini-sync ng Easy!Appointments. Hindi talaga nagbabasa ng availability ang Rallly: nangongolekta ito ng mga boto sa isang set ng candidate dates. Ito ang tamang tool para sa “kailan maaaring magkita tayong anim” at maling tool para sa “mag-book ng 30 minuto sa akin.”

Public ang booking page, kaya TLS ang unang dapat ayusin

Karamihan sa mga sine-self-host ay pribado. Maaaring nasa likod ng VPN o SSO login ang wiki, board, dashboard, at iba pang serbisyo, kaya hindi kailangang makita ng open internet. Hindi ganito ang booking link. Kailangang ma-load ito ng sinumang padadalhan mo. Dahil dito, may tatlong konkretong pagbabago sa setup.

Kailangan mo ng domain name na may A record na nakaturo sa VPS bago ka mag-install ng anuman. Kailangan mo ng certificate sa unang araw pa lang, dahil minamarkahan ng mga browser bilang hindi secure ang plain HTTP form, at inilalagay ng client mo rito ang pangalan at email address niya. Kailangan mo ring itakda nang tama sa config ng app ang public URL nito, dahil ginagamit ang value na iyon sa mga link sa outgoing email at sa OAuth redirect URI. Itakda ang NEXT_PUBLIC_WEBAPP_URL sa Cal.com, DOMAIN sa Rallly, BASE_URL sa Easy!Appointments, o DAYOTTER_DOMAIN sa oras ng pag-install, at gamitin ang https:// address na talagang gagamitin mo.

Awtomatikong inaasikaso ng Rallly at DayOtter ang TLS. Kasama sa bundled stack ng Rallly ang Traefik, na nag-i-issue ng Let's Encrypt certificate gamit ang address sa ACME_EMAIL. Nagse-set up ang installer ng DayOtter ng Caddy na may automatic HTTPS. Hindi ito ginagawa ng Cal.com at Easy!Appointments, kaya maglagay ka ng nginx sa harap nito at ikaw mismo ang mag-issue ng certificate, gaya ng Let's Encrypt certificate sa nginx gamit ang Certbot. I-bind ang app container sa 127.0.0.1 para ang tanging daan papasok ay ang proxy na kontrolado mo. Kung nagpapatakbo na ang parehong machine ng self-hosted na alternatibo sa Trello para sa mga internal board, panatilihin itong nasa likod ng dati mong auth at booking host lamang ang bigyan ng public server block.

Cal.com sa iyong VPS

Nasa sarili nitong repository ang Docker configuration, at prebuilt na sa Docker Hub ang mga image, kaya ipo-pull mo ang mga ito sa halip na i-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

Ilagay ang unang random value sa NEXTAUTH_SECRET at ang pangalawa sa CALENDSO_ENCRYPTION_KEY. Pareho itong required. Itakda ang DATABASE_URL at ituro ang NEXT_PUBLIC_WEBAPP_URL sa iyong public address. Ang bundled stack ay binubuo ng web app, PostgreSQL, at Prisma Studio. Nagbibigay ang documentation ng docker compose up -d calcom para patakbuhin lamang ang app gamit ang database na naka-host sa ibang lugar. Ito ang gamitin mo kapag tapos na ang initial installation.

I-pull ang image; huwag itong i-build sa VPS. Ayon sa sariling instructions ng project, kailangan mong i-export ang NODE_OPTIONS="--max-old-space-size=16384" kapag nagbu-build mula sa source. Katumbas ito ng 16 GB heap para sa Node lamang. Sa ARM hardware, idagdag ang -arm suffix sa image tag. Walang inilalathalang minimum requirement ang project para sa pagpapatakbo ng prebuilt image. Kaya ituring ang 2 GB para sa app at PostgreSQL bilang working figure lamang, hindi bilang documented requirement. I-monitor ang memory sa unang linggo.

Tiyaking gumagana na ito:

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

Dapat mag-print ang curl ng HTTP/2 200. Ang 502 Bad Gateway mula sa nginx habang nakikitang running ang container ay karaniwang nangangahulugang ipinapatupad pa ng first boot ang database migrations. Maghintay ng ilang minuto at basahin ang logs bago mong ipagpalagay na may sira. Nagti-trigger ang webhooks ng Cal.com sa bawat confirmed booking, kaya maaaring magpatakbo ang isang booking ng automation na ginagamit mo na, halimbawa isang n8n instance na naaabot sa HTTPS sa iyong VPS.

AGPLv3 ang core, ngunit may ilang feature sa isang enterprise directory na saklaw ng hiwalay na commercial licence. Basahin ang licence na iyon bago ka bumuo ng paid business process gamit ang team features.

Easy!Appointments sa isang 1 GB na server

Ang mga kailangan ay Apache o Nginx, PHP 8.2 o mas bago, at MySQL. May official image sa alextselegidis/easyappointments.

Isang babala muna. Ang docker-compose.yml sa repository ay isang development environment. Inaasahan nitong magbukas ka ng shell sa container at patakbuhin ang npm install && composer install && npm start. Hindi ito para sa deployment. Gamitin ang published image sa halip:

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

Ang BASE_URL ay dapat ang public HTTPS address. Kapag mali ito, ang mga booking link sa loob ng confirmation email ay tuturo sa host na hindi maabot ng client mo. Nagseserve ang image ng plain HTTP sa port 80 at wala itong sariling certificate. Kaya naka-bind ang port sa 127.0.0.1 at si nginx ang nagte-terminate ng TLS sa harap nito. Kung bago sa iyo ang compose syntax, magsimula sa Mga pangunahing kaalaman sa Docker Compose sa isang VPS at bumalik dito.

Ito ang pinakamagaan na option dito. Kumportableng tumatakbo sa isang 1 GB VPS ang dalawang container—isang PHP application at MySQL. Kapalit nito ang limitadong compatibility: Google Calendar lang ang calendar backend, at traditional admin panel ang interface sa halip na modernong booking flow. Kung Microsoft 365, Fastmail, o Nextcloud ang calendar mo, hindi ito angkop mula pa lang sa simula.

Rallly para sa group polls

Ibang tanong ang sinasagot ng Rallly. Hindi nito inilalathala ang availability mo. Nagpapakita ito ng mga kandidatong oras sa isang grupo at kumokolekta ng mga boto. Ito ang kailangan mo para sa isang board meeting, pero hindi ito angkop para sa client booking link.

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

Basahin muna ang anumang script bago ito i-pipe sa isang shell. Palitan ang bash ng less, basahin kung ano ang ginagawa nito, saka ito patakbuhin. Pareho ang ginagawa ng manual path, pero hinahati ito sa mga hakbang na makikita mo:

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

Ang documented requirements ay hindi bababa sa 2 GB ng RAM, Docker 19.03 o mas bago na may Compose v2, mga port 80 at 443 na available, at isang domain na nakaturo sa server. Kasama sa bundled stack ang Traefik para sa HTTPS, ang web application, PostgreSQL, at Garage para sa S3-compatible object storage. Itakda ang DOMAIN, isang SECRET_PASSWORD na may hindi bababa sa 32 character, SUPPORT_EMAIL, at INITIAL_ADMIN_EMAIL. Kung gumagamit ka na ng reverse proxy, itakda ang PROXY_MODE=external at WEB_PORT, at hindi hahadlang ang Traefik. Kung gumagamit ka na ng self-hosted na S3-compatible object store gamit ang MinIO, ituro rito ang mga S3_* variable at alisin ang Garage container.

Hindi optional ang SMTP dito dahil magic link ang ginagamit sa sign-in. Kung walang gumaganang relay, walang makakapag-log in, kabilang ang admin account na kakagawa mo lang. Ito ang mas ligtas na uri ng problema sa email: pinipigilan ka nitong makapasok sa simula, sa halip na mawala ang booking ng client pagkalipas ng 3 linggo.

DayOtter, ang pinakabagong pumasok

Ang DayOtter ay isang AGPLv3 scheduling platform na may kasamang assistant. Isang command lang ang kailangan para sa production install:

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

Basahin muna ito bago patakbuhin, gaya ng nasa itaas. Nagtatayo ang installer ng Docker, gumagawa ng secrets, at pinapagana ang buong stack: ang Next.js web app, isang background worker na humahawak ng reminders, calendar sync, at webhooks, PostgreSQL, Redis, at Caddy na may automatic HTTPS.

Pinakamalawak ang calendar support nito sa apat. Sinusuportahan nito ang Google, Microsoft 365, Apple sa pamamagitan ng CalDAV, at ICS feeds, kasama ang caveat sa ICS na nabanggit sa itaas. Kailangang opt-in sa pamamagitan ng environment variables ang lahat ng iba pang integration, kabilang ang SMTP o Resend para sa mail, ANTHROPIC_API_KEY para sa assistant, Twilio para sa SMS, at Stripe para sa payments. Confirm-first ang assistant: nagmumungkahi ito, ikaw ang nag-aapruba, at walang ipinapasok sa iyong calendar nang walang tahasang yes. Kapag iniwang walang laman ang API key, hindi tatakbo ang bahaging iyon ng product.

Malinaw ang licensing para sa self-hosters. AGPLv3 ang core, at may ee/ directory na naglalaman ng commercial cloud-only licence na nananatiling hindi aktibo maliban kung nakatakda ang DAYOTTER_CLOUD=1. Ibig sabihin, magagamit sa sarili mong server ang team features na sinisingil ng hosted plan ng $9 bawat seat bawat buwan, noong August 2026.

Ito rin ang pinakamabigat na stack dito at ang pinakabatang project. Patakbuhin ito kasabay ng dati mong booking link sa loob ng dalawang linggo, tumanggap ng aktuwal na bookings sa parehong system, at basahin ang worker logs bago ilipat ang iyong mga client.

Aktuwal na gastos sa bawat stack

Ang bilang ng container ang pinakatapat na batayan kung gaano karaming resource ang hihingin ng isang stack sa maliit na VPS, dahil may sariling minimum memory requirement ang bawat serbisyo. Ang mga bilang na ito ay mula sa mismong inilathalang Docker stack ng bawat proyekto, na sinuri noong Agosto 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"
  }
]

Kailangan ng Easy!Appointments ng 2 container at kasya ito sa 1 GB. Ang bundled stack ng Rallly ay 4, at nangangailangan ang dokumentasyon nito ng 2 GB. Nagbubukas ang installer ng DayOtter ng 5, kaya ito ang nangangailangan ng pinakamalaking server sa 4 na ito. Walang inilalathalang minimum memory figure ang Cal.com at DayOtter, kaya 2 GB ang panimulang itinatakda ko para sa dalawa, hindi bilang suportadong requirement.

Bababa ang dalawa sa mga bilang na ito kung mayroon ka nang tumatakbong infrastructure. Hindi na kailangan ang Traefik at Garage container ng Rallly kapag itinuro mo ito sa sarili mong proxy at object storage. Ang Prisma Studio ng Cal.com ay development tool na hindi dapat iwanang tumatakbo sa public server.

Aling self-hosted na alternatibo sa Calendly ang dapat mong piliin

Dapat gumamit ng Cal.com ang isang solo consultant. Ito lamang ang project dito na pinagsasama ang booking page na pamilyar sa mga tao, mga prebuilt image na hindi na nangangailangan ng Node build sa iyong VPS, at isang CalDAV path para sa mga hindi gumagamit ng calendar sa Google o Microsoft. Isang PostgreSQL database at isang application container lamang ito, kaya kayang-kaya itong i-maintain sa loob ng maraming taon. Maglaan ng isang hapon para sa OAuth client at mail relay. Tandaan na beta pa ang CalDAV app, kaya magsagawa muna ng isang aktuwal na booking mula simula hanggang dulo bago mo i-publish ang link.

Dapat tingnan ng isang maliit na team ang DayOtter. Kasama sa AGPLv3 core ang weighted round robin at collective booking. Sa self-hosting, makukuha mo ang mga feature na sinisingil ng hosted seat. Dinisenyo ang worker process para sa reminders at webhooks na aktuwal na ginagamit ng isang team. Ang kapalit nito ay maturity: ito ang pinakabagong project sa listahang ito. Patakbuhin muna ito nang kasabay ng kasalukuyang system at panatilihing aktibo ang lumang link hanggang sa mamonitor mo ang isang buong buwan ng bookings.

Dalawang mas partikular na sitwasyon. Kung kailangan mo lamang ng poll para makahanap ng oras na puwedeng magpulong ang grupo, i-install ang Rallly at doon na magtapos. Kung mayroon kang 1 GB VPS, Google Calendar ang ginagamit mo, at gusto mo ng pinakamaliit na application na tumatanggap ng booking, mas tatagal ang Easy!Appointments kaysa sa anumang mas komplikadong option na maaari mong ilagay sa server na iyon. Para sa mas malawak na tanong kung ano pa ang sulit i-self-host sa parehong server, tingnan ang ano ang sulit i-self-host sa 2026.

FAQ

Maaari ba akong magpatakbo ng self-hosted booking page nang walang domain name?

Hindi. Isinusulat ng bawat app na ito ang public URL nito sa mga link sa loob ng confirmation email. Tinutugma rin ng Google at Microsoft ang OAuth redirect URI sa parehong value. Kaya kapag bare IP address ang ginamit, makikita mo ang redirect_uri_mismatch sa consent screen. Hindi rin mag-iisyu ang Let's Encrypt ng certificate para sa IP address. Dahil dito, sa plain HTTP naglo-load ang page at mamarkahan ng browser na hindi secure ang form. Bilhin muna ang domain, ituro ang isang A record sa VPS, saka mag-install.

Bakit hindi kailanman dumarating ang booking confirmation email ko?

Halos palagi itong nangyayari dahil sinusubukan ng server na ito mismo ang mag-deliver ng mail. Hinaharangan ng karamihan sa mga VPS provider ang outbound port 25 sa mga bagong account. Dahil dito, nagha-hang ang connection. Kahit bukas ang port, walang sending reputation ang bagong address at tatanggihan ito ng malalaking mail receiver. Ituro ang app sa isang transactional mail relay sa port 587. Kumpirmahin na reachable ang port gamit ang nc -vz -w 5 "$SMTP_HOST" 587. Pagkatapos, i-publish ang SPF at DKIM record na ibinigay ng relay. Kung Cal.com ang ginagamit mo, tiyaking pinalitan mo ang shipped EMAIL_SERVER_HOST=localhost at EMAIL_SERVER_PORT=1025 defaults. Nakaturo ang mga ito sa local development mailbox.

Nagsi-sync ba ang self-hosted Cal.com sa CalDAV, o Google lang?

Pareho, pero magkaiba ang antas ng maturity. Beta ang marka ng CalDAV app. Na-verify ito sa mga server gaya ng Baikal, Radicale, Nextcloud, at Kerio Connect. Gumagana rin dito ang Apple iCloud gamit ang app-specific password. Parehong nagsi-sync sa dalawang direksyon ang Google Calendar at Microsoft 365. Sa self-hosted install, kailangan mong gumawa ng sarili mong OAuth client at ibigay ito sa pamamagitan ng GOOGLE_API_CREDENTIALS, dahil wala sa source ang credentials ng hosted service.

Bakit humihinto ang Google Calendar sync ko pagkalipas ng isang linggo?

Dahil nasa Testing publishing status pa rin ang Google Cloud project. Nag-iisyu ang Google ng refresh token sa mga app na nasa status na ito, pero nag-e-expire ang mga token pagkalipas ng pitong araw. Kaya gumagana muna ang connection, pagkatapos ay humihinto sa susunod na token refresh. Ipinapakita ng application log ang invalid_grant. Ilipat ang OAuth consent screen sa In production at isang beses na muling ikonekta ang calendar. Kapag nag-reconnect ka nang hindi binabago ang status, makakakuha ka lamang ng panibagong pitong araw.

Alin sa mga ito ang tatakbo sa 1 GB VPS?

Madali! Tatakbo ang Easy!Appointments dahil PHP application ito na gumagamit ng MySQL. Nagdodokumento ang Rallly ng minimum na 2 GB, at apat na service ang pinapatakbo ng bundled stack nito. Walang inilalabas na minimum requirement ang Cal.com at DayOtter. Gayunman, ang Next.js application na may PostgreSQL, at sa kaso ng DayOtter ay mayroon ding Redis at worker process, ay nangangahulugang dapat kang maglaan ng 2 GB o higit pa. Huwag kailanman mag-build ng Cal.com mula sa source sa maliit na server. Nangangailangan ang sariling build instructions ng project ng 16 GB Node heap. Sa halip, gamitin ang prebuilt image.