Self-hosted scheduling and booking in 2026: revisit Cal.com, Easy!Appointments and Rallly before you share another Calendly link

Booking a meeting looks like a small thing. You share a link, the other person picks a slot, and an invite lands in both calendars. Behind that link, though, sits a lot of data: your free and busy times, the names, emails and phone numbers of people who book you, meeting notes, and often an OAuth token that can read and write your whole calendar. When that link belongs to a hosted SaaS, all of this lives on someone else’s servers.

Self-hosted scheduling tools put that data back on infrastructure you control. In 2026 three open source options deserve a calm look, and one of them has changed a lot this year: Cal.com, which moved its commercial product to closed source in April 2026 and released its open code as Cal.diy under MIT; Easy!Appointments, a long running PHP booking system for service businesses; and Rallly, a group poll tool for finding a date that suits everyone.

These three do not solve the same problem. That is the first thing to learn. Then unlearn the idea that every meeting needs a booking page. Re-learn how calendar sync, OAuth tokens and CalDAV work. Practise a database restore. Then apply the right tool to the right kind of meeting.

A scenario to keep us honest

This is an invented scenario, not a real company. Kochi Coastline Physio is a small clinic with three physiotherapists, one front desk person and one part time IT helper. Patients call or send WhatsApp messages to book sessions, and the front desk keeps a paper register plus a shared Google Calendar. Separately, the three partners struggle every month to find a common evening for their review meeting. The clinic wants:

• An online booking page where patients choose a therapist, a service and a slot
• Therapist calendars that stay in sync, so double booking stops
• A simple way to agree on a meeting date among the partners
• Patient data kept on a server the clinic controls, with a clear deletion process

We will come back to this clinic at the end.

Three kinds of scheduling

Before comparing tools, separate the problems:

• Personal booking links: one person, or a small group, publishes availability and others book a slot. This is what Calendly made popular. Cal.com and Cal.diy are built for this.
• Service appointments: a business offers services, with providers, working plans, breaks and customer records. Think clinics, salons, tutors and repair shops. Easy!Appointments is built for this.
• Group date polls: a group votes on a few proposed options and one is finalised. Nobody’s calendar is exposed. Rallly is built for this.

Choosing the wrong category causes more pain than choosing the wrong tool within a category.

Where these tools came from

Cal.com and Cal.diy

The calcom repository on GitHub was created in March 2021, and for about five years Cal.com was one of the best known open source alternatives to Calendly. On 14 April 2026, co-founder Bailey Pumfleet published a post titled “Cal.com is going closed source. Here’s why.” The stated reason was security: the company said AI tools now make it much easier to find and exploit vulnerabilities in public code, and that it handles sensitive booking data.

At the same time, the company renamed the public repository from calcom/cal.com to calcom/cal.diy and released that code as Cal.diy. According to the Cal.com engineering post of 15 April 2026, enterprise and commercial features were removed before the rename. The Cal.diy README describes it as the community edition, community maintained, and “strictly recommended for personal, non-production use”. The commercial Cal.com codebase is now private; the v6.4 changelog says customers self-hosting the enterprise edition receive invites to a private repository. At the time of writing, the latest tagged release on the cal.diy repository is v6.2.0, published on 2 March 2026 (IST), although commits continue on the main branch.

This is the most important governance fact in this article. If you read an older guide that says “self-host Cal.com”, it now means “self-host Cal.diy”, with a different feature set and a clear warning from its own maintainers.

Easy!Appointments

Easy!Appointments was created by Alex Tselegidis, and its GitHub repository dates from November 2014. The README calls it “a powerful, self-hosted appointment scheduling platform built for flexibility”. It is a mature project with a long release history. At the time of writing, the latest release on GitHub is 1.6.1, published on 19 October 2026 (IST). The author also offers premium features and professional services on the project website, separate from the open source code.

Rallly

Rallly is developed by Luke Vella. The repository was created in January 2015 and the project describes itself as an open source scheduling and collaboration tool to “schedule group meetings, without the back-and-forth”. There is a hosted version at rallly.co and a Docker based self-hosting path. At the time of writing, the latest release is v4.16.4, published on 1 November 2026 (IST).

Licences, in plain words

Cal.diy

Cal.diy is licensed under MIT, a permissive licence. You can use, modify and embed it with very few obligations. Earlier, the public Cal.com code was AGPL 3.0 with a separate commercially licensed enterprise directory. The Cal.com engineering post confirms the change from AGPL 3.0 to MIT for Cal.diy. The commercial Cal.com product is now closed source and not available to self-host without a commercial agreement.

Easy!Appointments

The code is licensed under GPL v3.0, and the content under CC BY 3.0, according to the README. The README also says it is free for both personal and commercial use. For a business that runs it internally, the obligations are small; redistributing a modified version requires sharing source.

