Alternatif Calendly Terbaik Untuk Dihoskan Sendiri

Jawapan ringkas

Alternatif Calendly yang dihoskan sendiri perlu melakukan satu perkara yang tidak pernah dilakukan oleh alat dalaman pada VPS anda: menjawab kepada orang awam. Halaman tempahan adalah produk tersebut. Ia memerlukan nama domain sebenar dan TLS (transport layer security) sejak hari pertama, dan ia perlu menghantar e-mel kepada orang yang tidak pernah mendengar tentang pelayan anda.

Empat projek merangkumi bidang yang realistik. Cal.com adalah padanan paling hampir dengan Calendly dan pilihan utama bagi perunding solo. Mudah! Easy!Appointments adalah pilihan yang ringan, menggunakan PHP dan MySQL, serta berfungsi dengan baik pada VPS 1 GB. Rallly ialah alat tinjauan kumpulan dan tidak mempunyai halaman tempahan langsung. DayOtter ialah peserta terbaharu, platform penjadualan AGPLv3 dengan pembantu pengesahan-dahulu di hadapannya.

Dua soalan menentukan yang mana satu yang boleh anda jalankan. Adakah ia menyegerak dua hala dengan kalendar yang anda gunakan sekarang? Dan bolehkah ia menghantar e-mel? Soalan kedua adalah tempat di mana kebanyakan persediaan tempahan yang dihoskan sendiri gagal secara senyap, jadi ia perlu diutamakan.

E-mel keluar adalah bahagian yang gagal

Pengesahan tempahan dihantar ke peti masuk orang asing. Itu adalah e-mel transaksi yang sampai ke Gmail atau Microsoft 365, dan penerima tersebut menilai anda berdasarkan alamat IP penghantar serta rekod DNS anda.

Menghantar terus dari VPS hampir tidak pernah berjaya. Kebanyakan penyedia menyekat port TCP 25 keluar pada akaun baharu, jadi sambungan tergantung dan kemudian tamat tempoh. Walaupun port 25 dibuka, alamat VPS yang baharu tiada sejarah penghantaran, dan penerima besar menganggap alamat julat pengehosan yang tidak dikenali sebagai mencurigakan. Tempahan ditulis ke dalam pangkalan data, halaman menyatakan ia disahkan, dan tiada sesiapa menerima e-mel. Tiada apa-apa yang kelihatan rosak dari sisi pelayan, itulah sebabnya perkara ini biasanya ditemui beberapa minggu kemudian oleh pelanggan yang tidak pernah muncul.

Gunakan relay. Mana-mana penyedia e-mel transaksi boleh digunakan, dan aplikasi hanya memerlukan nama hos, port, pengguna dan kata laluan. Pastikan port boleh dicapai sebelum anda menyentuh konfigurasi aplikasi:

nc -vz -w 5 "$SMTP_HOST" 587

Baris succeeded bermaksud laluan terbuka. Sambungan tergantung atau Connection refused bermaksud port disekat pada peringkat rangkaian, dan menyunting .env tidak akan membaiki perkara itu. Relay mendengar pada 587 atau 465 tepat kerana 25 sering disekat.

Setiap projek mengambil relay dengan caranya sendiri. Cal.com membaca EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER dan EMAIL_SERVER_PASSWORD, dan juga menerima RESEND_API_KEY sebagai ganti. Berhati-hati dengan perkara itu: .env.example yang disertakan menghalakan EMAIL_SERVER_HOST ke localhost pada port 1025, iaitu peti mel pembangunan tempatan. Biarkan lalai di tempatnya dan aplikasi akan menghantar ke tempat kosong tanpa ralat. Rallly mengambil SMTP_HOST, SMTP_PORT, SMTP_USER dan SMTP_PWD. DayOtter mengambil tetapan SMTP atau kunci Resend. Easy!Appointments menghantar pemberitahuannya daripada aplikasi, jadi halakan ia ke relay yang sama daripada halaman tetapannya sebelum anda menerima tempahan sebenar.

