Open-source room booking systems in 2026

Rooms are the oldest shared resource in an office, and somehow still the worst-managed one. Someone books the big room for a 30-minute call and holds it for three hours. Two teams show up at the same door. A recurring standup keeps a room reserved for a team that dissolved last spring.

The software that fixes this is not complicated — a list of rooms, a calendar, a permission model, and a way to release a booking nobody turned up for. Which is exactly why so many people look for an open-source version instead of paying per user per month for it. Room booking is not where you want your software budget going.

There are real open-source options here. There are also three completely different problems hiding under the phrase "room booking," and most of the frustration I see comes from picking a tool built for one of them and trying to use it for another.

First, which of the three "room booking" problems do you have?

These get conflated constantly, and the tools are not interchangeable.

1. Internal meeting rooms. Employees reserve a conference room for an hour. Needs calendar integration, recurring bookings, capacity and AV equipment attributes, and ideally a tablet outside the door. Everyone booking is a known, authenticated user. This is what MRBS was built for.

2. 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, a clinic renting treatment rooms to visiting practitioners. Bookings come from people outside your organisation, often with payment attached, and the whole thing has to look like a booking page rather than an admin panel. This is where the open-source options get thin fast.

3. Hotel rooms. Completely different category — you want a property management system, not a room booking system. Nights, rate plans, channel manager, OTA sync. If this is you, nothing in this article applies; go look at PMS software.

Most people searching "room booking system open source" mean 1. A meaningful minority mean 2, and they are the ones who end up disappointed, because internal meeting-room tools have no payment layer, no public storefront, and an admin UI you would not put in front of a customer.

MRBS — the veteran, and still the default answer

MRBS (Meeting Room Booking System) is a PHP application that has been maintained since the early 2000s. The code lives at meeting-room-booking-system/mrbs-code, it's GPL, and it is still getting commits in 2026 — which for a project this old is the number that matters more than stars.

What it does well is the thing it was designed for: a weekly grid of rooms across time slots, click a cell, book it. Multiple areas (buildings, floors, sites), multiple rooms per area, room capacity, custom fields per room, repeat bookings, approval workflows, per-area permissions, email notifications, and authentication against LDAP, IMAP, database or SAML. It exports to iCalendar so bookings show up in Outlook or Google Calendar, and it can import too.

What it does not do is look modern. The default interface is functional and dated, which is fine for an internal tool that a facilities coordinator uses daily and is not fine as a public-facing booking page. There are community themes if the default bothers you.

Pick MRBS if you have internal rooms, authenticated staff, and no need to charge anyone.

LibreBooking — a general resource scheduler that handles rooms well

LibreBooking is the maintained continuation of Booked Scheduler, GPL-3.0, around 800 stars, and actively developed — there were commits in the last week as I write this. It's PHP as well.

The important difference from MRBS is conceptual: LibreBooking schedules resources, and a room is just one kind of resource. That flexibility is the reason to choose it. If your building has eight meeting rooms, three projectors, two company cars and a 3D printer, LibreBooking models all of them in one system with one permission model. MRBS would need you to pretend the projectors are rooms.

It also has the pieces MRBS lacks around the edges: a REST API, resource groups, quotas per user, blackout periods, custom attributes, reservation reminders, and a reasonably usable admin UI. The API is the one worth calling out — if you want a Slack bot or a lobby display, LibreBooking gives you something to call.

The tradeoff is that generality costs you setup time. Because a room is just a resource, you configure the room-specific behaviour yourself rather than getting it out of the box.

Seatsurfing — if rooms and desks are the same project

Seatsurfing is GPL-3.0, written in Go with a React frontend, around 300 stars, and actively developed. It started as a desk-sharing product and now describes itself as covering desk sharing, room reservation and free seating.

The reason to consider it is that it's the most modern-feeling of the self-hostable options — floor plans you can click, a mobile app, SSO, and a deployment story built around containers rather than a PHP tarball. If your actual project is "we went hybrid, people need to book desks and the four meeting rooms," this is one product instead of two.

The reason to be careful is that rooms are the newer half of the feature set. If meeting rooms are your only problem, MRBS handles the room-specific details — capacity rules, equipment attributes, per-area approvals — with more depth.

Nextcloud, Exchange and Google — the option you might already own

Before installing anything: your groupware probably does this already, badly documented but working.

Nextcloud (AGPL-3.0) supports resource and room booking through its Calendar app. You define rooms as resources in the backend, and users add them to an event like an attendee — the room accepts or declines based on availability. It's basic. There is no approval workflow worth the name and no equipment inventory. But if you already run Nextcloud, it costs you an afternoon of configuration and zero new services to maintain.

Exchange and Google Workspace both have room resources with automatic accept/decline, capacity, and building/floor metadata. Neither is open source, but if you're already paying for them, adding a dedicated open-source room tool means running two systems that disagree about who has the room. That's usually worse than the imperfect thing you already have.

My honest advice: spend an hour testing your existing calendar's room resources before you spin up a new server. A surprising number of "we need room booking software" projects end there.

Side by side

Notice the last two rows. Every open-source room booking system is an internal tool. If you need to sell room hours to the public, you are not shopping in this category — you're shopping for booking software with a storefront and a payment processor.

The upkeep nobody quotes you

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

• Patching. PHP applications with authentication and a public URL are a standing obligation. Booked Scheduler had a publicly documented remote code execution vulnerability in 2.7.5. That's not an argument against the software; it's an argument for actually applying updates.
• Backups you have tested. A room booking database is small and boring right up to the morning it's gone and nobody knows who has which room.
• Auth integration. LDAP or SAML configuration is where most of these deployments actually stall. Budget a day, not an hour.
• The upgrade you postpone. Every one of these will eventually need a PHP major-version bump. Someone owns that. Decide who before you deploy, not after.

For an internal tool with fifty users, this is a few hours a quarter. It's real, and it's usually still cheaper than per-seat SaaS at that scale. Past a few hundred users, or once payments enter the picture, the maths changes.

When self-hosting is the wrong answer

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

You need to take money. Renting rehearsal rooms, treatment rooms or coworking space means payments, deposits, refunds, tax and invoices. None of these tools do that, and bolting Stripe onto MRBS is a bigger project than it sounds.

The people booking are customers, not staff. External users need a page that looks like your brand, works on a phone, and does not ask them to create an account on your PHP 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 entirely. You want scheduling as an API you call — availability computed server-side, bookings created over HTTP, payments handled. That's the case I built Opencals for, and it's the honest boundary of where these open-source tools stop.

I wrote about that decision in more depth here: open-source vs hosted booking API. And if you want the generic version of this comparison across all booking software rather than rooms specifically, that's open-source booking systems.

How to choose, in about an hour

The short version

Room booking is a solved problem in open source, as long as the rooms are yours and the people booking them work for you. MRBS and LibreBooking both do the job properly; Seatsurfing is the modern choice when desks are in scope too; and your existing calendar may already handle it well enough that installing anything is a step backwards.

The category genuinely stops at money. The moment a stranger needs to pay for a room, you have left the world of internal resource schedulers, and no amount of configuring MRBS gets you there. That's the case Opencals handles — a booking layer with availability, payments and a storefront you can point customers at, or an API and SDK if you're building the front end yourself. Pay-per-booking rather than per seat, which for room hire tends to matter.

If you're weighing it up, the pricing page is honest about the numbers, and you can get in touch if you want to talk through whether it fits.