Cal.diy

Last reviewed Sep 13, 2026 · 835 words

The MIT licence is the reason Cal.diy exists as a separate project from Cal.com, and it is the first thing to understand before deploying it. Upstream Cal.com is AGPL-3.0 with a commercial enterprise layer; Cal.diy strips that out and publishes the scheduling core under MIT, which means you can embed it in a product, modify it, and never send a line of code back. For a solo consultant who wants a booking page, that distinction is irrelevant. For a company putting scheduling inside its own app, it is the whole decision. Either way you are getting the same TypeScript and Next.js codebase, 48,134 stars behind it, and the same setup effort, which is more than the phrase "self-hosted Calendly" implies.

The install is a Next.js app, and it behaves like one

Cal.diy needs PostgreSQL and a machine willing to build a large Next.js monorepo. The catalogue's 512 MB is what it idles at once built; the build itself wants several gigabytes and a coffee break, and a 1 GB VPS will fail it with an out-of-memory error that looks like a random TypeScript crash. Use the prebuilt container image where one is offered, or build on a bigger machine and ship the image. Configuration follows upstream Cal.com: a DATABASE_URL, a NEXTAUTH_SECRET, an encryption key for stored calendar credentials, and a public URL that must match what your reverse proxy serves. Run it behind Caddy or Traefik on port 3000 and get TLS working before you touch any integration, because every OAuth provider refuses plain-HTTP callback URLs.

Calendar connections are where the hours go

A booking tool is only useful if it can read your busy times, and that means OAuth apps. Google Calendar requires creating a project in the Google Cloud console, enabling the Calendar API, configuring a consent screen, and pasting a client ID and secret into your environment. Google marks the app as unverified, which is fine for your own account and your team but shows a scary warning to anyone else. Microsoft 365 is the same dance in Entra. CalDAV, including Nextcloud calendars, is the one that just works with a URL and an app password, and for a self-hoster it is the connection I would set up first. Expect 2 hours for the Google and Microsoft pair the first time and 15 minutes for CalDAV.

Video is a second round of the same. The hosted product's built-in meeting rooms lean on a third-party service; self-hosted, you either add Jitsi Meet as the location, which works well and needs no keys, or wire up Zoom or Google Meet with yet another OAuth app.

The scheduling engine is the strongest part

Once connected, the feature set is complete in a way rivals are not: event types with buffers and limits, round-robin and collective bookings for teams, availability schedules per person and per event type, workflows that send reminder emails and SMS, webhooks for every booking lifecycle event, and an API you can drive from automation. Round-robin across a 5-person sales team with fairness weighting is the feature that keeps companies paying Calendly, and it is here. The Calendly alternatives page covers what the hosted product does that self-hosting cannot, mostly the polished native integrations that depend on the vendor holding the OAuth apps.

When you don't need this at all

If the job is "find a time that works for 6 people", Rallly does it in one container with no OAuth at all. If you want a personal booking link and already run Nextcloud, its Calendar app has appointment booking built in and reads your busy times without a single extra credential. Cal.diy pays off when you need team scheduling, multiple calendars per person, or programmatic control. The rest of the calendar category sits between those points.

Youth shows in the docs, not the code

The catalogue is right that Cal.diy is younger than its rivals as a project. The code has years of upstream maturity; the self-hosting documentation and the container packaging are what is still settling, and the answers you find in forums often refer to upstream Cal.com paths and variable names. That is usually fine because they are the same, but check dates on anything you copy.

What I'd do

Solo user with a Nextcloud already running: use Nextcloud's appointment booking and skip this. Small team that needs round-robin, buffers and reminders, or a developer embedding scheduling in a product: run Cal.diy on a 2 GB VM behind Caddy, connect CalDAV first and Google second, use Jitsi as the default location, and keep the OAuth secrets in your password manager because you will be rotating them. The MIT licence makes it the one scheduling tool in this space you can build on without a lawyer.