GLPI architecture for large inventories and many users

GLPI architecture for large inventories and many users: when one server stops being enough

When thousands of GLPI Agents report in while staff work tickets and asset screens on the same instance, the design question is how to separate inventory ingestion from user-facing work. The right layout depends on load you have measured, not on a headcount rule of thumb. Start by measuring where the time goes: agent check-in volume, inventory processing, database query latency and the response times staff actually feel during peak hours. GLPI describes itself in its README as an open-source IT service management platform covering tickets, assets, CMDB, contracts, financial management and data center infrastructure, distributed under the GNU General Public License version 3. That breadth is why one instance often carries both heavy machine reporting and interactive ticket work. The official requirements apply to every node you add: the README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later for the current line, while the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm which set matches your target release before you build a second front end, because a mismatch on one node breaks the whole pool.

Every additional node, whether an inventory front end, a user front end or a database server, must run the same supported PHP and database combination for the release you choose. Confirm the exact versions for your GLPI line in the GLPI installation prerequisites and record them in your design document. Also confirm with Teclib' or your integrator how the instances share the database, configuration keys and file storage before you split roles, since the update procedure depends on those shared secrets being identical across nodes. The practical output of this section is a short sizing record: agent count and check-in interval, peak concurrent staff sessions, current database and web server utilization, and the response targets for ticket and asset screens. With those numbers, you can decide which role to split first and which components need a second node. Teams that skip this step often add a load balancer before they know whether the bottleneck is inventory processing or database contention.

Which layout fits which estate

A few hundred agents reporting to one support team usually run well on a small footprint, and the first tier to separate is the database. Keep the web server, PHP and GLPI on one application host, move MariaDB or MySQL to its own server, and keep the files directory on local disk while only one application node serves users. Teams at this size seldom need a load balancer, but they do need a tested restore of the database, the files directory and the config directory, including glpi.key and glpicrypt.key.

Single application node: web server, PHP and GLPI share one host, with the scheduled tasks driven by cron.
Dedicated database host: separating it early keeps inventory writes from competing with page rendering.
Local files directory: shared storage adds work without adding capacity while one node serves users.
Version-matched stack: confirm the PHP and database versions against the prerequisites for your chosen GLPI release before the first install.
Restore testing: run a restore into a separate environment, not just a backup job that reports success.

Before you add a second application node, check the inventory processing time, the database growth trend and any backlog of agent check-ins across a full reporting cycle.

Architecture options and when each fits

This table compares the main architecture options for a GLPI instance serving many agents and users, from a single server to a load-balanced pool. Read each row as a step you add only when a measured bottleneck or an operational requirement justifies it. The main takeaway is that every split adds components to patch, back up and monitor, so confirm the sizing with your own load tests before committing.

Option	What it solves	What it adds to operate	What to confirm
Single server	Simplest install with web, PHP and database on one host; fine for early pilots and small estates	One patch cycle and one failure domain; inventory uploads compete with interactive users for CPU and disk	Peak agent check-in rate and whether web and database contention appears under your load
Split inventory and user front ends	Separates high-volume agent inventory traffic from browser users so slow inventory processing does not degrade ticket work	Two web entry points with the same GLPI code and configuration; routing rules and version parity must be kept aligned	How agents are pointed at the inventory endpoint and how your GLPI version and config directory are kept identical on both
Dedicated database server	Moves MySQL or MariaDB off the web hosts so disk, memory and buffer pool are tuned for GLPI alone	A network hop on every query, database backups and restores as a separate runbook, and a new privileged access path to secure	Supported MySQL or MariaDB version for your GLPI release and latency from web hosts to the database
NFS shared files	Gives every web node the same files directory, so uploads and documents are visible from any front end	NFS export permissions, UID mapping, locking behavior and a single point of failure unless the storage is itself redundant	Whether Teclib or your GLPI release documents NFS as supported for the files directory and how locking is tested
Load balancer with session handling	Distributes browser traffic across user front ends and removes a single web entry point	Health checks, TLS termination, sticky or shared session strategy, and cache coordination across nodes	Session storage method for your version, cache backend choice for multi-server installs and how the balancer treats agent endpoints
Read replicas and shared cache	Offloads reporting and search reads and shares cache state across nodes	Replication lag monitoring, stale-result risk for reads sent to replicas, and an extra cache service to run	Which GLPI features read from replicas in your version and the cache backend Teclib recommends for multi-server installs
Backup and upgrade coordination	Keeps database, files and config directory restorable as one consistent set across all nodes	Upgrades must stop or drain every node, and plugins are suspended after a new version is detected in GLPI 11	Backup order, key file handling for glpi.key and glpicrypt.key, and a rollback test on a copy of production