Kemudian terbitkan rekod DNS yang diberikan oleh relay anda. Rekod SPF (sender policy framework) menyatakan pelayan mana yang boleh menghantar bagi pihak domain anda, dan kunci DKIM (domainkeys identified mail) menandatangani setiap mesej supaya penerima boleh membuktikan ia tidak diubah. Tambahkan polisi DMARC (domain-based message authentication, reporting and conformance) sebaik sahaja kedua-duanya lulus. Hantar tempahan ujian ke alamat sebenar di penyedia besar, buka pengepala mesej, dan sahkan baris pengesahan membaca pass. Halaman tempahan yang tidak boleh menghantar adalah lebih buruk daripada tiada halaman tempahan, kerana ia gagal secara senyap.

Backend kalendar yang manakah benar-benar menyegerak dua hala

Penyegerakan mempunyai dua arah dan kedua-duanya boleh gagal secara berasingan. Arah bacaan ialah ketersediaan: aplikasi mesti melihat blok masa sibuk anda yang sedia ada, jika tidak, ia akan memberikan slot masa yang anda sebenarnya sudah sibuk. Arah penulisan ialah tempahan itu sendiri: acara yang disahkan perlu muncul pada kalendar yang anda lihat, bukan sekadar di dalam alat tempahan tersebut.

Google Calendar dan Microsoft 365 melakukan kedua-dua arah, dengan satu syarat untuk pemasangan yang dihoskan sendiri (self-hosted). Anda perlu mencipta klien OAuth (open authorization) sendiri, kerana ID klien produk yang dihoskan tidak disertakan dalam kod sumber. Bagi Cal.com, ini adalah GOOGLE_API_CREDENTIALS dalam .env, yang menyimpan JSON yang anda muat turun daripada konsol Google Cloud. DayOtter menerima kelayakan OAuth Google dan Microsoft dengan cara yang sama.

Dua perkara sering gagal di sini, dan kedua-duanya perlu diketahui sebelum anda bermula. Pertama, URI ubah hala (redirect URI) yang anda daftarkan mestilah sepadan dengan URL awam anda dengan tepat, termasuk skema dan sebarang path di hujung, atau Google akan menghentikan sambungan dengan redirect_uri_mismatch pada skrin persetujuan. Kedua, projek Google yang dibiarkan dalam status penerbitan Testing akan mengeluarkan token penyegaran (refresh tokens) yang tamat tempoh selepas tujuh hari. Penyegerakan berfungsi sepanjang minggu dan kemudian terhenti, dan log aplikasi akan menunjukkan invalid_grant pada penyegaran seterusnya. Tukar skrin persetujuan kepada In production, atau terima hakikat perlu menyambung semula secara manual setiap hari Isnin.

CalDAV (sambungan kalendar kepada WebDAV) ialah pilihan terbuka, dan sokongannya lebih terhad. Cal.com menyediakan aplikasi CalDAV yang masih ditandakan sebagai beta, disahkan terhadap pelayan termasuk Baikal, Radicale, Nextcloud dan Kerio Connect. Apple iCloud berfungsi melalui aplikasi yang sama tetapi memerlukan kata laluan khusus aplikasi (app-specific password) dan bukannya kata laluan Apple ID anda. DayOtter menyenaraikan Apple melalui CalDAV di sebelah Google dan Microsoft 365.

Suapan ICS bukanlah penyegerakan. URL .ics yang dilanggan adalah baca-sahaja (read-only) mengikut reka bentuknya, jadi ia boleh menyekat masa pada halaman tempahan anda tetapi tidak akan menerima tempahan. Jika sesuatu alat hanya menawarkan ICS untuk kalendar anda, anda hanya mempunyai separuh daripada sistem dan anda masih perlu menyalin acara secara manual.

Easy!Appointments hanya menyegerakkan Google Calendar dan tiada yang lain. Rallly tidak membaca ketersediaan langsung: ia mengumpul undian pada set tarikh calon. Itu adalah alat yang tepat untuk "bilakah kami berenam boleh berjumpa" dan alat yang salah untuk "tempah 30 minit dengan saya".

Halaman tempahan bersifat awam, jadi TLS adalah keutamaan

Kebanyakan perisian yang dihoskan sendiri bersifat peribadi. Wiki, papan perbincangan, atau papan pemuka boleh diletakkan di sebalik VPN atau log masuk SSO tanpa perlu didedahkan kepada internet terbuka. Pautan tempahan tidak boleh berbuat demikian. Sesiapa sahaja yang menerima pautan tersebut perlu memuatkannya, dan ini mengubah persediaan anda dalam tiga cara yang nyata.

