Open-source booking system: do you actually need one?
Most people who type "open source booking system" into a search box want one of three things: software that costs nothing, a booking page that looks like their site instead of someone else's, or data that lives on a server they control. Only the third one actually requires running the backend yourself. The first two are better served by something else, and that's what this article is about.
I build booking software for a living, so read this knowing I have a horse in the race. I'll tell you where self-hosting is the right call, which projects are still alive in October 2026, and where my own product doesn't fit.
An open-source booking system is free to download and expensive to own. After the install you're the one running payments, reminders, time zones, security patches, backups and uptime. Self-host when the data has to sit on your own infrastructure or the bookings are internal (rooms, desks, kit). If what you actually want is a booking flow that looks and behaves exactly like your brand, rent the engine through an API and own only the front end — the way Shopify merchants own their theme but not the checkout.
The obvious answer closed its source in April
For years the reflex answer to this search was Cal.com. On 15 April 2026 Cal.com closed its source. The pre-closure code lives on as Cal.diy under MIT, maintained by the community, and its own site says it is "strictly recommended for personal, non-production use." Teams, SAML SSO, Workflows, Routing Forms and the Insights dashboard aren't in it.
I wrote up what happened, and what to do if you were self-hosting it, separately:
Cal.com went closed source
What changed on 15 April 2026, what Cal.diy is and isn't, and what to do if you were self-hosting Cal.com.
The bigger lesson isn't about Cal.com. It's that "open source" was doing a lot of quiet work in people's heads. Plenty of teams running the AGPL version had never forked it, patched it or read it. They were trusting a funded company to maintain it, which is the same trust you place in a SaaS vendor, minus the uptime guarantee.
Downloading it is the cheap part
Here's what you own the morning after docker compose up works.
Payments. A booking that isn't paid for is a reservation, and reservations get no-showed. Taking money means Stripe keys, webhook endpoints, signature verification, retries, idempotency so a double-clicked "Pay" doesn't charge twice, refunds, partial refunds, deposits, and cancellation fees that have to agree with whatever policy text you showed the customer. None of the open-source schedulers I looked at treat this as the core of the product. It's a plugin, an integration, or your job.
Notifications. Confirmation, reminder, reschedule, cancellation, receipt. Each one is a template, a trigger and a queue. Then deliverability: SPF, DKIM, a sending domain that doesn't land in spam, and something that notices when the reminder job silently stopped three weeks ago.
The scheduling rules. Buffers between appointments. A stylist who works Tuesdays at one location and Thursdays at another. A room that two staff members can't use at once. Daylight saving time, which will break your reminders twice a year until you get it right. Two customers hitting "Book" on the last slot in the same second.
Security and upkeep. Dependency updates, framework upgrades, PHP or Node version bumps, TLS certificates, backups you've actually tested restoring, and someone who answers when the server falls over on a Saturday. If you store customer names, phone numbers and appointment history for people in the EU, there's GDPR on top: access requests, deletion requests, a record of who processes what.
None of this is exotic. It's just a lot, and it never ends. I wrote a longer piece on exactly where those hours go for developers building it themselves:
Booking system for developers: what you still build
Availability search, reschedule links, payment failures and reminder queues — the parts that take longer than the estimate.
There's also an architecture point that rarely comes up. Most self-hostable booking projects are one app and one database, built to install on cheap shared hosting or a small VPS. That's a feature when you're a solo therapist. It's also the ceiling. Nobody load-tested it for a chain of twelve locations taking bookings from a marketing campaign at 9am on a Monday, and you'll be the one who finds out where it bends.
What's actually still open source (checked 3 October 2026)
Short list, because the honest version is short. Licences, languages and release dates below are from each project's GitHub repository on the day I checked.
| Project | Licence | Stack | Built for | Latest release |
|---|---|---|---|---|
| Easy!Appointments | GPL-3.0 | PHP | Customer appointments with staff and services | 1.6.0, 27 May 2026 |
| Cal.diy | MIT | TypeScript | One-to-one meeting scheduling (community fork of Cal.com) | v6.2.0, 1 March 2026 |
| LibreBooking | GPL-3.0 | PHP | Rooms, desks, equipment and other shared resources | v6.0.0, 1 October 2026 |
| Rallly | AGPL-3.0 | TypeScript | Group polls for finding a meeting time — not booking | v4.15.3, 29 September 2026 |
Easy!Appointments is the one I'd look at first for customer-facing appointments. Its GitHub history goes back to 2014, it still ships releases, and it models what service businesses actually have: services, providers, working plans. Its site lists payments, SMS and reports, but doesn't spell out which of those come with the free download and which are part of the paid services the maintainer sells (custom development, hosting, support). Check that against your list before you commit a weekend.
Cal.diy has the biggest community by far (around 48,800 GitHub stars), but read the warning on its own homepage before putting customers on it.
LibreBooking (the old Booked Scheduler / phpScheduleIt line) is the right tool if your bookings are internal — a meeting room, a hot desk, a lab instrument. It's a different problem from customer appointments, and I've written separate comparisons for each variant:
Open-source room booking
Meeting rooms and shared spaces — what to self-host and what you already own.
Open-source desk booking
Hot desks and hybrid offices, compared honestly.
Open-source equipment booking
Lab kit, tools and shared equipment.
Open-source patient scheduling
Clinics, practices and the charting question.
Rallly gets lumped into these lists a lot. It's a self-hosted Doodle. Great at what it does, which isn't taking bookings from customers.
Three cases where I'd still self-host
I'm not going to pretend the answer is always "use a SaaS". Self-hosting is the right call when:
- The data legally has to sit on your infrastructure. Some public bodies, some hospitals, some government contractors. If a hosted product can't sign what your lawyer needs, the conversation is over, and you should budget for the maintenance list above as a real line item.
- The bookings are internal. Staff booking rooms or kit behind your own login. No payments, no public traffic spikes, no customer emails. LibreBooking on an internal server is a perfectly sane setup.
- You want to own a booking product, not run a booking. If you're an agency or a dev shop that wants to fork something, maintain it, and sell it, then the maintenance burden is your business. Go in with your eyes open.
If none of those describe you, you're probably searching "open source" as shorthand for "flexible and not locked into someone's ugly widget." That's a real need. It just has a cheaper answer.
Own the storefront, rent the engine
The closest analogy I know is e-commerce. Fifteen years ago a small shop that wanted a store that looked like their brand self-hosted Magento and paid a developer to keep it alive. Today the same shop uses Shopify. Shopify runs the checkout, the payments, the order pipeline, the security. The merchant (or their agency) owns the theme, and can build anything on top of the API — a custom storefront, a mobile app, an integration with their warehouse.
Opencals is that split for service businesses. I describe it as Shopify for services, and it's the reason I built it the way I did.
What we run: the scheduling engine (staff, locations, resources, buffers, time zones, capacity for group sessions), orders, payments through Stripe, deposits and cancellation fees, refunds, rescheduling, invoices, customer accounts, and the confirmation and reminder emails. Card data goes straight to Stripe — we never see full card numbers, so you're not carrying PCI scope on your own server. Patching, backups and uptime are ours.
What you own: everything the customer sees. The public Storefront API and a typed TypeScript SDK let you build any front end you like: a Next.js site, a mobile app, a booking flow inside a product you already have, or a server-side integration that creates appointments from your own system. Here's the whole booking path, using the real SDK:
import { setupOpencals, ProductService, AppointmentService, CartService, CheckoutService } from '@opencals/storefront-sdk';
setupOpencals({ apiKey: process.env.OPENCALS_API_KEY });
// Live availability for a service, staff member and location
const { data: slots } = await ProductService.getCurrentAvailabilities({
path: { productId: 'prod_123' },
query: { date: '2026-10-15', staffMemberId: 'staff_456', locationId: 'loc_789' },
});
// Hold the slot, put it in a cart, take payment
const { data: appointment } = await AppointmentService.create({
body: {
slot: { productId: 'prod_123', fromDate: '2026-10-15', fromTime: '10:00:00', toDate: '2026-10-15', toTime: '11:00:00' },
numberOfAttendees: 1,
},
});
await CartService.createOrGet();
await CartService.addItem({ body: { appointmentId: appointment.id } });
await CheckoutService.start({ body: { provider: 'stripe', customer: { email: 'jane@example.com' } } });
await CheckoutService.submit();That's the whole integration surface for a booking. Everything that happens after — the confirmation email, the reminder, the reschedule link, the refund if they cancel inside the policy window — happens on our side.
And this is where the "open source" part comes back in, honestly: the front end is open. The SDK is MIT on npm, and so are the Next.js booking site templates — a salon, a barbershop, a clinic and a padel club so far. Clone one, rebrand it, deploy it to Vercel, sell it to a client. Nobody has to ask us.
Haar: a free salon booking website template
MIT-licensed Next.js site with services, staff, multi-location booking and Stripe checkout, running on the Storefront API.
Most hosted booking apps give every business the same storefront with a different logo on it. Ours exists too, and plenty of customers are happy on it, but you're not stuck with it. That's the part you can't get from a widget, and the part people were really after when they went looking for open source.
Headless booking system
How running booking behind your own UI works, and when it's worth the extra front-end work.
Where my argument stops working
Some things you should hear from me rather than discover later.
- Opencals is not open source. The templates and the SDK are MIT. The engine isn't, and I'm not planning to open it. If source access to the backend is a hard requirement, this isn't your product.
- You can't self-host it. Our infrastructure runs on AWS in the US. If your data has to stay on your own servers or in a specific country, go back to the self-hosting section.
- The free tier doesn't take real money. A development store is free forever, with every feature and every API endpoint, but it runs in test mode. Going live is either $0.99 per completed booking with no monthly fee, or a fixed plan from $14.98 a month with 300 bookings included and $0.20 for each one after (opencals.com/pricing, checked 3 October 2026). At low volume that's cheaper than a VPS and your time. At a few thousand bookings a month a self-hosted system costs less in invoices — and more in everything else.
- You're trusting a small company. The same question I asked about Cal.com applies to us. It's fair to ask any vendor, me included, what happens to your bookings if they change direction.
How I'd decide, in one pass
| Self-hosted open source | Hosted booking app | Booking API + open templates | |
|---|---|---|---|
| Who runs payments, refunds, deposits | You | The vendor | The vendor (Stripe underneath) |
| Who patches, backs up, keeps it up | You | The vendor | The vendor |
| How much of the booking UI you control | All of it, if you maintain the fork | Colours and a logo | All of it |
| Where the data lives | Your servers | The vendor's | The vendor's |
| Cost that shows up on an invoice | Hosting only | Monthly plan | Per booking or monthly |
| Cost that doesn't | Your weekends | Being stuck with their storefront | Front-end build time |
If you're a developer or an agency and that last column sounds right, start with a free development store, point one of the templates at it, and see whether the API covers your client's edge cases before you write anything custom.
The Opencals booking SDK
Typed TypeScript for availability, carts, checkout and customer accounts.
Booking API for developers
Auth, endpoints and examples for the Storefront API.
How to build a booking website
Three approaches compared, from no-code to fully custom.
Clarity: an open-source clinic template
A free Next.js clinic booking site you can fork today.
Frequently Asked Questions
Get started
Ready to transform your service business?
Join 150+ businesses already using Opencals. Start on a free development store with every feature unlocked, and only pay once you go live.