Rallly

Rallly is licensed under the GNU AGPL v3 or any later version. You can self-host and modify it freely. If you modify it and offer it to others over a network, you must make your modified source available to those users.

How each is built

Cal.diy

• Next.js, tRPC and Prisma, according to the README
• Node.js 18 or newer, Yarn recommended
• PostgreSQL 13 or newer
• A NEXTAUTH_SECRET and an encryption key must be generated for the environment file
• Docker and several platform deployment options are documented
• It is a large monorepo; the README even suggests raising the Node memory limit for development builds

Easy!Appointments

• PHP 8.2 or newer
• Apache or Nginx
• MySQL database
• Classic install: upload the folder, make the storage directory writable, copy config-sample.php to config.php and follow the setup wizard
• A Docker Compose environment is provided for development

Rallly

• Next.js, Prisma, tRPC and Tailwind CSS
• Shipped as a Docker image
• The official self-hosting Compose file bundles PostgreSQL, an S3 compatible object store (Garage) and an optional Traefik reverse proxy with Let’s Encrypt; each can be replaced with an external service
• Needs an SMTP server for sending emails such as login links and notifications

In short, Easy!Appointments is the lightest and most familiar stack for anyone who has run a PHP and MySQL site. Rallly is a small set of containers. Cal.diy is the heaviest, with a large Node application that you should not underestimate.

Calendar sync

Sync is where scheduling tools succeed or fail. A booking page is only as good as its knowledge of when you are really busy.

Cal.diy

Cal.diy keeps the Cal.com app store framework, which includes calendar integrations such as Google Calendar, Microsoft Outlook and Office 365, and CalDAV. Google and Microsoft integrations need you to register your own OAuth application with those providers, because a self-hosted instance cannot use Cal.com’s credentials. Plan time for this; OAuth consent screens and redirect URLs are the most common setup trouble.

Easy!Appointments

The README lists Google Calendar synchronisation as a core feature. The changelog for recent releases shows active work on CalDAV synchronisation too, including clearer error messages, independent Google and CalDAV sync so that one failure does not skip the other, and rules about which CalDAV hosts on a local network are allowed. That CalDAV support means it can work with self-hosted calendar servers such as Nextcloud or Radicale.

Rallly

Rallly does not need to read your calendar to work. Participants vote on proposed options without creating an account, and the organiser finalises a date and notifies everyone. For a group that does not want to expose calendars to each other, this is a feature, not a limitation. Check the current documentation for any calendar connection features before you depend on them.

Features that matter for a small team

Cal.diy

• Event types, booking pages, availability rules and buffers
• Calendar and video conferencing integrations through the app store
• Webhooks and API v2
• Not included, according to the Cal.com engineering post: Teams and Organizations, Routing Forms, Workflows such as automated reminders, Instant Booking, SAML and SSO, Insights dashboards and API v1

That last list matters. Team round robin booking and automated reminder workflows were reasons many companies chose Cal.com. In Cal.diy they are gone.

Easy!Appointments

• Appointment and customer management
• Services and providers, with working plans and booking rules
• Separate roles such as admin, provider and secretary
• Email notifications and a multi-language interface
• A REST API and webhooks, and LDAP related features mentioned in the changelog

Rallly

• Date and time polls with an availability grid
• No account needed to vote
• Comments on the poll and notifications when people respond
• Finalising a date and informing everyone
• More than ten community translated languages

Operations

Installation

• Cal.diy: Docker or a Node build, PostgreSQL, environment secrets and your own OAuth apps for calendar providers
• Easy!Appointments: a PHP web host with MySQL is enough; a pilot can run on a small virtual machine
• Rallly: the official Compose setup with a helper script, plus working SMTP

Upgrades

• Cal.diy: read the commit history and release notes carefully; database migrations run through Prisma, so take a backup first. Remember that it is community maintained now.
• Easy!Appointments: follow tagged releases; recent changelogs contain many security fixes, so staying current matters.
• Rallly: releases are frequent. Pin a major image tag, as the official Compose file does, and update deliberately. The helper script also manages PostgreSQL major upgrades into a fresh volume, keeping the old one for rollback.
• For all three, take a database backup immediately before each upgrade.

Monitoring

Watch that the service is up, that outgoing email actually reaches people (a silent SMTP failure means missed bookings), and that calendar sync jobs are succeeding. An expired OAuth token can quietly stop sync and lead to double bookings.

Backups

A scheduling tool holds data people care about: future appointments and customer contacts.

• Back up the database with the native tool: pg_dump for Cal.diy and Rallly, mysqldump or mariadb-dump for Easy!Appointments
• For Rallly, also back up the object storage bucket if you use features that store files there
• Back up configuration: environment files, Compose files, config.php, and the encryption keys; without the Cal.diy encryption key, stored calendar credentials cannot be decrypted
• Keep one copy off the server and restore it once on a spare machine before you trust it