Anda memerlukan nama domain dengan rekod A yang dihalakan ke VPS sebelum memasang apa-apa. Anda memerlukan sijil pada hari pertama kerana pelayar akan melabelkan borang HTTP biasa sebagai tidak selamat, sedangkan pelanggan anda memasukkan nama dan e-mel mereka ke dalamnya. Anda juga perlu menetapkan URL awam aplikasi dengan betul dalam konfigurasinya, kerana nilai tersebut akan disematkan ke dalam pautan e-mel keluar dan URI ubah hala OAuth. Tetapkan NEXT_PUBLIC_WEBAPP_URL dalam Cal.com, DOMAIN dalam Rallly, BASE_URL dalam Easy!Appointments, atau DAYOTTER_DOMAIN semasa pemasangan, dan tetapkan kepada alamat https:// yang akan anda gunakan.

Rallly dan DayOtter menyelesaikan isu TLS untuk anda. Stak yang disertakan dalam Rallly merangkumi Traefik dan mengeluarkan sijil Let's Encrypt menggunakan alamat dalam ACME_EMAIL. Pemasang DayOtter menyediakan Caddy dengan HTTPS automatik. Cal.com dan Easy!Appointments tidak menyediakannya, jadi anda perlu meletakkan nginx di hadapan dan mengeluarkan sijil sendiri, sama seperti cara anda mendapatkan sijil Let's Encrypt pada nginx dengan Certbot. Ikat kontena aplikasi ke 127.0.0.1 supaya satu-satunya laluan masuk adalah melalui proksi yang anda kawal. Jika pelayan yang sama sudah menjalankan alternatif Trello yang dihoskan sendiri untuk papan dalaman anda, kekalkan ia di sebalik pengesahan sedia ada dan berikan blok pelayan awam hanya kepada hos tempahan.

Cal.com pada VPS anda

Konfigurasi Docker disimpan dalam repositori tersendiri, dan imej telah dibina lebih awal di Docker Hub, jadi anda hanya perlu menarik (pull) imej tersebut dan bukannya membina sendiri.

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

Nilai rawak pertama dimasukkan ke dalam NEXTAUTH_SECRET dan nilai kedua ke dalam CALENDSO_ENCRYPTION_KEY. Kedua-duanya diperlukan. Tetapkan DATABASE_URL dan halakan NEXT_PUBLIC_WEBAPP_URL ke alamat awam anda. Stak yang disertakan terdiri daripada aplikasi web, PostgreSQL dan Prisma Studio; dokumentasi memberikan docker compose up -d calcom untuk menjalankan aplikasi secara berasingan dengan pangkalan data yang anda hoskan di tempat lain, iaitu kaedah yang disyorkan setelah pemasangan selesai.

Tarik imej tersebut, jangan binanya pada VPS. Arahan projek itu sendiri meminta anda mengeksport NODE_OPTIONS="--max-old-space-size=16384" apabila membina daripada sumber, yang memerlukan 16 GB heap untuk Node sahaja. Pada perkakasan ARM, tambahkan sufiks -arm pada tag imej. Projek ini tidak menerbitkan keperluan minimum untuk menjalankan imej yang telah dibina, jadi anggap 2 GB untuk aplikasi berserta PostgreSQL sebagai angka anggaran saya dan bukannya angka rasmi, serta pantau penggunaan memori sepanjang minggu pertama.

Semak sama ada ia telah berjalan:

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

Arahan curl sepatutnya memaparkan HTTP/2 200. Ralat 502 Bad Gateway daripada nginx semasa kontena menunjukkan status berjalan biasanya bermaksud but pertama masih dalam proses melakukan migrasi pangkalan data. Berikan masa beberapa minit dan baca log sebelum anda membuat kesimpulan bahawa ia rosak. Webhook Cal.com akan dicetuskan pada setiap tempahan yang disahkan, jadi tempahan tersebut boleh menggerakkan sebarang automasi yang anda jalankan, contohnya instans n8n yang boleh dicapai melalui HTTPS pada VPS anda.

Terasnya adalah AGPLv3, dengan beberapa ciri disimpan dalam direktori perusahaan di bawah lesen komersial yang berasingan. Baca lesen tersebut sebelum anda membina proses perniagaan berbayar menggunakan ciri-ciri pasukan tersebut.

Easy!Appointments pada pelayan 1 GB

