--- og_image: "/images/guides/self-host-cal-com-calendly-2026.webp" title: "Self-Host Cal.com: Calendly Alternative Scheduling 2026" description: "Self-host Cal.com as a Calendly alternative in 2026: licensing, hosted vs self-hosted pricing, Docker, OAuth, email, backups, and migration." date: "2026-05-14" author: "OSSAlt Team" tags: ["cal-com", "calendly", "scheduling", "booking", "self-hosting", "docker", "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: 1. Create a DNS record such as `cal.example.com`. 2. Provision a server or app platform with enough memory, disk, and outbound network access for email/calendar integrations. 3. Clone the current Cal.diy repository, copy `.env.example` to `.env`, and pin the version or image you are deploying. 4. Set `NEXT_PUBLIC_WEBAPP_URL`, `NEXTAUTH_URL`, `NEXTAUTH_SECRET`, `CALENDSO_ENCRYPTION_KEY`, `DATABASE_URL`, and `DATABASE_DIRECT_URL` deliberately. 5. Choose local PostgreSQL for a pilot or managed PostgreSQL for production; either way, schedule backups and test restore. 6. Configure email delivery before inviting users. Booking confirmations and reminders are part of the core product experience. 7. Configure Google and Microsoft OAuth in the relevant provider consoles, including callback URLs for the final domain. 8. Put Caddy, Nginx, Traefik, or your platform's edge proxy in front of the app with HTTPS-only redirects. 9. Run the app, create the first admin user, connect calendars, and test a real booking end to end. 10. Add uptime monitoring, log retention, update windows, and rollback notes before you move production scheduling links. ```bash 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. - [ ] Export or inventory every Calendly event type, duration, buffer, location, question, reminder, payment, and routing rule. - [ ] Decide which links stay individual and which become team, round-robin, collective, or routing-form workflows. - [ ] Map each user to their calendar provider and confirm the OAuth path works on the final domain. - [ ] Recreate the most important event types first; do not migrate rarely used links until the core workflow is stable. - [ ] Test double-booking prevention by creating a busy calendar block and attempting to book over it. - [ ] Test email delivery to Gmail, Microsoft 365, and a non-corporate mailbox if customers use mixed providers. - [ ] Recreate website embeds and confirm the iframe or embed script works with your CSP and cookie settings. - [ ] Recreate webhooks and automations for CRM, Slack, n8n, Zapier, or internal systems. - [ ] Run paid-booking flows in sandbox mode if you collect payment before appointments. - [ ] Keep old Calendly links alive or redirected during the transition window. - [ ] Add a rollback plan: DNS, old links, data export, and a person authorized to pause cutover. ## 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. ## Related guides - [Cal.com on OSSAlt](/tool/cal-com) — tool profile for the current open-source alternative listing. - [Best Open Source Calendly Alternatives](/guides/best-open-source-alternatives-to-calendly-2026) — broader scheduling alternatives shortlist. - [How to Migrate from Calendly to Cal.com](/guides/how-to-migrate-from-calendly-to-calcom-2026) — migration-focused companion guide. - [Rallly vs Cal.com](/guides/rallly-vs-cal-com-2026) — decide between polls and booking pages. - [Migrate Doodle to Rallly or Cal.com](/guides/migrate-doodle-to-rallly-cal-com-2026) — group scheduling migration path. - [Self-host Uptime Kuma](/guides/how-to-self-host-uptime-kuma-website-monitoring-2026) — monitoring foundation for self-hosted services. - [Self-host n8n](/guides/how-to-self-host-n8n-zapier-alternative-2026) — workflow automation for booking events and webhooks. - [Self-host Duplicati](/guides/how-to-self-host-duplicati-encrypted-cloud-backup-2026) — 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.