GLPI: the GPL-3.0 asset and service desk stack, and what it costs to run

What GLPI actually replaces in an IT department

The name expands to Gestionnaire Libre de Parc Informatique. The README frames the package around SACM: computers, peripherals, network printers and their components, held in a configuration database that inventory agents keep current. Around that core it lists request fulfilment, incident and problem management, change management, a knowledge base with FAQ support, contract management, financial management for IT services, asset reservation, DCIM, software and licence management, impact analysis, a service catalogue with SLM, entity separation, project management and intervention planning.

That list is the honest description of the project and also the main warning about it. GLPI is not a focused ticketing tool with an asset tab. It is a general IT management application where the ticket queue is one module among many, and the data model behind it is shared: a ticket can point at an asset, an asset at a contract, a contract at a supplier, a supplier at a financial record. Teams that want only a queue will spend their time hiding modules they never asked for. Teams that already keep those relationships in spreadsheets are the intended audience, because the entity separation feature lets one installation serve several organisational units with distinct visibility rules rather than one database per department.

The architecture: PHP application, MariaDB schema, inventory agents

GLPI is a PHP web application served by Apache, Nginx or IIS, with MariaDB 10.6 or MySQL 8.0 as the datastore. The repository layout reflects that: src/ and inc/ hold the PHP classes, front/ and ajax/ hold the entry points the browser hits, install/ holds the installer, config/ holds configuration, and public/ holds the web-exposed assets. locales/ and the .tx/ directory carry translations, and marketplace/ is the client side of the plugin marketplace.

A second process feeds the database. The README states that native dynamic inventory arrived in version 10, and it points to a separate GLPI Agent documentation site covering installation on Windows, Linux and Mac OS, configuration and execution. The agent collects hardware and software data and submits it; the PHP side reconciles it against existing records. That is where the required PHP extensions come from. curl is listed for access to remote resources such as inventory agents and the marketplace API, zlib for compressed communication with agents, openssl for encrypted communication with agents and OAuth 2.0 authentication, and bcmath for QR code generation. None of those are incidental: strip curl or openssl out of the PHP build and the inventory path stops working, not just a cosmetic feature.

The front end is a conventional server-rendered application with a sizeable JavaScript dependency set rather than a single-page framework. package.json lists Tabler for the UI, jQuery with jquery-migrate, FullCalendar for scheduling, ECharts for dashboards, Cytoscape with dagre and grid-guide extensions for graph rendering, Leaflet for maps, and gridstack for dashboard layout. Node 20.9 or newer is required by the package manifest. Build tooling runs through webpack, and the presence of eslint.config.mjs, stylelint, phpstan, psalm and rector configuration files indicates the project enforces static analysis and coding standards on contributions.

Installing GLPI and taking a first ticket

The README does not give install commands. It points at the releases page for tarball packages and at the administrator documentation for install and update, command line tools, timezones and advanced configuration. So the production path is: satisfy the prerequisites, unpack a release tarball, and run the installer under install/. The prerequisites are a web server, MariaDB 10.6 or MySQL 8.0 or newer, PHP 8.2 or newer, and the mandatory extensions dom, fileinfo, filter, libxml, simplexml, xmlreader, xmlwriter, bcmath, curl, gd, intl, mbstring, mysqli, openssl and zlib. Suggested extras are bz2, phar and zip for marketplace packages, exif for image validation, ldap for remote directory authentication, and Zend OPcache for performance.

The repository also ships a Docker Compose stack, but the Makefile states plainly that it is for local development only and that production or deployment should follow GLPI's documentation. If you want to look at the application before committing to a real install, that stack is the fastest route. It builds an application container on PHP 8.4, runs MariaDB 11.8, and adds Mailpit for mail capture and dbgate for browsing the database.

docker compose up -d

The app service publishes 8080 to the container's port 80, so the web interface is at http://localhost:8080. Mailpit's interface is on 8025, and dbgate is on 9000. The database service is reachable inside the Compose network as db with user glpi and password glpi, which is why you should not expose this stack beyond your own machine.

The Makefile wraps the same stack. Its install target chains init-override, build, up, vendor, db-install and test-db-install, so a full first run is one command:

make install

For anything beyond that, the Makefile routes through the application container. Console commands run as the web user, and the file notes a helper for creating a preconfigured LDAP object in GLPI:

make console c='tools:generate_dev_ldap'

