Open-source room booking systems in 2026

I build booking software, so people send me their scheduling problems. The room booking ones follow a pattern I didn't expect: a good half of them are solved by a checkbox in software the company already pays for, and nobody looked before spinning up a server.

So this comparison starts somewhere unusual for a listicle — with the case for installing nothing. Then the real open-source options, which are genuinely good, and the exact point where all of them stop.

Check what you already run

Before installing anything, open your groupware admin and look for room resources. This is badly documented in all three of the big platforms, which is why it gets missed.

Exchange and Google Workspace both have room mailboxes with automatic accept and decline, capacity, and building and floor metadata. Users add the room to a meeting like an attendee; it accepts if it's free. Neither is open source, but if you're already paying for one, adding a separate room tool means running two systems that will eventually disagree about who has the room. That's usually worse than the imperfect thing you already own.

Nextcloud (AGPL-3.0) does it through resource booking in the Calendar app. You define rooms as resources in the backend and they behave the same way — invite the room, it accepts or declines. It's basic: no approval workflow worth the name, no equipment inventory. But if Nextcloud is already running, this costs an afternoon of configuration and zero new services.

I'd have put this section at the bottom a year ago, under "alternatives." It belongs at the top. A meaningful share of "we need room booking software" projects should end here, and the ones that don't will at least know why.

Three different things get called "room booking"

If the check above didn't settle it, the next thing that matters is which problem you actually have. These get conflated constantly and the tools are not interchangeable.

Internal meeting rooms. Employees reserve a conference room for an hour. Calendar integration, recurring bookings, capacity and equipment attributes, ideally a tablet outside the door. Everyone booking is a known, authenticated user. This is the well-served case.

Public or semi-public room hire. A community centre renting a hall, a music school renting rehearsal rooms, a coworking space selling meeting room hours. Bookings come from outside your organisation, usually with payment attached, and the whole thing has to look like a booking page rather than an admin panel. This is where open source gets thin, and I'll come back to why.

Hotel rooms. Different category entirely — you want a property management system. Nights, rate plans, channel manager, OTA sync. Nothing here applies.

Most people searching this term mean the first. The minority who mean the second are the ones who end up disappointed after a weekend of installing.

MRBS is still the right answer for meeting rooms

MRBS — Meeting Room Booking System — is PHP, GPL, maintained since the early 2000s, and still receiving commits in 2026. For a project that old, that last fact matters more than any star count.

It does the thing it was designed for and doesn't pretend to do anything else: a weekly grid of rooms across time slots, click a cell, book it. Multiple areas for buildings and floors, room capacity, custom fields per room, repeat bookings, approval workflows, per-area permissions, email notifications, and authentication against LDAP, IMAP, database or SAML. It reads and writes iCalendar, so bookings show up in Outlook.

It also looks its age. That's fine for a facilities coordinator using it daily and disqualifying for anything a customer sees. Community themes exist if the default bothers you.

LibreBooking, when a room is one resource among several

LibreBooking is the maintained continuation of Booked Scheduler: GPL-3.0, around 800 stars, PHP, commits within the last week as I write this.

The difference from MRBS is conceptual. LibreBooking schedules resources, and a room is just one kind. If your building has eight meeting rooms, three projectors, two company cars and a 3D printer, that's one system with one permission model. MRBS would have you pretending the projectors are rooms.

It also has the pieces MRBS lacks around the edges — a REST API, resource groups, per-user quotas, blackout periods, custom attributes, reminders, and an admin UI you can hand to someone else. The API is the one I'd call out: if you want a Slack bot or a lobby display, LibreBooking gives you something to call.

Generality costs setup time. Because a room is just a resource, the room-specific behaviour is yours to configure rather than yours to receive.

Seatsurfing, only if desks are in scope too

Seatsurfing is GPL-3.0, Go with a React frontend, around 300 stars, actively developed, and it now covers room reservation alongside its original desk sharing.

It's the most modern-feeling of these — clickable floor plans, a mobile app, SSO, containers rather than a PHP tarball. Worth it when the project is genuinely "we went hybrid, people need desks and the four meeting rooms," because that's one deployment instead of two. If meeting rooms are the only problem, MRBS handles the room-specific details with more depth, and I wouldn't take on the extra surface area.

The comparison, and the row that decides it

The bottom two rows are the whole argument. Every open-source room booking system is an internal tool for authenticated staff. Nobody has built the open-source version that takes a card. If you're renting rehearsal rooms or treatment rooms or coworking space, the feature comparison above is irrelevant to you — none of these can do the thing you need, and bolting Stripe onto MRBS is a larger project than it sounds on a Sunday afternoon.

The upkeep, and where these deployments actually stall

Self-hosting is free the way a puppy is free.

Patching is the obligation people underestimate: a PHP application with authentication and a public URL is a standing commitment, and Booked Scheduler had a documented remote code execution vulnerability in 2.7.5. That's not an argument against the software, it's an argument for someone owning updates by name.

The thing that actually kills these projects is duller. It's LDAP and SAML configuration. Not the install, not the theming — the auth integration is where I've watched more than one of these sit half-finished for a month because the person who understood the directory left. Budget a day for it, and do it first, while the project still has momentum.

Beyond that: backups you've restored at least once, and a plan for the PHP major-version bump that's coming whether you plan for it or not. For fifty internal users this is a few hours a quarter and still cheaper than per-seat SaaS. Past a few hundred users, or once money is involved, run the numbers again.

Where the category stops

Three situations where I'd tell you not to run any of these.

You need to take payment. Renting rooms commercially means deposits, refunds, tax and invoices. None of these tools have any of that.

The people booking are customers, not staff. External users need a page that carries your brand, works on a phone, and doesn't ask them to make an account on your admin panel.

You're building room booking into your own product. If you're an agency shipping a coworking platform, or a SaaS adding resource reservation, self-hosting somebody else's application is the wrong shape. You want scheduling as an API you call — availability computed server-side, bookings created over HTTP, payments handled. That's what I built Opencals for, and it's the honest boundary of where the tools above stop rather than a knock against them.

The longer version of that decision: open-source vs hosted booking API. The wider category beyond rooms: open-source booking systems.

If you're on the commercial side of that line — selling room hours rather than allocating them — the thing you need is a booking layer with availability, payments and a page you can point customers at, or an API and SDK if you're building the front end yourself. Pricing is public, it's per booking rather than per seat, and you can get in touch if you want to work out whether the shape fits before committing to anything.