Self-hosted scheduling: Cal.diy, Cal.com, and the tradeoffs

First, identify the product you are evaluating

As of the April 2026 announcement, Cal.com’s commercial production code is private. Cal.diy is the separate MIT-licensed community project for individual self-hosting. Commercial team and organization features were removed from that community edition.

This distinction changes the buying decision. Do not treat a community deployment as a free substitute for a paid multi-user commercial installation. Read the current project documentation and license for the exact release you intend to use.

Self-hosting changes who does the work

Running the application yourself means someone must own installation, upgrades, monitoring, backups, and recovery. Calendar and email integrations also need configuration and continued attention.

Before choosing this route, name the person who will respond if guests cannot book, confirmations stop arriving, or an update breaks the workflow. If nobody can own that responsibility, evaluate a hosted scheduler first.

Use a deployment checklist, not a guessed server size

Infrastructure requirements change between releases and depend on the workload. Use the current repository instructions for your chosen version instead of copying an old generic server specification.

Start with a non-production evaluation. Confirm that the features you need exist in the community project before connecting a real client workflow.

• Record the exact version and license you evaluated.
• Verify the required booking types and host model.
• Confirm how calendar integrations and email delivery are configured.
• Test restoring a backup, rather than only creating one.
• Document the upgrade process and how to return to a working version.
• Assign ongoing maintenance and an incident contact.

Compare total ownership cost

Include infrastructure, maintenance time, email delivery, monitoring, and recovery work. Removing a per-user subscription does not remove those costs.

Self-hosting is most compelling when controlling the deployment or modifying the software is a concrete requirement. If your main need is simply to let clients book a call, compare hosted free plans before taking on the operational work.

Keep the decision reversible

Before depending on any scheduler, check how you can export the information you need and how existing appointments would be handled during a move. Document your configuration and integration dependencies.

Do not migrate a live team based on a feature name alone. Prove the actual booking, cancellation, reminder, and recovery workflows in the product and version you plan to run.