# Open-source room booking and reservation systems in 2026 > MRBS, LibreBooking, Seatsurfing and Nextcloud compared for self-hosted room reservation, releases checked October 2026: licence, upkeep and the exit path. URL: https://opencals.com/blog/open-source-room-booking-system Author: Stanislav Tyshchenko Published: 2026-09-01 Updated: 2026-10-26 Categories: comparison 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. > **Key takeaway** > > Check your existing calendar's room resources first — Exchange, Google Workspace and Nextcloud all do this and most people don't know it. If that's not enough, **MRBS** is the right answer for meeting rooms specifically and **LibreBooking** if rooms are one resource type among several. Every option here is an internal tool: the moment you need to charge someone for a room, you've left this category. Opencals is not open source; only our Next.js templates and npm SDK are. ## 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. > **Rooms and desks are not the same product** > > If the actual problem is hot desking rather than meeting rooms, the shortlist is different and the floor-plan requirement changes everything: [open-source desk booking software](https://opencals.com/blog/open-source-desk-booking-software). ## MRBS is still the right answer for meeting rooms MRBS — Meeting Room Booking System — is PHP, GPL, maintained since the early 2000s, and still shipping: the latest release is 1.12.2, from 26 May 2026 (checked on SourceForge, 12 October 2026). For a project that old, a release this year 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. **Pros** - Purpose-built for meeting rooms — every concept maps directly - Twenty-plus years of edge cases already handled - GPL, PHP + MySQL/PostgreSQL, runs on almost any hosting - LDAP/SAML auth fits an existing corporate directory - Repeat bookings and approval workflows work properly **Cons** - Interface looks dated; unsuitable for external customers - No payments, no invoicing — never a commerce tool - Configuration lives largely in a config file, not a UI - PHP stack you patch yourself ## LibreBooking, when a room is one resource among several LibreBooking is the maintained continuation of Booked Scheduler: GPL-3.0, PHP, about 820 GitHub stars, and the busiest release schedule on this list right now. v6.0.0 landed on 1 October 2026, v6.1.0 two days later and v7.0.0 on 6 October (all checked 12 October). 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. One thing to know before you install the current version if you're coming from something older. v7.0.0 is a breaking release, and what it broke is the way in: the web-based migration from phpScheduleIt 1.2 is gone, and so are the Quartzy importer and the general import pages. The only importer left is ICS. If your old bookings live in phpScheduleIt or an early Booked install, upgrade through an older release first, or accept that history comes across as calendar files rather than as structured bookings. **Pros** - Rooms, equipment and vehicles under one permission model - REST API — displays, bots and integrations are buildable - Actively maintained, GPL-3.0, official Docker image - Quotas, blackout periods and approval rules properly modelled **Cons** - More configuration than MRBS for a pure meeting-room case - Aesthetically still an internal tool - No native payment handling ## Seatsurfing, only if desks are in scope too Seatsurfing is GPL-3.0, Go with a React frontend, about 320 stars, and it releases almost weekly (v1.134.0 came out on 8 October 2026). 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. If desks are the main problem and you mostly want it free, I've compared the [free hot desk booking options, self-hosted and hosted](https://opencals.com/blog/open-source-desk-booking-software#free-hot-desk-booking-software-where-each-free-tier-stops), including where each free tier stops. > **An adjacent tool people confuse with this** > > Rallly (AGPL-3.0, about 5,300 stars) surfaces in these searches, but it solves _finding a time everyone can meet_ — availability polls, like a self-hosted Doodle. It has no room inventory. Useful, adjacent, not a substitute. ## The comparison, and the row that decides it | | MRBS | LibreBooking | Seatsurfing | Nextcloud | | -------------------------- | ------- | ------------------ | ----------- | --------- | | Licence | GPL | GPL-3.0 | GPL-3.0 | AGPL-3.0 | | Stack | PHP | PHP | Go + React | PHP | | Built for rooms | true | Rooms as resources | Desks first | Basic | | Recurring bookings | true | true | true | true | | Approval workflow | true | true | Limited | false | | REST API | Limited | true | true | CalDAV | | Floor plans | false | false | true | false | | Payments | false | false | false | false | | Public-facing booking page | false | false | false | false | 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. ## Check the exit before the install Nobody plans to leave the room booking system they're installing, which is why it's worth spending ten minutes on it now. The question is simple: if this goes away in three years, what comes out? The answer differs more than you'd expect. MRBS reads and writes iCalendar, so a room's bookings can come out as a calendar file and go into almost anything. Nextcloud stores rooms as CalDAV resources, which is the most portable format of the four, because the bookings are calendar events from the start. LibreBooking has a REST API you can script an export against, and since v7 its only built-in importer is ICS, which tells you which format the project itself expects data to move in. With any of them, the thing that won't come across cleanly is the structure around the booking: approval history, custom attributes, quotas. Export a month of real bookings during your trial and open the file. If you can't, you've learned something important while it's still cheap. ## 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](https://opencals.com/developers) for, and it's the honest boundary of where the tools above stop rather than a knock against them. If you want to see what a customer-facing version looks like, the closest thing we've published is the [VOLT template](https://opencals.com/blog/templates/volt): it's a padel club site, but its court booking grid is a room-hire page in everything but name. Swap courts for rehearsal rooms or meeting rooms and the shape holds. The template is MIT licensed. Opencals behind it isn't open source, and the free Dev Store runs in test mode, so it won't take real payments until you move to a live store. The longer version of that decision: [open-source vs hosted booking API](https://opencals.com/blog/open-source-vs-hosted-booking-api). The wider category beyond rooms: [open-source booking systems](https://opencals.com/blog/open-source-booking-system). - [Open-source desk booking software](https://opencals.com/blog/open-source-desk-booking-software): Hot desking and floor plans — the adjacent comparison - [Open-source booking systems](https://opencals.com/blog/open-source-booking-system): The wider category: appointments, classes and services - [What a booking API is](https://opencals.com/blog/booking-api): If you're building rather than deploying - [What's open source at Opencals](https://opencals.com/open-source): MIT templates and the npm SDK — and what isn't ## Frequently asked questions ### What is the best open-source room booking system? For internal meeting rooms, MRBS — it has been built for exactly this job for over twenty years and is still maintained. If rooms are one resource type among several, LibreBooking is the better fit because it schedules any resource and exposes a REST API. If you also need hot desking, Seatsurfing covers both in one product. Before any of them, check whether your existing calendar already handles room resources. ### Is there an open-source alternative to Robin or Envoy? Not a feature-equivalent one. Robin and Envoy sell workplace analytics, occupancy sensors and hardware room displays alongside booking. Open-source projects cover the booking layer well and the analytics and hardware layers barely at all. If the sensors are why you're buying, self-hosting will not replace them. ### Can I use an open-source room booking system to rent rooms to the public? Technically yes, practically no. None of MRBS, LibreBooking, Seatsurfing or Nextcloud handles payments, deposits, refunds or invoices, and their interfaces are built for staff rather than customers. Renting rooms commercially is a booking-and-payments problem, not a room-inventory problem. ### Does Nextcloud have room booking? Yes, through resource booking in the Calendar app. You define rooms as resources and users invite them to events; the room accepts or declines based on availability. It is basic — no approval workflow, no equipment inventory — but if you already run Nextcloud it costs nothing extra to try, and it is the first thing worth testing. ### Is Opencals an open-source room booking system? No. Opencals is a hosted booking platform and API, priced per booking rather than per seat. Our Next.js booking templates and our npm SDK are MIT-licensed and genuinely open source, but the platform itself is not. If self-hosting the whole stack is a hard requirement, MRBS or LibreBooking are your answer. ### Is LibreBooking still maintained in 2026? Yes, very actively. As of 12 October 2026 it had about 820 GitHub stars and three major or minor releases in the first week of October alone: v6.0.0 on 1 October, v6.1.0 on 3 October and v7.0.0 on 6 October. v7 is a breaking release that removed the phpScheduleIt web migration and the Quartzy importer, leaving ICS as the only built-in import. ### How much maintenance does self-hosting actually take? For a small internal deployment, a few hours a quarter: security patches, a tested backup, and an occasional PHP or database upgrade. The cost that catches people out is not maintenance but setup — LDAP and SAML integration is where most of these projects stall, and it is worth doing first rather than last. 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](https://opencals.com/blog/booking-sdk) if you're building the front end yourself. [Pricing is public](https://opencals.com/pricing), it's per booking rather than per seat, and you can [get in touch](https://opencals.com/contact) if you want to work out whether the shape fits before committing to anything.