Cal.com sells itself as the open-source Calendly alternative, and that pitch lands hardest if you are a developer who would rather run your own scheduling stack than rent one. We spun up a self-hosted instance to see how far the "own your data" promise actually goes in 2026, where the friction lives, and whether the freely licensed core does enough on its own without paying for anything.
What the self-hosted core gives you
The repository is a TypeScript monorepo built on Next.js, Prisma, and PostgreSQL, with north of 30,000 GitHub stars behind it. Clone it, point it at a Postgres database, set your environment variables, and you get a working booking system on your own domain: event types, availability schedules, public booking pages, round-robin and collective team scheduling, routing forms, webhooks, a REST API, and an app store of integrations.
The license is the part to read carefully. The main application is AGPLv3, which means you can self-host it at no cost, but if you distribute a modified version as a network service you are expected to share your changes under the same terms. A separate set of features lives under a commercial enterprise license in the ee/ directory — SAML single sign-on, organizations, and some advanced admin controls. So the practical line is this: personal and small-team scheduling is fully covered by the free AGPLv3 core, but you cannot simply lift the enterprise SSO code and skip a paid plan.
Self-hosting removes the per-seat subscription, not the work. You trade a monthly invoice for the time you spend running Postgres, applying schema migrations on upgrade, configuring SMTP for booking emails, and keeping the instance patched. If your team is small and your hours are valuable, that trade is not automatically in your favor.
The self-hosting reality
Getting the app to boot is the easy half. Cal.com ships a Docker setup and documented environment variables, and a database plus a NEXTAUTH_SECRET and an CALENDSO_ENCRYPTION_KEY will get you a running login screen quickly.
The genuinely tedious half is calendar integrations. To connect Google Calendar or Microsoft 365 so that bookings sync both ways and double-bookings are prevented, you register your own OAuth application with each provider. That means creating a project in Google Cloud Console, configuring an OAuth consent screen, setting authorized redirect URIs that match your domain, enabling the Calendar API, and copying client credentials into your environment file — then repeating an equivalent dance in Microsoft's Azure portal. None of it is hard in isolation, but it is the step that turns a five-minute deploy into an afternoon, and it is the step a hosted plan does for you.
Budget real time for OAuth before you promise anyone a working calendar. Google's verification and consent-screen rules, and Microsoft's tenant permissions, are where most first-time self-hosters stall. Test the full booking-to-calendar round trip yourself before you point a single colleague at the instance.
Here is how the three realistic options stack up:
The column that should decide it is "Data location." Everything else — cost, convenience, SSO — has a hosted answer. Control over where booking data lives, and the ability to read and modify the code that handles it, is the one thing only the self-hosted path gives you.
Who should self-host, and who should not
Self-hosting Cal.com is a good fit when you have a concrete reason to keep scheduling data inside your own boundary — a compliance requirement, a data-residency rule, or a customer contract that forbids third-party processors. It is also a good fit when you want to embed scheduling inside your own product, because the API, webhooks, and the ability to fork the UI give you room a hosted widget never will. And it suits teams that already run Node and Postgres in production, where one more service is marginal overhead rather than a new discipline.
It is a poor fit if you are a solo operator who values an afternoon more than a subscription, or if nobody on the team is comfortable owning OAuth credentials, database migrations, and security updates. For that profile, the hosted free tier or Calendly will get you booking meetings today without any of the maintenance tail.
Wherever scheduling lives, the bookings still need a home — a place to document availability rules, route inbound requests, and track follow-ups. A structured workspace handles that layer well, and pairs cleanly with Cal.com's webhooks for logging new bookings.
The short version: Cal.com's self-hosted core is a credible, genuinely open option in 2026, and the AGPLv3 code does more on its own than most "open-source" products that gate the useful features. Just go in knowing the bill you avoid is paid back in OAuth setup and ongoing maintenance.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)