cal.diy：個人向けにCal.comの予約画面を自ホストする
cal.diy は、個人の非運用セルフホスティング向けに、Cal.com のスケジューリング インターフェイスとカレンダーの統合をパッケージ化します。
ひと目でわかる
- これは何？
- calcom/cal.diyはCal.comから企業向けコードを除いたMITの予約基盤です。READMEはpersonal、non-production用途に限定し、マネージド版は無いと書いています。
- 誰に向いている？
- 自分の予約ページをNodeとPostgreSQLで動かし、Cal.comアカウントやライセンスキー無しで画面を試したい個人に向きます。TeamsやSSO、Insightsが要る組織利用、可用性契約が要る本番予約には向きません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
READMEがpersonalとnon-productionに閉じる理由
Cal.diyのREADMEは冒頭で、自ホストするコミュニティ版であり、個人の非本番用途に限ると警告しています。サーバー管理、データベース、機微データの保護に慣れていないなら進まないでほしい、という書き方です。商用やエンタープライズの予約基盤が必要なら Cal.com 本体（https://cal.com/sales）を使え、と TIP が誘導します。ホスト型や管理型の Cal.diy は無く、動かす場所は自分のインフラだけです。
リポジトリ説明も、Cal.comのスケジューリング画面とカレンダー連携を個人の非本番セルフホスト向けにまとめたもの、としています。取得時点のリリースは v6.2.0、v6.1.16、v6.1.15 です。版番号が Cal.com 本家と並んで見えても、機能集合は同じではありません。Teams、Organizations、Insights、Workflows、SSO/SAML など EE 専用機能は削除済みです。
公式サイトは https://cal.diy です。サイトがあることと、運用を代行してくれることは別です。READMEは「自分で実行する」以外の提供形態を書いていません。予約の可用性、バックアップ、個人情報の漏えい対策は、導入した側の作業になります。
企業版コードを削ったMIT一本のフォーク
Cal.diyはCal.comのフォークで、企業向け・商用コードを除去したスケジュール基盤です。コードベース全体がMITで、オープンコアの分割は無い、ライセンスキーも Cal.com アカウントも不要、と README が列挙しています。貢献は CONTRIBUTING.md 経由でこのリポジトリへ入り、Cal.com 本番へ自動では流れません。
残るのは個人が予約枠を公開し、カレンダーと連携する部分です。複数組織の権限、SAML、分析ダッシュボードを期待して clone すると、削除済み機能を探して時間を溶かすことになります。機能の有無は Cal.com の記憶ではなく、このリポジトリの README とソースで確認する必要があります。
技術スタックは Next.js、tRPC、React、Tailwind CSS、Prisma、Daily.co です。ローカル要件は Node.js 18 以上、PostgreSQL 13 以上、推奨パッケージマネージャは Yarn。統合を有効にする場合は、各サービスの認証情報を別途取る必要があり、詳細は README の integrations 節へ委譲されています。素材の README は途中で切れているため、Google Calendar や Zoom の具体手順は、クローンしたリポジトリの当該節を直接読む必要があります。
NEXTAUTH_SECRETとCALENDSO_ENCRYPTION_KEYを先に置く
手動セットアップは git clone https://github.com/calcom/cal.diy.git、cd cal.diy、yarn、.env.example を .env へ複製、という順です。Windows では管理者権限の Git Bash で git clone -c core.symlinks=true を使う注記があります。秘密値は openssl rand -base64 32 を NEXTAUTH_SECRET、openssl rand -base64 24 を CALENDSO_ENCRYPTION_KEY へ入れます。既定のまま起動してはいけない、という趣旨です。
Windows では packages/prisma/.env がシンボリックリンクのままだと、Prisma が unexpected character / in variable name で落ちることがあります。対処は rm packages/prisma/.env && cp .env packages/prisma/.env です。ここを飛ばすと、ルートの .env は正しいのに migrate だけ失敗する、という切り分けになります。
Node 版が合わないときは nvm use、必要なら nvm install && nvm use です。開発時のメモリは export NODE_OPTIONS="--max-old-space-size=16384" を README が例示しています。ログの細かさは .env の NEXT_PUBLIC_LOGGER_LEVEL で、0 silly から 6 fatal まで。例として echo 'NEXT_PUBLIC_LOGGER_LEVEL=3' >> .env で info 以上だけ出します。
yarn dxが作るfree@example.comなどの試験ユーザー
最短起動は yarn dx です。Docker と Docker Compose が必要で、ローカル Postgres と試験ユーザーを立てます。資格情報はコンソールへ出ます。README の表では free@example.com / free（Free）、pro@example.com / pro（Pro）、trial@example.com / trial（Trial）、admin@example.com / ADMINadmin2022!（Admin）、onboarding@example.com / onboarding（オンボーディング未完了）です。サインイン先は http://localhost:3000 です。
シードの全体を見るなら yarn db-studio で http://localhost:5555 の Prisma Studio を開きます。これらのパスワードは開発用です。同じ値を公開インスタンスへ残す用途ではありません。yarn dx が成功しても、それは Docker 上の開発スタックが起きたという意味で、本番相当のバックアップやTLSは含まれていません。
E2E は既存稿が yarn test-e2e と Playwright に触れていましたが、取得した README 断片の末尾は Gitpod 手前で切れています。テストコマンドを採用根拠にするなら、クローンしたリポジトリの当該節を自分で開いて版と突き合わせてください。素材に無い成功率や所要時間はここには書きません。
Docker Hubのcalcom/cal.diyとDATABASE_URL
Docker イメージは Docker Hub の calcom/cal.diy として案内されています。README 断片は Compose でプリビルドを使う経路と、ソースからビルドする経路に触れ、スタックにローカル Postgres、Web アプリ、Prisma Studio を含められる、としています。実行時に必要な例は DATABASE_URL、NEXTAUTH_SECRET、CALENDSO_ENCRYPTION_KEY です。ビルド時には MAX_OLD_SPACE_SIZE や NEXT_PUBLIC_WEBAPP_URL が既存の整理に出てきます。値の意味は、クローンしたドキュメントの Docker 節で確認してください。
初回実行でセットアップウィザードが出て最初のユーザーを定義する、という説明も既存の整理にあります。yarn dx のシードユーザーと、ウィザードで作るユーザーを混同すると、どちらでログインしているか分からなくなります。開発用シードを消したつもりが Compose ボリュームに残っている、という事故が起きやすいです。
Prisma の migrate は開発で prisma db-migrate、本番相当で db-deploy と整理されていました。コマンド名はリポジトリの scripts と README を優先してください。migrate が通ることと、予約が外部カレンダーへ書き戻されることは別確認です。カレンダー統合の認証情報は integrations 節側です。
v6.2.0でもCal.com本番の代替にはならない
リリース v6.2.0 は 2026-03-01 付です。セルフホストできることと、Cal.com が売るエンタープライズ予約基盤を代替できることは、README が見事に分けています。EE 機能は削除済みで、サポート契約もホスト型もありません。自分の Postgres と秘密値とTLSを運用できる人向けです。
MIT なので改変や再配布の条項は緩い一方、予約データとカレンダーOAuthトークンは利用者の管理物です。README は機微データを守れ、と前置きしているだけで、暗号化キーのローテーション手順や監査ログの完成度までは書いていません。CALENDSO_ENCRYPTION_KEY を作り直すと既存データの復号に影響し得るため、試験用と長期用の .env を分けた方が安全です。
導入確認は次に限ると切り分けやすいです。yarn dx で http://localhost:3000 に admin@example.com が入れるか。手動経路なら NEXTAUTH_SECRET と CALENDSO_ENCRYPTION_KEY が入った .env でアプリが起動するか。Windows なら packages/prisma/.env が実ファイルか。カレンダー連携を試すなら、integrations 節のサービスを一つだけ選び、予約作成後に外部カレンダーへ予定が載るかを見る。ここを越えて社内の本番予約へ載せる判断は、README の適用範囲外です。
編集部の結論
自分の予約ページをNodeとPostgreSQLで動かし、Cal.comアカウントやライセンスキー無しで画面を試したい個人に向きます。TeamsやSSO、Insightsが要る組織利用、可用性契約が要る本番予約には向きません。先にyarn dxか.envのNEXTAUTH_SECRETとCALENDSO_ENCRYPTION_KEYを通し、http://localhost:3000でシードユーザーが入れることと、README先頭のpersonal、non-production警告を同じ版（例: v6.2.0）で読んでから広げてください。
コミュニティノート