GLPI 12 is still under development, but it is already possible to follow some of the changes being worked on in the official repository.
We are not talking only about a new interface or visual changes. The project is going through an important modernization of its structure, mainly in the frontend, in the organization of components, and in the reduction of old dependencies.
Since there is no stable version yet, everything presented in this content should be treated as an analysis of the current state of development. Features, requirements, and even technical decisions may still change.
Interface modernization
One of the main changes underway is in the GLPI frontend.
Today, the system still has components built at different moments of the project. Some areas use traditional PHP pages, while others already use Twig, modern JavaScript, and Vue.js.
In GLPI 12, the tendency is to expand this modernization and further standardize the interface.
Among the work we have already been able to observe are:
greater use of Vue.js;
gradual replacement of old components;
reduced dependency on jQuery;
modernization of selectors;
review of upload components;
standardization of fields and forms;
navigation improvements;
migration of the build process to Vite.
Vite should make the development and maintenance of frontend components easier. For the end user, however, the main gain should be a more consistent interface with more standardized behaviors.
Even so, this migration is under development and should not be considered complete until the stable version is published.
A more standardized interface
Anyone who has administered GLPI for a while knows that some modules have different behaviors from one another.
This happens because parts of the interface were created at different times and using different technologies.
GLPI 12 should reduce this problem through component reuse.
This can bring improvements in areas such as:
entity selection;
hierarchical trees;
form fields;
attachments;
menus;
filters;
validation messages;
selection boxes;
editors;
searches.
In practice, the system tends to become more predictable for users and simpler to maintain for those who develop plugins or integrations.
Knowledge Base
The Knowledge Base is also going through changes.
The work involves the content editor, file management, navigation between articles, and information organization.
This is an important area for companies that use GLPI not only for tickets, but also as:
a base of procedures;
an internal documentation portal;
a self-service center;
a repository of solutions;
support for service teams.
Since the feature is still being tested, there are pending adjustments related to the interface, translations, performance, and category behavior.
Therefore, it is not yet possible to state exactly how the Knowledge Base will be delivered in the final version.
Custom Assets
Custom Assets were one of the main new features of GLPI 11.
This feature allows creating new asset types without needing to directly change the GLPI source code.
A company can use this feature to control, for example:
industrial machines;
medical equipment;
vehicles;
furniture;
tools;
laboratory equipment;
any other object specific to the operation.
In GLPI 12, the expectation is that these assets will become increasingly integrated with the rest of the platform.
Among the points that need to keep evolving are:
searches;
permissions;
relationships;
entities;
history logs;
forms;
rules;
the API;
imports.
This evolution is important because it allows using GLPI beyond the traditional inventory of computers, monitors, printers, and network equipment.
Internal modernization
Not all changes will be visible on screen.
An important part of the GLPI 12 work is happening in the internal structure of the system.
Among the points observed are:
refactoring of the PHP code;
reduction of legacy code;
greater use of Twig templates;
creation of reusable components;
replacement of old libraries;
improvements in automated tests;
frontend review;
improvements in the translation system;
API evolution;
compatibility with more recent PHP versions;
review of compatibility with supported databases.
This type of change does not usually draw as much attention as a new screen, but it is essential to keep the project sustainable.
The lower the dependency on old code, the easier it becomes to fix problems, implement new features, and keep plugins compatible.
The current GLPI technical documentation already shows this transition to a more modular architecture, based on controllers, templates, APIs, and modern components.
APIs and integrations
Another point that needs to be followed closely is the evolution of the APIs.
Today, many environments use GLPI integrated with:
HR systems;
ERPs;
monitoring tools;
BI solutions;
Active Directory and LDAP;
automation platforms;
n8n;
in-house systems;
external portals;
inventory solutions.
A major version change can alter endpoints, permissions, fields, or return formats.
Therefore, anyone with critical integrations needs to test mainly:
authentication;
ticket creation and updates;
asset reading;
searches;
document uploads;
relationships between objects;
API user permissions;
endpoint responses.
It is not safe to assume that an integration that works in GLPI 11 will continue to work the same way in GLPI 12 without validation.
Security
Security continues to be worked on within the project.
There are already discussions and implementations related to additional controls for sensitive operations, permission reviews, and re-authentication for certain actions.
Even so, it is important not to wait for GLPI 12 to keep the environment secure.
Security fixes continue to be published in the GLPI 11 maintenance releases. Therefore, production environments must remain up to date.
The basic recommendations also still apply:
do not modify the core;
keep plugins up to date;
remove abandoned plugins;
review permissions;
protect configuration files;
use HTTPS;
keep PHP and the database up to date;
run automatic actions correctly;
review API users;
keep backups of the database and files.
Plugin compatibility
This will probably be one of the main points of attention during the migration.
A new major version can change classes, methods, hooks, JavaScript components, templates, and structures used by plugins.
Before updating, it will be necessary to validate:
whether the plugin has a compatible version;
whether the project is still maintained;
which PHP versions are supported;
whether there are database changes;
whether there were changes to the hooks;
whether the plugin's frontend still works;
whether the permissions are still correct;
whether the automatic actions work;
whether there is an official migration process.
Abandoned plugins, or plugins that directly alter the core's behavior, represent a higher risk.
Anyone with many installed plugins should start testing before the stable version is released.
Core customizations
If the environment has changes made directly to GLPI files, the upgrade will be more complicated.
These changes can be overwritten during the upgrade or simply stop working.
Ideally, customizations should be made using:
plugins;
APIs;
webhooks;
external integrations;
official customization features.
Before testing GLPI 12, it is important to survey all existing changes in the environment.
This includes:
modified PHP files;
altered templates;
custom CSS;
custom JavaScript;
manual database changes;
triggers;
views;
integrations;
in-house plugins.
Without this survey, it becomes difficult to distinguish a GLPI problem from a problem caused by an old customization.
Can GLPI 12 already be used in production?
No.
The current version should be used only in a lab environment.
It can be used to:
get to know the new interface;
test plugins;
validate integrations;
analyze technical changes;
check for possible incompatibilities;
test service flows;
prepare the team for the migration.
Since it is still under development, the following may occur:
errors;
regressions;
database changes;
incomplete features;
interface changes;
plugin incompatibilities;
translation issues;
changes without prior notice.
We also do not recommend connecting a development version directly to the production database.
Testing should be done with an isolated copy of the database and files.
We are tracking and testing GLPI 12
At Nextools and JMBA Soluções, we are already tracking GLPI 12's development and running tests with the available versions.
Our goal is to identify impacts in advance in:
plugins;
integrations;
the database;
infrastructure;
authentication;
APIs;
customizations;
the upgrade process.
To make these tests easier, we have made available a Docker image with the development version of GLPI 12.
To download it:
docker pull jmbasolucoes/glpi:12-dev
The image is intended exclusively for testing.
It should not be used in production.
With it, you can quickly spin up an environment to:
evaluate the interface;
test plugins;
validate LDAP and SSO;
test integrations;
analyze the inventory;
review forms;
check rules;
identify incompatibilities.
Before testing an upgrade, always use a copy of the environment.
Do not connect this image to the production database.
Docker environment example
Below is a simple example for spinning up GLPI 12 with a dedicated lab database:
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
To start it:
docker compose up -d
Then, access:
http://localhost:8080
This compose file is just a lab example and should be adjusted according to the environment.
How to prepare for GLPI 12
It is not necessary to wait for the stable version to start preparing.
The first step is to organize the current environment.
Update GLPI 11
Before thinking about GLPI 12, keep GLPI 11 up to date.
Migrating from an old version increases the number of changes and makes it harder to identify problems.
Take inventory of your plugins
List all installed plugins and record:
version;
developer;
purpose;
criticality;
maintenance status;
dependencies;
compatibility.
An installed but unused plugin should be removed.
Document your integrations
Record:
endpoint;
authentication method;
user used;
fields sent;
fields received;
frequency;
dependencies;
error handling.
Create a staging environment
The test environment should reproduce production as closely as possible:
PHP;
database;
plugins;
configurations;
authentication;
rules;
notifications;
cron;
integrations.
Create a validation checklist
It is not enough to just open GLPI and check whether the screen loaded.
It is necessary to test the main processes:
ticket creation;
assignment rules;
SLA;
notifications;
forms;
approvals;
tasks;
inventory;
LDAP;
SSO;
automatic actions;
the API;
reports;
dashboards;
permissions;
entities.
What we really expect from GLPI 12
From what we have been able to observe so far, GLPI 12 will not be just a version change.
The project is preparing a more modern foundation for the years ahead.
The main points are:
frontend modernization;
greater use of Vue.js;
reduction of old dependencies;
interface standardization;
evolution of Custom Assets;
improvements to the Knowledge Base;
API review;
internal security improvements;
simpler code maintenance;
a better structure for future features.
It is not yet possible to state which features will be in the first stable version.
Nor is it possible to guarantee that everything that appears today in development will be delivered exactly the same way.
Right now is the time to follow along, test, and identify impacts.
Those with a simple environment will likely have a smoother migration process.
Those with many plugins, integrations, and custom changes need to start validation early.
To start testing:
docker pull jmbasolucoes/glpi:12-devIn upcoming content, we will share the tests we are running, the differences compared to GLPI 11, and the problems found during this preparation.
Are you already testing GLPI 12? Tell us what worked, what broke, and what changes you found.
Notice: this content reflects the development state of GLPI 12 as of July 2026. Since this is not yet a stable version, features, requirements, structure, and behavior may change.