How to plan and build a multi-node GLPI layout

This sequence moves a single GLPI instance into a multi-node layout with a dedicated database host, shared files, identical web nodes and a load balancer, with a check at each step so the team knows the layout works before users depend on it.

Baseline load and agent count
Before choosing any topology, record how many agents report in, how often they send inventory, how many named users sign in at peak, how many assets and tickets exist, and how large the database and files directory are today. Pull these figures from your current GLPI instance and from your agent or inventory server logs. The output is a short written profile that the architecture decisions reference. Done when the team can state the peak concurrent user count and the agent check-in rate from measured data rather than estimates, and the profile is signed off by the platform owner.
Confirm supported PHP and database versions
Check the target GLPI release against the installation prerequisites for the PHP and MariaDB or MySQL versions it requires. The current README and the installation docs differ for GLPI 11.0 and later, so confirm the exact versions in the release notes and documentation for the release you plan to run. Also confirm that only MySQL and MariaDB are supported for the database. Record the chosen PHP, database and web server versions on every node. Done when every node in the plan has a version matrix that matches the target release and no component is planned on an unsupported version.
Place the database on its own host
Build a dedicated database server, separate from every web node, and load the current GLPI database into it. Configure a database user that only the web nodes can reach, restrict network access to those nodes, and tune the server for the working set you measured in the baseline. Confirm that web-to-database latency is low on the network you chose, because every page depends on it. Done when a web node can connect with the GLPI credentials, the existing data loads without errors, and a test query returns the expected asset and user counts.
Set up shared storage for files
Create a shared file location, commonly an NFS export, that holds the GLPI files directory and any other directories GLPI writes to at runtime. Mount it on every web node at the same path. Set ownership and permissions so the web server user can read and write, and keep the configuration directory and its key files (glpi.key and glpicrypt.key) identical across nodes. Store the key files securely and back them up, because losing them breaks access to encrypted data. Done when a file written on one node appears on all others, the web server user can create and delete test files on each node, and the key files match byte for byte across nodes.
Deploy identical web nodes
Build two or more web nodes from the same configuration. On each node, install the same PHP extensions and web server, point the virtual host or server block at GLPI's public directory rather than the installation root, and enable URL rewriting so requests route through index.php. Mount the shared files location and point GLPI's configuration at the database host. Confirm that the same plugins are installed on every node with the same versions. Done when each node serves the login page from its own hostname or internal address, direct requests to other paths are blocked, and the GLPI system status page reports matching versions on all nodes.
Configure the load balancer
Place a load balancer in front of the web nodes and define a health check that calls a lightweight GLPI page on each node. Decide how sessions will be kept consistent, either through sticky sessions or through a shared session and cache backend, and confirm which option matches your cache design. Configure TLS termination and the forwarded headers GLPI needs to build correct URLs. Done when the health check marks a stopped node as down, traffic reaches the remaining nodes, and a login made through the balancer persists across requests.
Verify cron, sessions and plugins on every node
Confirm that scheduled tasks run once, not once per node, because duplicate runs can send duplicate notifications or repeat automatic actions. Choose one node or a separate scheduler to run GLPI's cron tasks and disable the others, then check the task queue. Test a session across a node change and a logout from one node. Activate a test plugin, then confirm it behaves the same on each node after a version change. Done when scheduled tasks show a single runner, sessions survive a node switch as designed, and plugin status matches across all nodes.