Keperluan sistem ialah Apache atau Nginx, PHP 8.2 atau lebih baharu, dan MySQL. Terdapat imej rasmi di alextselegidis/easyappointments.

Satu amaran awal. docker-compose.yml dalam repositori tersebut adalah persekitaran pembangunan. Ia menjangkakan anda membuka shell dalam kontena dan menjalankan npm install && composer install && npm start. Ia bukan untuk tujuan deployment. Gunakan imej yang diterbitkan sebaliknya:

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 mestilah alamat HTTPS awam. Jika salah, pautan tempahan di dalam e-mel pengesahan akan menghala ke hos yang tidak boleh dicapai oleh pelanggan anda. Imej ini menyediakan HTTP biasa pada port 80 tanpa sijilnya sendiri, itulah sebabnya port tersebut diikat pada 127.0.0.1 dan nginx melakukan TLS termination di hadapan. Jika sintaks compose baharu bagi anda, mulakan dengan Asas Docker Compose pada VPS dan kembali semula ke sini.

Ini adalah pilihan paling ringan di sini dengan perbezaan yang ketara. Dua kontena, aplikasi PHP dan MySQL, boleh berjalan dengan selesa pada VPS 1 GB. Kosnya adalah dari segi capaian: Google Calendar ialah satu-satunya backend kalendar, dan antara mukanya adalah panel admin tradisional dan bukannya aliran tempahan moden. Jika kalendar anda ialah Microsoft 365, Fastmail atau Nextcloud, pilihan ini tidak sesuai sejak dari awal lagi.

Rallly untuk tinjauan kumpulan

Rallly menjawab soalan yang berbeza. Ia tidak menerbitkan ketersediaan anda. Ia meletakkan satu set cadangan masa di hadapan kumpulan dan mengumpul undian, iaitu perkara yang anda perlukan untuk mesyuarat lembaga pengarah dan tidak berguna untuk pautan tempahan pelanggan.

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

Baca sebarang skrip sebelum anda menyalurkannya (pipe) ke dalam shell. Tukar bash kepada less, baca perkara yang dilakukannya, kemudian jalankan. Laluan manual melakukan kerja yang sama dalam langkah-langkah yang boleh anda lihat:

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

Keperluan yang didokumenkan adalah sekurang-kurangnya 2 GB RAM, Docker 19.03 atau lebih baharu dengan Compose v2, port 80 dan 443 yang bebas, serta domain yang dihalakan ke pelayan. Tindanan (stack) yang disertakan ialah Traefik untuk HTTPS, aplikasi web, PostgreSQL, dan Garage untuk storan objek yang serasi dengan S3. Tetapkan DOMAIN, satu SECRET_PASSWORD yang sekurang-kurangnya 32 aksara, SUPPORT_EMAIL dan INITIAL_ADMIN_EMAIL. Jika anda sudah menjalankan reverse proxy, tetapkan PROXY_MODE=external dan WEB_PORT, dan Traefik tidak akan mengganggu. Jika anda sudah menjalankan storan objek serasi S3 yang dihoskan sendiri dengan MinIO, halakan pemboleh ubah S3_* kepadanya dan gugurkan kontena Garage.

SMTP tidak bersifat pilihan di sini, kerana log masuk menggunakan pautan magis (magic link). Tanpa relay yang berfungsi, tiada sesiapa boleh log masuk, termasuk akaun pentadbir yang baru anda cipta. Itu adalah versi kegagalan e-mel yang baik: ia menghalang anda di pintu masuk dan bukannya menyebabkan tempahan pelanggan hilang tiga minggu kemudian.

DayOtter, pendatang baharu

DayOtter ialah platform penjadualan berlesen AGPLv3 yang dilengkapi dengan pembantu. Pemasangan pengeluaran hanya memerlukan satu arahan:

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

Baca arahan tersebut sebelum anda menjalankannya, seperti yang dinyatakan di atas. Pemasang ini menyediakan Docker, menjana rahsia, dan menghidupkan keseluruhan tindanan (stack): aplikasi web Next.js, pekerja latar belakang yang mengendalikan peringatan, penyelarasan kalendar dan webhook, PostgreSQL, Redis, serta Caddy dengan HTTPS automatik.

