QloApps: a hotel PMS, booking engine, and site on one PHP install

Three products share one installation

QloApps is described as one kind of a true open-source hotel reservation system and a booking engine, and the pitch is aimed at everyone from small independent hotels to large chains. What sits inside that single codebase is three distinct products: a Property Management System, a Booking Engine, and a Hotel Website. You launch the site, showcase the property, and take and manage bookings from the same place, which is the operational argument for the whole project. The practical reading is that these are not three add-ons you evaluate separately. Adopting the booking engine means adopting the PMS, and the website inherits the same data model. A team that only wants the public facing booking page is taking on a property management system whether it planned to or not.

The server is checked before the install is allowed to continue

Installation is gated by a compatibility check rather than by a hopeful error later. The stated behaviour is that the system verifies compatibility during installation and will not move ahead if the server does not qualify, which is a better failure mode than a half-installed front office. The hosted requirements are a web server running Apache 1.3, Apache 2.x, Nginx or Microsoft IIS, PHP 8.2+ to 8.5, and MySQL 5.7+ to 8.4 with a database already created, plus SSH or FTP access obtained from the hosting provider. Nine PHP extensions are required: PDO_MySQL, cURL, OpenSSL, SOAP, GD, SimpleXML, DOM, Zip, and Phar. The versions are given as ranges with both ends, which tells you the ceiling is deliberate rather than an oversight.

The local server list names Windows packages only

The local configuration section says the supported operating systems are Windows, Mac, and Linux, and then lists three prepared packages: WampServer for Windows, Xampp for Windows and Mac, and EasyPHP for Windows. No local package is offered for Linux, so a developer on that platform is left to assemble the stack from the Apache, PHP, and MySQL versions above. That is a documentation gap rather than a technical one, and it is the kind that turns up in a team where the person setting up local environments is the one who is not on Windows. There is a second, quieter gap in the same section: allow_url_fopen does not appear in the local settings list at all, while the hosted list asks for it explicitly. A local environment copied from the hosted notes will differ from the local notes by one setting.

memory_limit 128M and max_execution_time 500 apply to both paths

Three PHP settings are named identically under hosted and local configurations: set memory_limit to 128M, upload_max_filesize to 16M, and max_execution_time to 500. The hosted list adds allow_url_fopen on, and adds an SSL certificate as a requirement if you plan to process payments internally rather than handing them to PayPal. The limit here is that these values are quoted as requirements with no explanation of what breaks when they are wrong. The compatibility check verifies the server can run the installer; it does not promise your PHP will hold 128M through a season of booking operations.

Three licences live in one tree, not one

The licensing paragraph is the one to read carefully before you build on this. QloApps Core is licensed under OSL-3.0, modules authored by Webkul carry their own applicable licence in a LICENSE.md kept inside their module root, and other modules are licensed under AFL-3.0. So a single installation can contain code under three different licences depending on which directory it came from, and the split is per module rather than per file. The project credits itself as crafted at Webkul, which explains why one group of modules is carved out separately. For anyone redistributing QloApps or offering it as a hosted product, the practical consequence is that you cannot answer a licence question with one name, and you have to check the module directories that ship the functionality you actually depend on.

Docker is a single pull, the rest of the install is a link

There are exactly two documented routes. The first is to download QloApps and follow the steps in the installation guide hosted at qloapps.com/install-qloapps/, which means the real procedure is not in the repository. The second is the Docker image, and it is one command:

docker pull webkul/qloapps_docker

Note the namespace: the image lives under the Webkul organisation on Docker Hub, not under QloApps. Beyond these two routes the README says nothing about configuration, and its own table of contents has no section for upgrades, migrations, backups, or a configuration reference, even though the tree contains webservice/, override/, themes/, translations/, cache/, log/, and upload/ directories that imply all of those concerns exist. The security contact is also simple: do not disclose vulnerabilities publicly and email [email protected], with a SECURITY.md in the tree.

The demo credentials are public and the last release is over a year old

Evaluation is offered through a shared instance at demo.qloapps.com with the username [email protected] and the password demodemo, printed openly in the documentation. That makes it easy to judge, and it also means anyone reading the same page is in the same account, so anything you create there is not private and should not hold real guest data. Version history is the other thing to weigh. Tags run v1.6.0 on 2023-04-17, v1.6.1 on 2024-10-10, and v1.7.0 on 2025-07-04, while the last push to the default branch, develop, is dated 2026-10-30. Commits have continued well past the newest tag, so the code you see at the head of develop is more than a year ahead of the last release you could point a production install at.

Editorial conclusion

QloApps is a reasonable fit for an independent property or small chain that wants a PMS, a public booking site, and a booking engine running from one codebase without a per-seat licence. It is a poor fit if you need a documented upgrade path, a configuration reference, or a first-party local install for Linux, because none of those appear in the project documentation. Before deploying, confirm your host meets the PHP, MySQL, and extension list, check that allow_url_fopen is on and that you have an SSL certificate if you self-process payments, decide whether you install from source or from the Docker image, and plan a backup and upgrade routine that the documentation will not give you.

Frequently asked questions

Official sources

1. License: OSL-3.0
2. Project website
3. Qloapps/QloApps on GitHub
4. README
5. Releases