Once you are logged in, the first useful action is not a ticket. Create an entity that matches your organisation, then add one asset manually and one user, then open a ticket against that asset. Doing it in that order shows you the linking behaviour that the rest of the application depends on.

Where GLPI gets awkward

The prerequisite list is the first real constraint. PHP 8.2 or newer with fourteen mandatory extensions is not a shared-hosting target. If your only deployment option is a cheap host running an older PHP, GLPI is the wrong tool and no amount of configuration will change that.

The second constraint is scope. The README lists sixteen feature areas. Each one carries schema, permissions and interface surface, and upgrades touch all of them. The repository's default branch is 11.0/bugfixes, and the release list shows three maintained lines at once: 12.0.0-rc2, 11.0.9 and 10.0.27, all dated 2026-09-16. That is a healthy maintenance picture, but it also means a version choice has to be made deliberately. Running the 12.0 release candidate in production is a decision the project itself signals by labelling it rc2.

The third constraint is the plugin ecosystem. The README says GLPI supports many plugins and links to plugins.glpi-project.org. Plugins are where a lot of real functionality lives, and a plugin that has not been updated for your branch is a hard blocker on upgrade. Nothing in the project documentation describes an automated compatibility check, so the practical check is manual: list your plugins, then confirm each has a release for the branch you intend to run.

Finally, the Docker stack is a development environment. It ships known credentials, publishes a database administration UI on port 9000 and a mail catcher on 8025, and the Makefile says so. Treating it as a production deployment would be a mistake the repository explicitly warns against.

GLPI compared with a ticket-only service desk

The clearest alternative is a dedicated helpdesk that does ticketing and nothing else. The difference is in the data model, not the feature list. A ticket-only tool stores tickets and the people who raise them. GLPI stores tickets alongside a configuration item database, so a ticket can be attached to a specific computer, that computer to a contract, that contract to a supplier and a financial record, and the impact analysis module can then reason about what a change to that computer affects.

If your team already has an asset register somewhere else, that is a second system of record and you will either duplicate data or integrate. GLPI's answer is the inventory agent path: the agent reports, GLPI reconciles, and the register stays current without manual entry. If you do not want to run agents, you are back to manual asset entry, and at that point the advantage over a simpler helpdesk narrows considerably.

There is also a licensing difference worth naming. GLPI is GPL-3.0. A proprietary helpdesk gives you a vendor to escalate to and a support contract. GLPI gives you the source, a plugin marketplace, and documentation split across four separate sites for administrators, users, developers and the agent. Support exists as a commercial offering, and the README points to glpi-network.cloud for a free personal demonstration, but the code itself comes with no obligation on anyone to fix your installation.

Licence, upgrades and the cost of staying current

GLPI is distributed under GPL-3.0, and package.json records the JavaScript side as GPL-3.0-or-later. For most internal deployments this is unremarkable: you can run it, modify it and keep your modifications to yourself as long as you are not distributing the modified work. The obligation appears if you redistribute GLPI or a derivative to third parties, at which point source availability and the same licence terms travel with it. Plugins may carry their own terms, and the project documentation does not describe them, so check each one before you build a process around it. This is a description of what the licence files say, not legal advice.

Upgrade cost is the recurring expense. Three release lines are maintained in parallel, which means there is a supported path forward, but the application's breadth is what makes an upgrade a project rather than a patch. Schema changes, permission changes and interface changes all land at once, and plugins have to follow. The repository provides the tooling to check your own work (phpstan, psalm, rector, php-cs-fixer and a PHPUnit configuration are all present at the top level), but that tooling serves contributors, not operators. For operators the cost is a staging copy, a database backup, and a plugin compatibility pass before each move.

Editorial conclusion

Adopt GLPI if you need one GPL-3.0 system to hold an asset CMDB, a ticket queue and licence records, and you have someone who can keep PHP, MariaDB and the plugin tree current. Do not adopt it if you only need a helpdesk, because the asset, contract, financial and DCIM modules are most of the application and most of the upgrade surface. Before committing, verify three things on a staging copy: that your PHP build carries bcmath, curl, gd, intl, mbstring, mysqli, openssl and zlib, that your database server is MariaDB 10.6 or MySQL 8.0 or newer, and that every plugin you depend on has a release matching the branch you plan to run.

Frequently asked questions

Official sources

1. glpi-project/glpi on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases