Self-Host Cal.com: Calendly Alternative Scheduling 2026

TL;DR verdict

Self-host Cal.com when scheduling is strategic infrastructure: you want code-level control, no vendor seat tax on booking links, tighter data residency, and the ability to shape booking flows around your product. Use hosted Cal.com when you want Cal.com's workflow without operating it. Stay on Calendly when reliability, account support, and the simplest non-technical admin experience matter more than open-source control.

The 2026 status check is important: Cal.com's public self-hosted codebase now presents as Cal.diy in the GitHub repository metadata. Cal.diy currently publishes an MIT license file and the repository API reports MIT license metadata. Do not treat that as a blanket promise that every hosted Cal.com feature, enterprise add-on, support entitlement, or future release is available in the self-hosted build.

Key takeaways

Open-source status: Cal.diy is the self-hosted/community codebase, currently MIT-licensed, and the sample environment file says no self-host license key is required.
Product boundary: Hosted Cal.com, Cal.diy self-hosting, and Cal.com Enterprise are separate buying surfaces. Verify feature parity before promising round-robin, routing, SSO, analytics, or compliance controls to stakeholders.
Real operating stack: Plan for PostgreSQL, Redis, NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY, email delivery, Google or Microsoft OAuth credentials, backups, updates, and monitoring.
Pricing comparison: Cal.com listed Teams at $12 per user/month yearly and Organizations at $28 per user/month yearly when checked on 2026-05-14. Calendly listed Standard at $10 per seat/month yearly, Teams at $16 per seat/month yearly, and Enterprise starting at $15,000/year when checked on 2026-05-14.
Best fit: Self-hosting is strongest for technical teams with compliance, branding, embed, or workflow-control requirements. It is weak for teams that do not already maintain production web apps.

At-a-glance decision table

Best fit	Choose this path	Why it wins	Main tradeoff
Solo operator or small team that just needs booking links	Calendly Free/Standard or Cal.com hosted Free/Teams	Fastest setup, no server to maintain, strong defaults	Per-seat/team feature gates and less infrastructure control
Technical team that wants open-source scheduling control	Self-host Cal.diy	MIT-licensed codebase, no self-host license key, deployable with Docker Compose	You own uptime, OAuth, email, updates, backups, and support
Revenue, recruiting, or support teams with routing needs but no infra team	Hosted Cal.com Teams/Organizations	Round-robin, routing, analytics, APIs, and admin controls without self-hosting	Paid hosted plans and vendor roadmap dependency
Enterprise buyer with SSO, compliance, SLA, or directory sync requirements	Cal.com Enterprise or Calendly Enterprise	Contracted support and enterprise controls	Custom pricing, procurement, and less code-level control

License and open-source status box

Surface	Current-check summary	What to verify before a compliance review
Public codebase	Cal.com's self-hosted repository resolves to Cal.diy, and the repository metadata reports an MIT license.	Confirm the current repository URL, license file, and any notices in the exact release or Docker image you plan to deploy.
Self-hosted runtime	The environment example says Cal.diy is fully open source and no license key is required.	Confirm whether your needed apps, workflows, routing features, and admin controls are available in your deployed build.
Hosted Cal.com	Hosted Free/Teams/Organizations/Enterprise plans are sold separately from self-hosting.	Check current pricing, plan feature gates, support/SLA promises, and compliance claims on the hosted pricing page.
Brand/trademark	Cal.com and Cal are still Cal.com, Inc. marks even when the self-hosted code is open source.	Do not imply ownership of the Cal.com brand when offering a client-facing managed deployment.

This is the block to reference from the Cal.com tool profile: the open-source status is favorable, but the decision is not just "is it MIT?" It is whether the self-hosted build you operate includes the scheduling, routing, calendar, email, payment, and admin behavior your team depends on.

Hosted vs self-hosted table