Failure modes that appear only at scale

A single GLPI server hides several problems that surface once inventory agents, technicians and reports share the same instance across several nodes. Each card below names one failure, the symptom it produces and the design response that prevents it. Check them in the order you would build the platform, because the shared file store, session handling and database layout decide how the others behave.

Shared file locking on NFS

When the files directory sits on NFS and several web nodes write to it at once, uploads, generated documents and inventory artifacts can collide or appear late on some nodes. Users see missing attachments or errors that come and go. Test write and lock behavior under concurrent load before go-live, not only a single-user upload. Confirm the NFS export options, the client mount settings and the latency between web nodes and the storage server, and keep GLPI's file directory outside the source tree so it can be moved without touching application code.

Sessions broken by round-robin balancing

A plain round-robin balancer sends each request to a different web node, so a user who signs in on one node can be logged out or see errors on the next request. Symptoms include repeated login prompts and CSRF-style failures on forms. Use session affinity or a shared session store, and check that the load balancer passes the session cookie unchanged. Also confirm that the session cookie settings match your HTTPS termination point, since a mismatch causes the same symptom on a single node.

Stale reads from database replicas

Routing reports, searches or list views to a read replica helps the primary database, but a replica that lags behind shows older tickets and asset changes. A technician updates an asset, reloads the page, and sees the previous value. Decide per screen which reads may be stale, and keep writes and the views that confirm a user's own change on the primary. Set a replication lag limit you can explain to the business, and test the fallback path that returns to the primary when the replica falls behind.

Cache inconsistency between nodes

If each web node keeps its own local cache, one node can serve configuration, dropdown values or rights that another node has already changed. The symptom is a setting that appears saved on one node and missing on another. Point all nodes at one shared cache backend such as Redis or Memcached, and plan a cache clear as a standard step after every configuration change and upgrade. Confirm the cache configuration is identical on every node before you put the cluster behind the balancer.

Upgrade order across nodes

Every node runs the same application code, but a rolling update that brings one node forward before the database schema is updated can send requests to code that expects a different schema. Plugins also need attention, because GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. Take a full backup, upgrade the database once through the console, then move all nodes together or drain them one at a time with the schema change already applied. Write this sequence into your runbook and rehearse it on a copy.

A single database as a hidden bottleneck

Web nodes, agent inventory submissions, search and reporting can all funnel into one database server, so latency grows slowly and then fails during peak inventory windows. Teams often notice only when the web tier looks healthy. Monitor database connections, query latency and disk I/O as separate signals from the web nodes, and size the database host for the inventory peak, not the daily average. Ask for the connection limit and buffer settings in your own environment, and keep the database on a dedicated host so its resources do not compete with web processes.

Questions teams ask before sizing a large GLPI estate

How much effort does a multi-node GLPI build take, and what drives it?

The effort depends mostly on how many separate roles the build has, how many agents report in, and how much of the environment is new to the team. A design with a separate inventory front end, a user front end, a dedicated database server, shared file storage and a load balancer has more moving parts than a single server, and each part needs its own configuration, access rules and tests. Ask any partner to break the estimate into design, build, data migration, testing and handover, and to state the number of nodes, the agent count and the number of integrations in the written scope. Those three inputs move the effort more than anything else.

Can our own team run a large GLPI architecture without a partner?

Often yes, if the team already runs PHP web applications, MySQL or MariaDB, and Linux load balancing. The gaps usually appear in shared file storage, session handling across nodes, cache configuration and the upgrade sequence. Before deciding, check whether you have engineers who can own the database server, the NFS layer and the web tier, and whether they have time for a planned build and a test upgrade. Teams that lack one of these skills often bring in a partner for the design and the first build, then keep the work in-house.

