GLPI

Review scope and evidence labels

This page is written as a technical technology profile, not as a copy of the official GLPI manual. It summarizes GLPI as an IT asset management, service desk, inventory and CMDB-oriented platform, and it separates official project capability from site-specific integration ideas.

Important evidence labels used below:

Official documentation — based on GLPI project documentation or official website material.
Source code — based on public GitHub repository or organization metadata.
Release metadata — based on public GitHub release metadata captured during review.
Author analysis — interpretation for architecture, governance, integration or operational risk context on this site.
Lab validation: not yet performed — a plausible use case that still needs controlled validation before it should be treated as operational evidence.

GitHub metadata is time-dependent. Values such as latest release, default branch, repository count and license metadata were captured on 1 August 2026 and should be deliberately rechecked during future reviews.

Technology snapshot

Field	Value
Category	IT asset management, IT service management, service desk and CMDB-oriented inventory
Application type	Web application
Deployment	Self-hosted or cloud-hosted, depending on operating model
Core backend	PHP, according to the main repository language metadata
Inventory	Native inventory model with GLPI Agent and related inventory components
Extensions	Plugins and plugin repositories
Integration surface	API, inventory protocol, plugins, webhooks or external integration workflows
Core repository	`glpi-project/glpi`
Core licence metadata	GPL-3.0 according to GitHub metadata captured on 1 August 2026
Reviewed core release	GLPI 11.0.8, published on 24 June 2026 according to GitHub release metadata
Agent release metadata	GLPI Agent 1.18, published on 23 June 2026 according to GitHub release metadata
Inventory plugin release metadata	GLPI Inventory plugin 1.6.8, published on 24 June 2026 according to GitHub release metadata
Review status	Public-source technical profile; local lab validation is not documented in this entry

What GLPI is

GLPI is an open-source platform for IT asset management, IT service management and service desk workflows. It can track assets, configurations, users, entities, tickets, requests, incidents, software, licences, contracts and operational relationships. Evidence: Official documentation; Source code.

GLPI should be understood as an operational system of record for ITAM/ITSM data, not merely as a ticket list. Its value comes from relationships between assets, users, locations, contracts, software, tickets, components and lifecycle state. Evidence: Author analysis.

Native inventory and the GLPI Agent make GLPI suitable for endpoint and infrastructure inventory workflows, but inventory data still requires reconciliation, governance and validation before it should be treated as authoritative asset truth. Evidence: Source code; Author analysis.

What GLPI is not

GLPI is not:

a network monitoring platform like NetXMS,
a SIEM,
an EDR,
a vulnerability scanner,
an automatically correct CMDB,
a compliance product by installation alone,
a substitute for ownership, lifecycle and governance decisions.

It can support governance, operational evidence, asset lifecycle and incident/service workflows, but compliance and operational correctness depend on process, data quality, access control, retention and auditability. Evidence: Author analysis.

Architecture

A typical GLPI deployment combines a core web application, a database, optional plugins, API or web clients, inventory agents and external integration services.

                     ┌───────────────────────┐
                     │ Users / Technicians   │
                     │ Web UI / API clients  │
                     └───────────┬───────────┘
                                 │
                     ┌───────────▼───────────┐
                     │      GLPI Core        │
                     │ ITAM / ITSM / CMDB    │
                     │ Rules / Workflows     │
                     └───────┬───────┬───────┘
                             │       │
                    ┌────────▼──┐ ┌──▼───────────┐
                    │ Database  │ │ Plugins      │
                    └───────────┘ └──────────────┘
                             ▲
                             │ Inventory protocol
                ┌────────────┴────────────┐
                │                         │
        ┌───────┴────────┐       ┌────────┴─────────┐
        │ GLPI Agents    │       │ SNMP / Discovery │
        │ Endpoints      │       │ Network devices  │
        └────────────────┘       └──────────────────┘

GLPI Core

GLPI Core is the main web application and business logic layer. It handles assets, tickets, users, profiles, entities, workflows, inventory processing and the user/API-facing application surface. Evidence: Source code; Official documentation.

Database

The database stores asset records, tickets, relationships, configuration, users, profiles, plugin data and operational history. It is not just a storage backend; it is a sensitive operational evidence store. Evidence: Author analysis.

GLPI Agent

GLPI Agent is a separate component for inventory and management tasks. It can run according to its own execution plan or under server-directed tasks, depending on configuration and deployment model. Evidence: Source code.

Inventory plugin and native inventory

GLPI Agent, GLPI native inventory and the GLPI Inventory plugin must be kept conceptually separate. The agent performs endpoint-side or network-side collection tasks. GLPI receives and reconciles inventory data. The Inventory plugin can manage additional inventory, discovery and task capabilities. Evidence: Source code; Author analysis.

Plugins

Plugins extend GLPI and can add major features. They also expand the attack surface, upgrade matrix and compatibility risk of an installation. Evidence: Source code; Author analysis.

GitHub repository registry