Capability	Hosted Cal.com	Self-hosted Cal.diy	Calendly
Setup speed	Minutes; create account and invite users	Hours to days; server, DNS, Docker, secrets, OAuth, email, monitoring	Minutes; mature admin onboarding
License/source control	Commercial hosted product with public OSS roots	Current public codebase is MIT-licensed	Closed-source hosted SaaS
Seat pricing	Free individual tier; paid Teams and Organizations plans	No vendor seat license for the self-hosted build, but you pay infrastructure and labor	Free personal tier; paid Standard/Teams/Enterprise
Team scheduling	Hosted plan feature; verify current tier boundary	Possible fit, but test round-robin/collective/team behavior in your deployed build	Paid team plans
Calendar sync	Hosted integrations managed by vendor	You configure Google/Microsoft/CalDAV-style credentials and callbacks	Hosted integrations managed by vendor
Email/SMS/reminders	Vendor-managed where included by plan	You configure SMTP/SendGrid and own deliverability	Vendor-managed where included by plan
Payments	Hosted payment features where included	You configure payment apps and test the booking workflow	Paid-plan payment integrations
Compliance/SLA	Contracted on business/enterprise surfaces	Your responsibility unless you buy outside managed support	Enterprise contract surface
Customization	Admin settings, embeds, APIs, and hosted app constraints	Code, database, environment, domain, and infra are under your control	Admin settings and integrations only

Deployment model table

Deployment model	Best for	What you operate	Notes
Hosted Cal.com	Teams that want Cal.com but not infrastructure work	Account configuration, users, plan selection, integrations	Use when the product fit is strong and the hosted feature boundary is acceptable.
Single-server Docker Compose	Small internal teams, pilots, and low-volume booking pages	Linux host, Docker, PostgreSQL/Redis volumes, reverse proxy, backups	The official Docker path runs Cal.diy with Docker Compose and can start a local PostgreSQL database, the Cal.diy web app, and Prisma Studio with `docker compose up -d`.
Docker Compose with managed database	Teams that want simpler backups and database operations	App host, Redis if needed, managed PostgreSQL, secrets, networking	The Docker docs describe a remote database path by configuring `DATABASE_URL`. This is the better default for production if you already use managed Postgres.
Platform deployment	Teams standardizing on Railway, Render, Northflank, or similar	Platform config, env vars, database, OAuth callback URLs, deploy logs	Treat marketplace templates as accelerators, not proof that production operations are solved.
Enterprise/managed support	Buyers with SLA, SSO, directory sync, compliance, or procurement needs	Vendor relationship and admin governance	Compare hosted Cal.com Enterprise and Calendly Enterprise before promising self-hosted parity.

Evidence cards

Repository and license evidence. Cal.diy's GitHub API response reported the calcom/cal.diy repository, MIT license metadata, and recent repository activity on 2026-05-14. The raw license file is the standard MIT license under Cal.com, Inc. copyright.

Environment and license-key evidence. The sample environment file states that Cal.diy is fully open source and that no license key is required. The same file also makes the production burden visible: database URLs, NEXTAUTH_URL, NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY, Google login/calendar credentials, Microsoft OAuth toggles, SMTP settings, and SendGrid are all part of a real deployment.

Docker evidence. The self-hosting docs require Docker and Docker Compose, show the clone/copy-env/start flow, and distinguish running the full local stack from running against an available remote database. The compose file includes database and Redis volumes plus runtime environment variables for the app container.

Pricing evidence. Cal.com's hosted pricing page showed Free, Teams, Organizations, and Enterprise surfaces; Calendly's page showed Free, Standard, Teams, and Enterprise. Because both pages are pricing sources, re-check them before quoting dollar amounts in procurement material.

Support caveat evidence. The older Docker repository says Docker resources moved into the main repository and warns that older Docker-resource installations are not the supported path. Use the current Cal.diy repository and docs, not stale Compose snippets copied from old blog posts.

Production Docker path

A minimal production plan is not just "run the container." Use this sequence as the deployment outline:

