calcom/cal.diy

Selection

Select when

• You want to self-host a personal scheduling and booking application.
• You require an MIT-licensed Cal.com-derived codebase without the stated enterprise layer.
• You can operate Node.js, PostgreSQL, secrets, OAuth credentials, networking, backups, and upgrades.
• You need inline, modal, or floating-button booking embeds.
• You want repository-local specs and machine-readable rules to guide Claude-assisted development.
• You are evaluating or developing integrations with documented calendar, conferencing, or CRM providers.
• You accept the project's explicit personal and non-production positioning.

Boundaries

Avoid when

• You need a vendor-managed scheduling service.
• You need production or enterprise readiness endorsed by this repository.
• You require teams, organizations, workflows, insights, SSO, SAML, or other removed enterprise features.
• You lack the expertise or capacity to secure and maintain a public web application and PostgreSQL database.
• You need a ready-made Claude Code plugin, skill, hook, MCP server, or scheduling tool surface.
• You need a simple low-resource installation with few external dependencies.
• You cannot safely manage OAuth secrets, encryption keys, user data, and third-party integration credentials.

Strengths

Capabilities

Risk profile

Risks and limitations

• Uncertainty: only selected first-party README files were supplied, so application code, CLAUDE.md files, AGENTS.md, rule bodies, manifests, tests, CI, authentication, authorization, encryption, telemetry, and integration implementations were not directly inspected.
• Uncertainty: repository update and push timestamps extend into 2026 relative to this analysis context, so current activity, release state, issue counts, and adoption cannot be independently reconciled.
• Uncertainty: the README calls the project a fork of Cal.com with all enterprise code removed, but the API v2 README still documents a placeholder license-key database setup, so the practical scope of license-key dependencies is unclear.
• Uncertainty: Claude-oriented behavior is documented in the spec workflow, but no Claude Code version, integration test, plugin manifest, skill, hook, MCP configuration, or installation path was supplied.
• The root warning strictly recommends personal, non-production use and directs commercial or enterprise users to Cal.com.
• Self-hosting requires advanced server administration, PostgreSQL management, application security, secret rotation, backups, monitoring, networking, and upgrades.
• The documented default Docker environment contains placeholder database credentials and secret values that must be replaced before exposed deployment.
• Strict CSP is enforced only on the login page, is report-only on other SSR pages, and is not supported on SSG pages according to the README.
• A troubleshooting option disables TLS certificate verification and is explicitly suitable only for trusted termination setups.
• Google, Microsoft, Zoom, Daily, CRM, and other integrations rely on external providers, credentials, scopes, availability, pricing, and privacy terms.
• Anonymous usage telemetry appears enabled unless CALCOM_TELEMETRY_DISABLED is set to 1, but the supplied files do not define collected fields, destinations, retention, or defaults in code.
• Building, testing, and operating this large monorepo can require Docker, browser binaries, substantial memory, multiple environment files, and external services.

Operators must generate and protect NEXTAUTH_SECRET and a 32-byte CALENDSO_ENCRYPTION_KEY, secure PostgreSQL and OAuth credentials, replace documented placeholder secrets, and review public exposure. The README documents partial CSP support, optional rate limiting, and a TLS-verification bypass only for trusted SSL termination; no independent audit or full threat model was supplied.