The official glpi-project GitHub organization described itself as the official GLPI Project organization and had 43 public repositories when reviewed on 1 August 2026. The pluginsGLPI organization described itself as the official GLPI Project Plugins organization and had 61 public repositories at the same review time. Evidence: Source code.

Repository	Classification	Purpose	Licence metadata captured	Review notes
`glpi-project/glpi`	Official upstream	Main GLPI application	GPL-3.0	Latest release metadata reviewed: 11.0.8, 24 June 2026
`glpi-project/glpi-agent`	Official upstream	Endpoint inventory and management agent	GPL-2.0	Latest release metadata reviewed: 1.18, 23 June 2026
`glpi-project/glpi-inventory-plugin`	Official upstream/plugin	Discovery, SNMP inventory and agent tasks	AGPL-3.0	Latest release metadata reviewed: 1.6.8, 24 June 2026
`glpi-project/doc`	Official upstream	Documentation sources	NOASSERTION/Other	Verify repository files before reusing documentation content
`glpi-project/docker-images`	Official upstream	Official Docker image build definitions	MIT	Review release cadence from repository history and image-publishing process
`glpi-project/roadmap`	Official upstream	Public roadmap	Not exposed through GitHub metadata at review time	Planning context only; not implementation evidence
`pluginsGLPI/*`	Official plugin organization	Official plugin ecosystem	Per repository	Review each plugin independently

Repository metadata policy

Repository metadata can change. The public Research page should avoid presenting stars, forks, open issues or latest commit timestamps as stable facts unless it also shows a capture date. Evidence: Author analysis.

Core GLPI data model

GLPI is not just a simple list of devices. Its model combines assets, people, organizations, service workflows, software, contracts and relationships.

Asset entities

Common asset-related concepts include:

Computer,
Monitor,
Printer,
Network Equipment,
Phone,
Peripheral,
Rack,
Enclosure,
PDU,
Software,
Licence,
Certificate,
Appliance,
Contract,
Supplier.

ITSM entities

Common ITSM-oriented concepts include:

Ticket,
Incident,
Request,
Problem,
Change,
Project,
Task,
Solution,
Knowledge base entry,
SLA,
OLA.

Organisational entities

Common organisational concepts include:

Entity,
Location,
Group,
User,
Profile,
Technician,
Manufacturer,
Model,
State.

The key integration challenge is not only creating records; it is preserving correct relationships, entity scope, lifecycle state, ownership and evidence. Evidence: Author analysis.

Database documentation and direct database access

GLPI has generated database documentation for versions and development branches. Generated diagrams are useful for understanding structure, but they should not be treated as an integration contract without validation. Evidence: Official documentation; Author analysis.

Important rule:

Integrations should not write directly to the GLPI database unless there is an exceptional, documented and controlled reason.

Preferred integration paths are:

supported application API,
native inventory protocol,
plugin extension points,
controlled integration workflows,
reversible and audited automation.

Direct database writes can bypass validation, hooks, permissions, audit trails, plugin logic and upgrade compatibility. Evidence: Author analysis.

GLPI Agent and inventory research

GLPI Agent should have its own deeper research page later. The main points for the GLPI overview are:

endpoint inventory is separate from server-side reconciliation,
agent execution plan and server-directed tasks must be understood before automation,
HTTPS and certificate validation matter,
local configuration and logs are part of operational support,
deployment can require packaging, GPO or another endpoint management method,
agent updates require a controlled rollout strategy,
inventory data may contain sensitive host, user, software and network information.

The distinction between GLPI Agent inventory, Inventory plugin tasks and GLPI server-side reconciliation must stay explicit in integration documentation. Evidence: Source code; Author analysis.

API and integration characteristics

A useful GLPI integration review should focus on operational properties, not only endpoint lists.

Question	Why it matters
Is the operation idempotent?	Prevents duplicate assets and repeated ticket creation
Is there a stable external identifier?	Enables reconciliation between monitoring and asset systems
How are conflicts handled?	Prevents non-deterministic updates
Is the write audited?	Supports governance and incident review
How does pagination work?	Prevents incomplete synchronization
What happens on partial failure?	Protects consistency
Can the operation be safely retried?	Enables reliable automation
How is entity context selected?	Prevents cross-entity data exposure
How are tokens and sessions rotated?	Reduces credential exposure risk

A production-grade integration should be designed around reconciliation and audit, not around blind creates and updates. Evidence: Author analysis.

Relationship with NetXMS

GLPI and NetXMS should be integrated, but their responsibilities must stay separate.

System	Authoritative responsibility
NetXMS	Discovery, monitoring, topology, metrics, events and alarms
GLPI	Asset lifecycle, ITAM, CMDB context, service desk and ticket lifecycle
SecurityPlatform or integration layer	Identity resolution, reconciliation, approval workflow, audit and evidence
Wazuh or security telemetry layer	Endpoint/security signals, where applicable