Create a DNS record such as cal.example.com.
Provision a server or app platform with enough memory, disk, and outbound network access for email/calendar integrations.
Clone the current Cal.diy repository, copy .env.example to .env, and pin the version or image you are deploying.
Set NEXT_PUBLIC_WEBAPP_URL, NEXTAUTH_URL, NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY, DATABASE_URL, and DATABASE_DIRECT_URL deliberately.
Choose local PostgreSQL for a pilot or managed PostgreSQL for production; either way, schedule backups and test restore.
Configure email delivery before inviting users. Booking confirmations and reminders are part of the core product experience.
Configure Google and Microsoft OAuth in the relevant provider consoles, including callback URLs for the final domain.
Put Caddy, Nginx, Traefik, or your platform's edge proxy in front of the app with HTTPS-only redirects.
Run the app, create the first admin user, connect calendars, and test a real booking end to end.
Add uptime monitoring, log retention, update windows, and rollback notes before you move production scheduling links.

git clone https://github.com/calcom/cal.diy.git cal-diy
cd cal-diy
cp .env.example .env
# edit .env before first boot
docker compose pull
docker compose up -d

For production, avoid latest-style drift where possible. Pin the release or image you intend to run, read the release notes, and stage updates against a copy of production data before changing the scheduling link your customers use.

Calendar, email, and OAuth caveats

Self-hosted scheduling is uniquely sensitive because failed integrations create silent customer-facing failures: a time slot looks free when it is not, a confirmation email never arrives, or a paid booking does not trigger the correct workflow.

Google Calendar and Google login: The environment file explicitly notes that self-hosters should configure the Google integration as an internal app so outsiders cannot use Google login to enter your instance.
Microsoft calendar/login: Outlook login is controlled by its own environment setting and OAuth credentials. Test both login and calendar sync if your team uses Microsoft 365.
Email: SMTP can work, but transactional email providers are easier to monitor. Send a real booking confirmation to an external address before cutover.
Video conferencing: Zoom, Google Meet, Daily, and similar apps can have separate marketplace or OAuth configuration. Do not assume they work because the booking page loads.
Payments and webhooks: Paid bookings and automation flows should be tested with sandbox keys, failed-payment states, cancellation, reschedule, and webhook retry behavior.

Maintenance burden

Self-hosting Cal.diy replaces SaaS subscription simplicity with a small production application. The burden is manageable for a team that already operates Docker and databases, but it is not zero.

Area	Monthly owner action	Failure mode if ignored
Updates	Review Cal.diy releases, update staging, run migrations if required, then update production	Security patches lag or a migration surprises the production container
Backups	Back up PostgreSQL and any persistent volumes; restore-test at least quarterly	Booking data, users, and settings are not recoverable after disk or operator failure
Monitoring	Watch HTTPS health, app logs, database disk, memory, and queue/Redis health	Users discover downtime before you do
Email deliverability	Monitor bounce/spam signals and rotate SMTP/API credentials safely	Confirmations and reminders fail even though bookings appear to succeed
OAuth apps	Keep Google/Microsoft callback URLs, consent screens, and client secrets current	Calendar sync or login breaks after provider-side changes
Security	Patch host OS, restrict inbound ports, manage secrets outside Git, and disable unused login paths	Public scheduling pages become an unnecessary attack surface

If nobody owns those rows, use hosted Cal.com or Calendly. If your team already has an operations checklist for internal apps, Cal.diy can fit into it cleanly.

Migration checklist

Use this checklist before replacing Calendly links with self-hosted Cal.diy links.

Cal.com vs Calendly cost model