Security

OAuth tokens are the crown jewels

A scheduling tool connected to Google or Microsoft holds tokens that can read and often write calendars. Ask for the narrowest scopes possible, store secrets safely, rotate them when staff leave, and remove the connection from the provider’s side too. Easy!Appointments’ own changelog shows fixes that stopped calendar tokens and CalDAV passwords from being returned to other accounts; this is the kind of bug that matters most here, so upgrade promptly.

Public booking pages attract abuse

Booking pages are public by design. Put the app behind HTTPS, add rate limiting at the reverse proxy, and watch for spam bookings. Keep the admin interface on a separate path that you can restrict by IP, VPN or single sign on.

Outbound requests

CalDAV and webhook features make the server call URLs that users configure. That can be used to reach internal addresses. Easy!Appointments now blocks local network CalDAV hosts unless an admin allows them. For any tool, limit the container’s outbound network and keep it away from cloud metadata endpoints.

Take the Cal.com warning seriously

Cal.com’s own reason for going closed source was the risk of vulnerabilities in public code being found quickly. You do not have to agree with that decision to learn from it. Whatever you self-host, plan for fast patching, and do not expose more than you need.

The Indian context: the DPDP Act

A booking system collects names, phone numbers, emails and sometimes the reason for a visit. For a clinic, that reason can be sensitive health information. Under the Digital Personal Data Protection Act, 2023, this is personal data and you are responsible for it. Tell people clearly why you collect each field, collect only what you need, set a retention period for past appointments, and delete records properly when the purpose is over or when a person asks. Hosting on a server in India that you control makes it easier to answer where the data lives. If you connect Google or Microsoft calendars, appointment details also flow to those providers, so record that in your notice. This is general guidance, not legal advice.

When not to adopt each

Do not choose Cal.diy if

• You need it for a business critical, production use case; its own README says it is recommended for personal, non-production use
• You need teams, round robin, routing forms, automated reminders or SSO; those were removed
• Nobody on the team is comfortable running a large Node.js application

Do not choose Easy!Appointments if

• You only need personal meeting links for a sales or consulting team; the provider and service model may feel heavy
• You need a modern multi-tenant setup for many separate businesses on one install

Do not choose Rallly if

• You need customers to book specific slots from your live availability; Rallly finds a date for a group, it is not a booking page
• You cannot provide a reliable SMTP server

Do not self-host at all if

• Nobody will own patches and backups; an unpatched public booking page with calendar tokens is worse than a hosted service

Back to Kochi Coastline Physio

For this invented clinic, a sensible path is to pilot Easy!Appointments for patient bookings. Its model of services, providers and working plans matches a clinic closely, the PHP and MySQL stack is easy for a part time IT helper, and Google Calendar or CalDAV sync keeps each therapist’s calendar current. The front desk gets a secretary role, not admin. For the partners’ monthly review, a self-hosted Rallly instance, or even its hosted version since no patient data is involved, solves the date problem without anyone sharing a calendar. Cal.diy is not the right fit here, because the clinic’s booking is a production, patient facing service and the project itself advises against that. The clinic also writes a short notice for patients and sets a deletion period for old appointments under the DPDP Act. No hands-on drill was run for this article; the plan is based on the projects’ own documentation.

Revisit checklist

• Decide which kind of scheduling you need: personal links, service appointments or group polls
• Check the current licence and governance, especially for Cal.com and Cal.diy after April 2026
• Confirm calendar sync: Google, Microsoft or CalDAV, and who registers the OAuth app
• Test outgoing email before going live
• Pin versions and read release notes before each upgrade
• Back up the database, configuration and encryption keys, and keep one copy off site
• Restrict admin access, rate limit public pages and limit outbound network
• Map booking data to DPDP notice, retention and deletion
• Practise a restore before you trust it

Sources

• Cal.com, “Cal.com is going closed source. Here’s why.”: https://cal.com/blog/cal-com-goes-closed-source-why
• Cal.com, “Moving to closed-source: the technical changes”: https://cal.com/blog/cal-diy-open-source-to-closed-source
• Cal.com v6.4 changelog: https://cal.com/blog/calcom-v6-4
• Cal.diy repository and README: https://github.com/calcom/cal.diy
• Easy!Appointments website: https://easyappointments.org/
• Easy!Appointments repository, README and changelog: https://github.com/alextselegidis/easyappointments
• Rallly website: https://rallly.co/
• Rallly repository and README: https://github.com/lukevella/rallly
• Rallly self-hosting files: https://github.com/lukevella/rallly-selfhosted
• Rallly self-hosting documentation: https://support.rallly.co/self-hosting
• Digital Personal Data Protection Act, 2023: https://www.meity.gov.in/