Discovery from NetXMS can produce useful candidates for GLPI, but discovery is not proof of asset ownership or authoritative identity. The integration layer should decide whether a candidate is ignored, proposed, updated or escalated for manual review. Evidence: Author analysis.

Candidate integration workflows

NetXMS object to GLPI asset candidate

NetXMS object
    ↓
Integration candidate discovery
    ↓
Identity and type resolution
    ↓
GLPI candidate lookup
    ↓
No-op / create proposal / update proposal
    ↓
Approved GLPI write

NetXMS alarm to GLPI ticket

NetXMS event or alarm
    ↓
Normalization
    ↓
Deduplication
    ↓
Severity and routing policy
    ↓
GLPI incident or request
    ↓
State synchronization decision

GLPI asset to NetXMS monitoring target

GLPI managed asset
    ↓
Eligibility policy
    ↓
Monitoring configuration proposal
    ↓
Approval
    ↓
NetXMS object creation or update

These workflows are design candidates, not production claims. Evidence: Author analysis; Lab validation: not yet performed.

Integration research status

The public page must not claim that site-specific automation is production-ready unless it is actually implemented, validated and deployed. The table below uses public research-status language rather than implementation promises.

Capability	Current status	Validation status	Production claim
Endpoint GLPI synchronization	Under evaluation	Lab validation required	No production claim
Non-endpoint typed candidate discovery	Design candidate	Architecture review only	No production claim
No-op persistence and audit evidence	Design candidate	Architecture review only	No production claim
Automatic NetworkEquipment creation	Not implemented	Not validated	No
Automatic Printer creation	Not implemented	Not validated	No
Alarm to ticket synchronization	Under evaluation	Lab validation required	No production claim
Bidirectional reconciliation	Not implemented	Not validated	No

Security and hardening

GLPI is security-sensitive because it stores infrastructure, people, software, contract and ticket context. A compromised GLPI installation can reveal a map of the environment and operational history.

Key hardening topics:

enforce strong authentication and least privilege,
separate roles through profiles and entities,
limit administrative and plugin-management rights,
protect API tokens and application credentials,
review agent trust boundaries,
treat inventory data as sensitive,
control file uploads and document access,
secure the database and backups,
review plugin provenance and compatibility,
patch core and plugins deliberately,
protect email notification channels,
enable and review audit logs,
restrict direct administrative exposure to the internet where possible,
use TLS and validate certificates for integrations.

Governance relevance

GLPI should not be described as making an organization compliant by itself. It can support selected governance and evidence processes when configured correctly.

Potential value areas:

asset inventory,
lifecycle state tracking,
contract and supplier context,
incident and request records,
service desk workflows,
software and license evidence,
user and entity relationships,
operational audit trails,
evidence for change, incident and asset-management processes.

GDPR relevance depends on whether tickets, assets, logs, users, documents or inventory records contain personal data or data that can identify employees, contractors, customers or locations. Retention, access control, exports and backups must be governed accordingly. Evidence: Author analysis.

Limitations and risks

CMDB data can become stale without ownership and review processes.
Inventory is not automatically proof of asset ownership.
Bad reconciliation can create duplicate assets.
Plugins increase attack surface and upgrade complexity.
API tokens and agent credentials are sensitive.
Direct database writes can bypass validation and audit.
Ticket creation does not prove incident resolution.
Service desk data may contain personal data.
Entity or profile misconfiguration can expose data.
Discovery does not prove business identity.
Automation without approval can pollute asset and ticket records.
Incomplete pagination or retry handling can silently miss records.

Strengths

Broad ITAM and ITSM scope.
Strong fit for asset lifecycle, inventory and service desk workflows.
Open-source core with official repositories and plugin ecosystem.
Agent-based inventory option.
Extensible through plugins and integrations.
Useful evidence layer for operational governance when configured carefully.
Natural complement to monitoring systems such as NetXMS.

Recommended next research pages

The main /research/glpi/ page should remain a readable technical profile. Deeper pages can follow later if the Research system is expanded beyond one slug per entry:

GLPI architecture,
core data model,
asset management,
service desk,
GLPI Agent,
inventory,
network inventory,
plugins,
GitHub repositories,
API and integrations,
database schema,
security,
hardening,
deployment,
backup and recovery,
upgrades,
limitations,
troubleshooting,
NetXMS and GLPI integration.

Further research directions

Future GLPI research should move from public-source profiling into controlled lab validation. The next useful step is a documented GLPI installation with repeatable notes on GLPI Agent deployment, inventory behaviour, API authentication, session handling, pagination and retry behaviour.

NetXMS-to-GLPI work should remain a separate integration research track until stable external identifiers, reconciliation rules and approval/audit workflows are validated. A dedicated flat Research entry such as netxms-glpi-integration can be added later once the workflow has implementation evidence.

Scientific literature entries intentionally preserve publication titles and selected bibliographic text in the language used by the original source where that helps readers match the entry to the linked record. Future bibliography work should add a curated English commentary layer without replacing canonical original-language titles.