What does the work need from our side before the build starts?

Plan to provide an inventory of the agents that will report in, including device counts by site and platform, plus current network diagrams that show firewalls, VLANs and routes between the web tier, the database and the agents. You will also need a database administrator who can review the replication and backup design, and an identity contact for the sign-in model. Ask for a list of every system that GLPI must reach, such as directory services, mail servers and monitoring. Missing network detail is one of the most common reasons a build schedule slips.

How do upgrades change when the estate has more nodes?

Each node runs the same application code, so every node must move to the new version in a controlled order, and the database update runs once. The official update procedure requires a backup of the database, the files and the config directory, including the glpi.key and glpicrypt.key files, before the application files are replaced and php bin/console db:update runs. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so plan time to test each plugin. Ask for a written upgrade runbook that covers drain and return of nodes behind the load balancer, rollback and a test on a copy of production data.

What recurs after go-live, and what is one-time?

The build itself is one-time work, but several items recur: operating system and PHP patches, database maintenance, backups and restore tests, certificate renewal, plugin updates and GLPI release upgrades. Agent deployment also continues as devices are added or replaced. GLPI's own scheduled tasks and notification queues need monitoring. Ask any partner to separate the one-time build fee from the recurring support, and to say which tasks your team keeps and which are included in a retainer.

What should a GLPI quote contain before we compare vendors?

A quote should follow from a written scope and list the node roles, the agent count, the database design, the file storage approach, the load balancer, the identity integration, the data migration, the test plan and the handover. It should name the deliverables, the assumptions about your environment and the items you must provide. Ask which parts are fixed scope and which are time-and-materials, and what happens if the agent count or the network design changes. For context on licensing, Teclib publishes subscription prices for its managed GLPI Network service, including self-hosted plans from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), but those plans are a separate choice from a self-hosted build and do not replace the design work.

Which choices change the cost most in a large GLPI estate?

The biggest cost drivers are the number of web nodes, the database topology, the shared file design and the amount of integration work. A dedicated database server with replicas adds hardware, backup and tuning work, while a shared file layer adds storage access and permission design. Each integration with directory services, monitoring or mail adds testing and support. Ask for options with different node counts and compare the recurring costs as well as the build cost, since a simpler design may cost less to run even if the build looks more expensive.

What to confirm before you commit to a design

Start by collecting real load data before you choose a topology. Count the agents that will report in, the assets they will create or update, the named users who will sign in, and how many of them work in the ticket front end at the same time. Pull inventory submission volumes from the existing tool or from a pilot group, and record peak hours, not averages, because inventory runs often cluster at shift changes and scheduled task windows. Ask the GLPI Agent rollout owner which collection schedule and network discovery jobs will run, since those decide the write pattern on the database. Without these numbers, any split between inventory and user front ends is a guess.

Agree the sizing method in writing before procurement. The statement of work should name the target agent count, asset count, concurrent user count, expected growth over the planning period, and the acceptance tests that prove the design meets them, such as a load run against the inventory endpoint and a timed search across the full asset base. Confirm who owns the database server, the shared file store, the load balancer and the cache, and who is paid for each. Ask the partner to show how the design scales when one tier needs more capacity, so that adding nodes does not require a rebuild.

Check the GLPI release you target against current requirements before you fix the design. The GLPI 12.0.0 release was published on October 7, 2026, and GLPI 11.0.11 on October 1, 2026, so confirm which line your organization will run and whether plugins you need support it. Compare the PHP and database versions in the README with the GLPI 11.0 installation prerequisites, because the two sources differ, and confirm the supported MySQL or MariaDB version with the vendor before you size the database server. The GLPI installation prerequisites page is the next read for that check. Once the release is fixed, the sibling topics on SQL read replicas, cache configuration with Redis or Memcached, and Nginx or Apache layout will each need the same confirmed inputs.

GLPI architecture for large inventories and many users