Sokongan kalendar adalah yang paling meluas antara keempat-empat pilihan. Ia menyokong Google, Microsoft 365, Apple melalui CalDAV, dan suapan ICS, dengan mengambil kira peringatan ICS di atas. Setiap integrasi lain adalah pilihan melalui pemboleh ubah persekitaran, termasuk SMTP atau Resend untuk e-mel, ANTHROPIC_API_KEY untuk pembantu, Twilio untuk SMS, dan Stripe untuk pembayaran. Pembantu ini menggunakan pendekatan pengesahan dahulu: ia mencadangkan, anda meluluskan, dan tiada apa-apa yang sampai ke kalendar anda tanpa persetujuan jelas. Biarkan kunci API kosong dan bahagian produk tersebut tidak akan berjalan.

Pelesenan adalah jelas untuk pengguna yang melakukan pengehosan sendiri. Terasnya adalah AGPLv3, dan direktori ee/ mengandungi lesen komersial khusus awan yang kekal tidak aktif melainkan DAYOTTER_CLOUD=1 ditetapkan. Ini bermakna ciri pasukan yang dikenakan bayaran $9 bagi setiap tempat setiap bulan dalam pelan terhos, setakat Ogos 2026, tersedia di pelayan anda sendiri.

Ini juga merupakan tindanan paling berat dalam senarai ini dan projek yang paling baharu. Jalankan ia di samping pautan tempahan sedia ada anda selama dua minggu, terima tempahan sebenar melalui kedua-duanya, dan baca log pekerja sebelum anda memindahkan pelanggan anda.

Kos sebenar setiap stack

Bilangan kontena merupakan proksi yang tepat untuk menentukan beban sesuatu stack terhadap VPS kecil, kerana setiap servis mempunyai penggunaan memori minimumnya sendiri. Berikut adalah bilangan kontena daripada stack Docker rasmi setiap projek, yang disemak pada Ogos 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 memerlukan 2 kontena dan boleh dimuatkan dalam 1 GB. Stack yang dibundelkan untuk Rallly ialah 4, dan dokumentasinya memerlukan 2 GB. Pemasang DayOtter menjalankan 5 kontena, sebab itulah ia memerlukan pelayan yang paling besar daripada 4 pilihan di sini. Cal.com dan DayOtter tidak menerbitkan sebarang angka memori minimum, jadi 2 GB adalah titik permulaan saya untuk kedua-duanya dan bukannya angka yang disokong secara rasmi.

Dua daripada jumlah ini akan berkurangan jika anda sudah menjalankan infrastruktur sedia ada. Kontena Traefik dan Garage untuk Rallly boleh dibuang apabila anda menghalakannya ke proksi dan storan objek milik anda sendiri. Prisma Studio untuk Cal.com ialah alat pembangunan yang tidak sepatutnya dibiarkan berjalan pada pelayan awam.

Alternatif Calendly yang manakah patut anda pilih untuk self-hosted

Perunding solo patut menjalankan Cal.com. Ia merupakan satu-satunya projek di sini yang menggabungkan halaman tempahan yang dikenali ramai, imej prabina yang menjimatkan VPS anda daripada proses binaan Node, serta laluan CalDAV bagi mereka yang tidak menggunakan kalendar Google atau Microsoft. Satu pangkalan data PostgreSQL dan satu bekas aplikasi merupakan beban penyelenggaraan yang boleh anda tanggung selama bertahun-tahun. Peruntukkan satu petang untuk menyediakan klien OAuth dan geganti mel (mail relay), dan ambil perhatian bahawa aplikasi CalDAV masih dalam peringkat beta, jadi uji satu tempahan sebenar dari awal hingga akhir sebelum anda menerbitkan pautan tersebut.

Pasukan kecil patut melihat DayOtter. Weighted round robin dan tempahan kolektif terletak dalam teras AGPLv3, jadi self-hosting memberikan anda ciri-ciri yang biasanya dikenakan bayaran pada perkhidmatan berhos, dan proses pekerja (worker process) dibina untuk peringatan serta webhook yang benar-benar digunakan oleh sesebuah pasukan. Pertukarannya adalah dari segi kematangan: ia merupakan projek terbaharu dalam senarai ini, jadi jalankan ia secara selari terlebih dahulu dan kekalkan pautan lama sehingga anda telah memantau tempahan selama sebulan penuh.