Cost category	Calendly	Hosted Cal.com	Self-hosted Cal.diy
Vendor seat cost	Free/Standard/Teams/Enterprise tiers	Free/Teams/Organizations/Enterprise tiers	No self-host license key in the current env example
Infrastructure	Included in subscription	Included in subscription	Server, database, storage, backups, monitoring, email, operator time
Support	Vendor support by plan	Vendor support by plan	Community/docs unless you buy separate help
Compliance and contracts	Enterprise plan surface	Organizations/Enterprise surface	Your controls, your audit trail, your risk
Custom code changes	Not available	Limited by hosted product	Available if you can maintain a fork or extension

The common budgeting mistake is comparing "Calendly at $16/seat/month" to "Cal.diy is free." The better comparison is per-seat SaaS spend versus monthly infrastructure plus the time cost of someone who can patch, monitor, back up, and debug a scheduling system.

Methodology

This refresh used the existing guide route rather than creating a separate Cal.com open-source-status URL. The goal was to preserve the self-hosting intent while adding a current license/status block that can also support /tool/cal-com and the scheduling cluster.

Evidence was checked on 2026-05-14 from the Cal.diy GitHub API, raw MIT license, raw environment example, Docker self-hosting docs, raw Docker Compose file, Cal.com pricing page, Calendly pricing page, and the archived Cal.com Docker repository readme. Pricing and license claims are freshness-sensitive; re-check pricing within 30 days and license/self-hosting documentation within 90 days before using this guide for procurement or compliance.

Source-backed FAQ

Is Cal.com still open source?

The self-hosted/community codebase currently resolves to Cal.diy, and the checked repository metadata and license file show MIT licensing. That is favorable for open-source adoption, but you should still verify the exact release, Docker image, and any third-party app terms before a compliance review.

Is self-hosted Cal.diy the same as hosted Cal.com?

Not necessarily. Treat hosted Cal.com, self-hosted Cal.diy, and Enterprise/commercial add-ons as separate surfaces. Hosted pricing pages describe plan features and support boundaries; the self-hosted docs describe deployment mechanics. Test the features you need in your own instance.

Does self-hosting eliminate scheduling costs?

It eliminates the current self-host license key requirement and avoids vendor per-seat billing for the self-hosted app, but it does not eliminate cost. You still pay for infrastructure, backups, email delivery, monitoring, upgrades, and the person who owns production operations.

What is the minimum reliable production stack?

Use HTTPS, PostgreSQL, Redis where the compose stack expects it, strong app secrets, transactional email, calendar OAuth, backups, monitoring, and a tested update path. A single-server Docker Compose deployment can be fine for a small team if it has those basics.

Should I migrate all Calendly links at once?

No. Start with one high-value event type, test bookings from outside your organization, verify calendar conflict checks and confirmation emails, then move the next workflow. Scheduling links are customer-facing production endpoints, so cut over gradually.

When should I choose Rallly instead?

Choose Rallly when the job is group poll scheduling rather than appointment booking. Cal.com is better for book-a-time workflows, routing, teams, embeds, and paid appointments. See the related Rallly comparison below for the narrower decision.

Cal.com on OSSAlt — tool profile for the current open-source alternative listing.
Best Open Source Calendly Alternatives — broader scheduling alternatives shortlist.
How to Migrate from Calendly to Cal.com — migration-focused companion guide.
Rallly vs Cal.com — decide between polls and booking pages.
Migrate Doodle to Rallly or Cal.com — group scheduling migration path.
Self-host Uptime Kuma — monitoring foundation for self-hosted services.
Self-host n8n — workflow automation for booking events and webhooks.
Self-host Duplicati — backup discipline for Docker-hosted apps.

Sources

Cal.diy GitHub repository metadata, checked 2026-05-14.
Cal.diy MIT license file, checked 2026-05-14.
Cal.diy sample environment file, checked 2026-05-14.
Cal.com Docker self-hosting documentation, checked 2026-05-14.
Cal.diy Docker Compose file, checked 2026-05-14.
Cal.com pricing page, checked 2026-05-14.
Calendly pricing page, checked 2026-05-14.
Archived Cal.com Docker repository readme, checked 2026-05-14.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)