How to Self-Host Cal.com
Cal.com is the scheduling product this listing started from. The GitHub repository at calcom/cal.com now resolves to Cal.diy, the community MIT edition for booking pages, availability rules, and calendar connections on infrastructure you run. The notes below were checked against that repository.
When Cal.com is a good fit
Choose this stack when you want a self-hosted booking page and you have accepted the upstream warning on Cal.diy: it is aimed at personal use, and the maintainers point commercial or enterprise scheduling at hosted Cal.com or their on-prem offering. You own PostgreSQL, the application secrets, email delivery, and any calendar OAuth apps you create.
Deployment notes
The repository documents Docker Compose. The image is calcom/cal.diy, and the compose stack can start a local Postgres alongside the app. Copy .env.example to .env and replace the placeholder secrets before the first start. The README requires generated values for NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY, plus a real DATABASE_URL. PostgreSQL 13 or newer is the documented database. ARM hosts need the image tag suffix the README describes.
The first launch opens a setup wizard on port 3000, or on NEXT_PUBLIC_WEBAPP_URL if you set one. Put that URL behind HTTPS before anyone but you can reach it.
Data and recovery
Back up the Postgres database and the .env file together. Bookings and users live in the database. The encryption key is what makes stored integration secrets readable after a restore. Calendar connections also depend on OAuth credentials you created at Google, Microsoft, or another provider; keep those in the same recovery notes.
Write down the restore sequence, required secrets, exposed ports, and the public web app URL. A scheduled backup is not complete until a clean host can restore it and pass a functional check.
Important limitation
Cal.diy is not the commercial Cal.com product. Upstream marks the community edition for personal, non-production use. Read that warning in the repository before you put a team on it.
Production checklist
- Pin and record the deployed version.
- Persist every documented data and configuration path.
- Terminate TLS at a maintained reverse proxy or trusted tunnel.
- Restrict administrative interfaces and rotate default credentials.
- Monitor uptime, disk space, certificate expiry, and failed jobs.
- Test an off-host backup with a real restore.