Dua kes yang lebih khusus. Jika anda hanya memerlukan tinjauan untuk mencari masa yang sesuai bagi kumpulan bermesyuarat, pasang Rallly dan cukup setakat itu. Jika anda mempunyai VPS 1 GB, anda menggunakan Google Calendar, dan anda mahukan aplikasi paling ringan yang boleh menerima tempahan, Easy!Appointments akan bertahan lebih lama daripada mana-mana pilihan lebih canggih yang boleh anda letakkan pada pelayan tersebut. Untuk soalan lebih luas tentang apa lagi yang berbaloi untuk diletakkan pada pelayan yang sama, lihat apa yang berbaloi untuk di-self-host pada tahun 2026.

FAQ

Bolehkah saya menjalankan halaman tempahan yang dihoskan sendiri tanpa nama domain?

Tidak. Setiap aplikasi ini menulis URL awamnya ke dalam pautan di dalam e-mel pengesahan, dan Google serta Microsoft kedua-duanya memadankan URI ubah hala OAuth dengan nilai yang sama, jadi alamat IP kosong akan memberikan anda redirect_uri_mismatch pada skrin persetujuan. Let's Encrypt juga tidak akan mengeluarkan sijil untuk alamat IP, jadi halaman akan dimuatkan melalui HTTP biasa dan pelayar akan menandakan borang tersebut sebagai tidak selamat. Beli domain dahulu, halakan rekod A ke VPS, kemudian pasang.

Mengapa e-mel pengesahan tempahan saya tidak pernah sampai?

Hampir selalu kerana pelayan cuba menghantar mel itu sendiri. Kebanyakan penyedia VPS menyekat port 25 keluar pada akaun baharu, jadi sambungan tergantung, dan walaupun ia dibuka, alamat baharu tidak mempunyai reputasi penghantaran dan penerima besar akan menolaknya. Halakan aplikasi ke relay mel transaksi pada port 587, sahkan port boleh dicapai dengan nc -vz -w 5 "$SMTP_HOST" 587, kemudian terbitkan rekod SPF dan DKIM yang diberikan oleh relay tersebut kepada anda. Jika anda menjalankan Cal.com, pastikan anda menggantikan lalai EMAIL_SERVER_HOST=localhost dan EMAIL_SERVER_PORT=1025 yang dibekalkan, yang menghala ke peti mel pembangunan tempatan.

Adakah Cal.com yang dihoskan sendiri diselaraskan dengan CalDAV, atau hanya Google?

Kedua-duanya, dengan tahap kematangan yang berbeza. Aplikasi CalDAV ditandakan sebagai beta dan disahkan terhadap pelayan termasuk Baikal, Radicale, Nextcloud dan Kerio Connect, dan Apple iCloud berfungsi melaluinya menggunakan kata laluan khusus aplikasi. Google Calendar dan Microsoft 365 kedua-duanya diselaraskan dalam setiap arah, tetapi pada pemasangan yang dihoskan sendiri, anda mesti mencipta klien OAuth anda sendiri dan membekalkannya melalui GOOGLE_API_CREDENTIALS, kerana kelayakan perkhidmatan yang dihoskan tidak terdapat dalam sumber.

Mengapa penyelarasan Google Calendar saya berhenti berfungsi selepas seminggu?

Kerana projek Google Cloud masih dalam status penerbitan Testing. Google mengeluarkan token segar semula kepada aplikasi dalam keadaan itu yang tamat tempoh selepas tujuh hari, jadi sambungan berfungsi, kemudian mati pada segar semula token seterusnya, dan log aplikasi menunjukkan invalid_grant. Alihkan skrin persetujuan OAuth kepada In production dan sambungkan semula kalendar sekali. Menyambung semula tanpa menukar status hanya memberikan anda tujuh hari lagi dan tidak lebih daripada itu.

Yang manakah antara ini akan berjalan pada VPS 1 GB?

Easy!Appointments boleh, kerana ia adalah aplikasi PHP ditambah MySQL. Rallly mendokumenkan minimum 2 GB dan tindanan yang dibundel menjalankan empat servis. Cal.com dan DayOtter tidak menerbitkan minimum, tetapi aplikasi Next.js dengan PostgreSQL, dan dalam kes DayOtter, Redis serta proses pekerja juga, bermakna anda harus merancang untuk 2 GB atau lebih. Jangan sekali-kali membina Cal.com daripada sumber pada kotak kecil: arahan binaan projek itu sendiri meminta heap Node 16 GB, jadi tarik imej yang telah dibina terlebih dahulu.