Why GLPI high availability is harder than adding a second web server
Adding a second web server does not make GLPI highly available. GLPI keeps its working state in several places, and each one needs its own resilience decision before any load balancer is placed in front of the application. If staff depend on GLPI for incidents, changes and asset records, a single GLPI server is a business risk, and the first job is to list every place where that server holds state so that a failure in one place does not silently take the service down. The main places to examine are the database, the files directory (attached documents, uploads and generated content), the config directory containing glpi.key and glpicrypt.key, active sessions, scheduled tasks run by the cron mechanism, and the mail collectors that pull tickets from mailboxes. Each has different failure behavior. The database is the obvious one. The files directory and config directory must be present and consistent on every node that serves requests. Sessions decide whether a user is logged out when a request lands on another node. Scheduled tasks and mail collectors must run exactly once, not once per web node, or notifications and tickets will be duplicated or missed. The encryption keys deserve particular attention. glpi.key and glpicrypt.key protect data GLPI stores, so a replacement node that does not carry the same keys cannot read what the first node wrote. Confirm with your own environment how the config directory will be shared or replicated, who holds copies of the keys, and how they are backed up separately from the database. The same keys appear in the GLPI update procedure, so the high availability design and the upgrade runbook should use one agreed location. Before promising any multi-node layout to a business sponsor, check the current GLPI installation documentation for the version you plan to run. GLPI supports MySQL and MariaDB only, so a database clustering or replication design must be built on one of those engines and on the versions listed in the prerequisites for your release. Ask the implementation partner to document which combinations the vendor documentation covers and which ones would be a custom design that your team must own and test.
Placing two web nodes behind a load balancer requires the document root on each node to point to GLPI's public directory, with URL rewriting routing requests through index.php. That configuration must be identical on every node, and it should be checked during build rather than assumed from a single-server install. A mismatch in rewrite rules often appears only under specific URLs, so the test plan should include direct requests to GLPI pages, API paths and file downloads on each node before traffic is shifted. For the decision itself, write down five questions and answer each one in writing: which database topology is supported for your version, where the files and config directories live, how sessions are kept consistent across nodes, which single node runs scheduled tasks and mail collectors, and how a failed node is removed and rejoined. These answers drive effort more than the number of web servers does. A two-node web tier with shared state is a modest build, while a design where the database, files and sessions each need custom replication is a larger project with more ongoing maintenance. The last point is ownership. A highly available GLPI is a system with more moving parts, and each part needs a named owner for patching, backups and restore testing. Agree in the scope who will perform the database failover test, who restores the config directory and keys from backup, and who checks that the mail collector has not stopped. Those responsibilities should appear in the runbook before go-live, not after the first incident.
Which GLPI components need a resilience plan
A GLPI deployment is several layers that hold different state, and each one fails in a different way when a node is lost. Map every layer to what it stores and what stops working without it before choosing a topology, because a load-balanced web tier means little if sessions, uploads or encryption keys live on one machine.
Web server and PHP-FPM
The web server and PHP-FPM process run GLPI requests and should hold no unique state. The document root must point to GLPI's public directory with URL rewriting routing requests through index.php, so the same configuration must exist on every web node. If a node is lost, users on that node lose their connection, but another node can serve requests once the load balancer removes it. Check that each node runs the same PHP version and extensions, since GLPI 11.0 requires PHP 8.2 or later and the GLPI 12.0.0 prerequisites list PHP 8.3 or later.
Database server
The MariaDB or MySQL server holds tickets, assets, users, configuration and most of the business record, so it is usually the hardest layer to rebuild. Losing the primary stops all writes and logins, and a replica that lags behind can lose recent changes during failover. Confirm the minimum versions for your GLPI release, since GLPI 11.0 lists MariaDB 10.6 or MySQL 8.0 and the current main branch requires MariaDB 10.11 or MySQL 8.0. Decide who promotes a replica, how applications reconnect, and how you verify data after a switch.
Shared files directory
The files directory stores uploaded documents, attachments and generated files, and every web node must read and write the same copy. If it sits on local disk of one web node, documents uploaded through another node are missing, and links to them fail. Use a shared filesystem or network storage that every node mounts with the same permissions, and confirm the storage survives the loss of any single node. Include this path in backups and in restore tests, because the database alone does not hold the files.
Config directory and encryption keys
The config directory holds the database connection settings and the glpi.key and glpicrypt.key files that GLPI uses for encryption. These keys are not recreated automatically, so encrypted values in the database become unreadable if a node is rebuilt without the original keys. Store one authoritative copy, distribute it identically to every web node, restrict access to it, and back it up separately from the database. The GLPI update procedure also requires backing up these files before any upgrade.
Session storage
PHP sessions tell GLPI who is logged in, and their location decides whether a user survives a node failure. With default file-based sessions on local disk, a load balancer that moves a user to another node logs that user out, and the user must sign in again. Choose a shared session store that all web nodes use, or enable sticky sessions and accept that a node failure ends the sessions it held. Confirm how the session lifetime interacts with the load balancer timeout, and review GLPI 12 session controls before choosing.
Cron and scheduled task runner
GLPI runs scheduled tasks such as notifications, inventory cleanup, mail collection triggers and recurring rules through its cron mechanism. These tasks must run once, not once per web node, or notifications and automatic actions will duplicate or conflict. Designate a single host to run the scheduler, and define what happens to pending tasks if that host is lost. Check that the runner account has access to the GLPI configuration and that failed runs appear in logs you review.
Mail collectors and the load balancer
Mail collectors create tickets from incoming email, so a collector configured on several nodes can fetch the same message more than once or miss it when its node is down. Assign each collector to one node or to a dedicated runner and confirm how a failover restarts it. The external load balancer or reverse proxy is the entry point for all users, so its own redundancy, health checks, timeouts and forwarded headers determine whether GLPI appears available at all. Test both during failover drills rather than assuming the application tier covers them.
Which high availability pattern fits your service desk
This table compares four ways to arrange GLPI servers, from a single node with reliable backups to load-balanced web nodes sharing files and sessions. Read each row against your user count, tolerance for downtime and in-house skills, then weigh the ongoing operational work each pattern adds. Failover timing and recovery objectives must come from your own requirements and tests, not from this page.
| Pattern | When it fits | Operational cost it adds | What to confirm first |
|---|---|---|---|
| Single node with tested backups | Small service desk where a short outage is tolerable and the team has limited database or Linux administration skills | Backup jobs, restore tests and a documented rebuild procedure; recovery depends on how quickly a replacement server can be provisioned | Your recovery time and recovery point requirements, and whether a restore has been rehearsed on a separate host |
| Separated web and database servers | Growing user base where web load or database load is starting to compete for resources on one machine | Two hosts to patch, monitor and back up; network path and database credentials must be managed between tiers | Whether the database host is sized and monitored independently, and who owns firewall rules between tiers |
| Database replication with manual or tested promotion | Service desk that needs a standby database copy and has a team able to run replication and perform a documented promotion | Replication lag and error monitoring, regular promotion drills, and careful handling of GLPI configuration pointing at the correct primary after a switch | Supported MariaDB or MySQL replication setup for your chosen version, and the promotion steps your DBA will sign off |
| Load-balanced web nodes sharing files and sessions | Large or business-critical service desk with staff who need the application to stay reachable during a single web node failure | Every web node must run the same GLPI version and plugin set, shared file storage and session handling need design and monitoring, and cron and mail collector ownership must be assigned to one node | Whether your load balancer, shared storage and session store meet your team's operating standards, and who approves changes to each node |
How to build GLPI high availability in order
This sequence takes a single GLPI server apart into the database, shared files, session storage, web nodes and scheduled work that a highly available deployment needs. Each step ends with a check, so the team knows the layer works before the next one depends on it. The last step proves that backups restore and that the update procedure runs on this topology.
Confirm versions against release prerequisites
The platform engineer checks the GLPI release being deployed against the PHP, MariaDB and MySQL requirements in the official installation prerequisites, since the README and the installation docs do not always list the same minimums. The team records the chosen PHP, database and web server versions and confirms that each node will run the same versions. Done when a written version matrix is approved and every planned node reports matching versions.
Split the database onto its own server
The database administrator moves MariaDB or MySQL off the application host onto a dedicated server, then points GLPI at it over the network. The web team confirms that the database account is limited to the GLPI schema and the application hosts. Done when a GLPI page loads through the application host while the database listens only on the intended network interface and accepts connections from it.
Place shared files and keys on storage
The platform engineer moves the GLPI files directory and config directory onto shared storage that every web node can mount. Both glpi.key and glpicrypt.key must be byte-identical on every node, and only the web service account should be able to read them. Done when each node reads the same files, the key checksums match across nodes, and the config directory cannot be fetched through the web server.
Configure shared session storage and test
The platform engineer sets up session storage that all web nodes can reach, so a session created on one node is valid on another. The team checks the session settings against the documentation for the chosen GLPI and PHP versions before enabling them. Done when a tester logs in, the balancer is forced to route the next request to a different node, and the user stays signed in without a prompt to authenticate again.
Build the database replica and document promotion
The database administrator builds a replica of the primary MariaDB or MySQL server and confirms that replication stays current under normal application load. The team writes a promotion runbook covering who decides, how the replica is promoted, and how the GLPI database connection setting is changed on every web node. Done when a promotion has been rehearsed in a test environment and writes succeed on the promoted server.
Place identical web nodes behind a load balancer
The platform engineer builds two or more identical web nodes, each with the same PHP settings and a web server whose document root is GLPI's public directory with URL rewriting to index.php. The load balancer receives health checks that confirm each node serves GLPI correctly, not only that the port is open. Done when each node passes the health check, a request to the balancer reaches any node, and direct requests to GLPI paths outside the public directory fail.
Move scheduled tasks to one controlled runner
The platform engineer selects one node as the only runner for GLPI scheduled tasks and mail collectors, and disables those jobs on every other node. The team records which node is the runner so that failover of that role is a deliberate step, not an accident of which node is up. Done when the task log shows tasks and mail collection running on the designated runner only, and a test email arrives as a ticket once.
Rehearse restore and updates on a separate host
The operations team restores the database, files and config directory, including glpi.key and glpicrypt.key, onto a separate host and starts GLPI there. On that copy they run the update steps: back up the database, files and config, replace the application files, and run php bin/console db:update. Plugins are suspended after a new version is detected in GLPI 11.0, so the team reactivates and tests them afterward. Done when the restored instance matches the source, the update completes, and the rehearsal is written up as a runbook for the production topology.
Keeping cron jobs and mail collectors from running twice or not at all
Scheduled GLPI tasks and mail collectors cause more trouble in a multi-node setup than almost any other part of a high-availability design, because they must run on one node at a time. If two web nodes both run the cron-driven tasks, notifications, inventory processing and cleanup jobs can collide. If neither runs them after a failover, tickets sit unread, escalations stop firing and SLA timers drift without anyone noticing. Both failure modes need a deliberate decision before the load balancer goes live.
Two patterns are common. The first pins the task runner and the mail collector to a single designated node, with a written takeover step: who confirms the node is down, how the runner is started elsewhere, and how the team confirms it is not still running on the original node. This is simple to operate but depends on people following the runbook during an incident, so rehearse it. The second uses an external scheduler on a separate host that calls the GLPI console (bin/console) on one target at a time, so the schedule lives outside the web tier and survives a web node loss. Either way, the web nodes themselves should not each run the built-in cron behavior unchecked. Confirm in the official GLPI documentation for your exact version how cron execution, task locking and collector behavior are configured, because these details have changed between releases.
Mail collectors need the same care. Each collector reads a mailbox and creates tickets or followups, so two active collectors on the same mailbox can create duplicate tickets, and a collector that is silently disabled leaves the queue unread. Decide which node owns each collector, record the mailbox settings and the expected polling interval, and plan how messages that arrived during a failover are picked up. Ask your team to test this with a controlled message sent while the active node is stopped, then confirm that exactly one ticket appears once service returns.
Verification is where most teams fall short. Check the last successful run of each scheduled task in the GLPI administration screens, and compare it against the expected interval. Look at the queue of pending notifications and any backlog of unprocessed mail or inventory data. Set an alert on stale task runs and on collector errors, and include these checks in the failover test. Ask any partner quoting this work to show how they confirm last-run times, backlog size and duplicate prevention in a test, not only how the configuration is written.
Decisions to settle early: which node is the primary runner, who authorizes a takeover, how long the team tolerates a gap in task execution before escalating, and whether an external scheduler fits the hosting and access rules of your environment. Each choice affects the effort to build and operate the design, so document the chosen option and its failure behavior before the cutover.
What drives the effort and cost of a GLPI high availability design
This table lists the factors that move the effort and cost of a GLPI high availability design, how each one can be kept down, and whether its cost is one-time or recurring. Use it to see which decisions in your environment will make a quote larger, and which ones you can settle before asking for one.
| Driver | Why it changes effort or cost | How to keep it down | One-time or recurring |
|---|---|---|---|
| Database size and growth | Larger tickets, logs and inventory history lengthen replication setup, initial sync, backup windows and restore tests | Set a retention policy for logs and old inventory early, and size the restore test against the real database | One-time for setup, recurring for backup and restore checks |
| Number of users and entities | More entities and profiles add access rules to validate after failover and make restore verification broader | Keep the entity tree as simple as the business allows and test a representative set of profiles | One-time validation, recurring when entities change |
| Number of agents sending inventory | High agent counts raise load on the web nodes and the database during inventory peaks | Stagger GLPI Agent inventory schedules and confirm capacity on the load-balanced pair before go-live | One-time tuning, recurring if the fleet grows |
| Mail collector volume | Email collectors and notifications depend on one active cron and mail path, so failover needs a clear owner for each job | Run cron and collectors from one designated node, and document what happens to queued mail during a switch | One-time design, recurring monitoring |
| LDAP or external authentication | Directory reachability and bind accounts must survive a node or site change, which adds test cases | Use the same directory endpoints on every node and test logins from each web node | One-time configuration, recurring directory changes |
| Plugin count and compatibility | Each plugin must be checked on every node and against the target GLPI version, and some are suspended after updates | Limit plugins to those with a clear business need and keep a tested list of versions | One-time testing, recurring on each update |
| Storage platform availability | Shared files and session storage need a platform that already offers redundancy, or the design must add it | Reuse an existing shared storage service that the organization already monitors and backs up | One-time build, recurring capacity and maintenance |
| Network and load balancer ownership | If the client's network team owns the load balancer, change requests, health checks and failover tests need their time | Agree ownership, change windows and health check definitions in the written scope | One-time integration, recurring change requests |
| Compliance evidence needs | Assessors may ask for failover records, restore results and access logs, which adds collection and documentation work | Define the evidence list before build and have the restore test produce dated records | One-time evidence design, recurring evidence collection |
| Environments (test, staging, production) | Each environment needs its own nodes, replication and restore test, so the design is repeated or scaled down | Standardize node images and configuration so a staging copy mirrors production, and confirm which environments must be highly available | One-time build per environment, recurring patching of each |
Securing shared files, keys and sessions in a clustered GLPI
A load-balanced GLPI keeps several web nodes in step with one database and one set of files, so the same secrets, accounts and session data must be protected consistently on every node. The cards below cover the controls that connect those shared pieces and how to check each one on your own deployment.
Access control on shared files
In a clustered setup, the files directory and config directory are typically shared between web nodes, so every node reads and writes the same uploads, documents and configuration. Confirm that the shared storage grants write access only to the web service account, that ownership matches on every node, and that the GLPI document root points to the public directory on each server. Test by logging in to each node directly and confirming that a file path outside the public directory is not served.
Permissions on glpi.key and glpicrypt.key
GLPI uses glpi.key and glpicrypt.key to protect encrypted data, so every web node must hold identical copies or it will fail to decrypt stored values. Restrict both files to the web service account and keep them out of any path the web server can serve. Back them up together with the database, because losing either key makes encrypted content unreadable even after a successful database restore.
Key consistency across nodes
Adding a node is the most common point where keys drift, for example when a new server is built from an older image or a key is regenerated during a manual setup. Compare checksums of both key files across all nodes after each change, and record the checksum in your change log without storing the key material itself. Ask your DeployOpen or internal team to include this comparison in every node build and in the update runbook.
Least-privilege database accounts
Give web nodes a database account limited to the privileges GLPI needs for normal operation and updates, and keep administrative privileges with a separate account used only during installation and db:update. Replication requires its own account with replication privileges only, which should not be the application account. Confirm the grants with a query against each account and review them after every GLPI upgrade, since update procedures can change what the application requires.
TLS between the balancer and nodes
Traffic from users to the balancer is only part of the path, because the balancer also forwards session cookies, credentials and ticket content to each web node. Decide whether the segment between the balancer and the nodes uses TLS, which certificates each side trusts, and how renewals are rotated across nodes. Verify the setting by capturing traffic on the internal network during a login and confirming that no session identifier travels in clear text.
Session storage and sticky sessions
A user who logs in through one node must keep a valid session when the balancer routes the next request to another node, which requires either shared session storage or a deliberate affinity policy. Decide which approach your topology uses, document the session lifetime and expiry, and confirm that a node restart does not silently log out every user. Test by stopping one node during an active session and checking whether the user stays signed in.
Active session review and revocation in GLPI 12
The GLPI 12.0.0 release adds a view of active user sessions with the ability to revoke them, which matters when a laptop is lost or an account must be locked during an incident. Check whether the view lists sessions created through every node and whether a revocation takes effect on the balancer path, not just on the node where the administrator is signed in. Record a test revocation during acceptance so the procedure is proven before an incident.
Step-up authentication for administrative actions
GLPI 12.0.0 adds step-up authentication for certain administrative actions, so an administrator may be asked to confirm identity before a sensitive change. Identify which actions trigger the prompt in your version, confirm that the prompt works when the request reaches a different node from the one that issued the first login, and confirm how it interacts with your SSO or LDAP sign-in. Ask the vendor or check the release notes for the exact list of actions covered.
How to test that GLPI fails over safely
The test plan should prove that GLPI keeps serving users when one part of the stack fails, and that it returns to a consistent state afterward. Run five scenarios on a non-production copy of the production topology, each with a named owner and a written expected result. The first is node loss during an active session: stop one web node while a technician is editing a ticket, then confirm whether the session survives through the shared session storage. The second is loss of the database primary, followed by the promotion steps in the documented runbook. The third tests load balancer health checks, the fourth rehearses a failed update on a staging copy, and the fifth performs a full restore of the database, files and config directory to a separate host.
Write the pass criteria before anyone runs a test, so that a result cannot be reinterpreted afterward. For access, confirm that each authentication source in GLPI's lookup order (internal database, LDAP, IMAP, then external methods such as REMOTE_USER) still lets the expected users sign in, and that a disabled account stays blocked. For data, open a sample of tickets and confirm that their history, followups and attachments are present and readable. For scheduled work, confirm that cron-driven tasks and mail collectors resume exactly once after failover, because a duplicated collector can create duplicate tickets from the same mailbox. For secrets, confirm that stored values decrypt with the restored glpi.key and glpicrypt.key. A restore that lacks the matching keys leaves the data in place but unusable.
Recovery targets must be agreed by the business before testing begins. Ask the service owners how long the service may be unavailable and how much recent ticket data may be lost, then compare the test results against those answers. Without agreed targets, the same restore can be recorded as a pass by the operations team and a failure by the service desk. Confirm the figures with the business owners, record who approved them, and note the GLPI version under test, since behaviour can change between major releases such as the move from GLPI 11 to GLPI 12. The approved targets become the reference for every result in the plan.
Load balancer tests need a health check that reflects real application health. A check that only confirms the web server port is open will keep sending traffic to a node whose PHP process or database connection has failed. Check which probe types and intervals your load balancer supports, and confirm that the probe fails when the database is unreachable. During the database promotion test, verify that the application configuration points at the new primary, that writes succeed, and that the former primary is fenced so it cannot accept writes if it returns. Record the time each step takes so the promotion runbook can be checked against the approved targets.
The failed update rehearsal follows the documented procedure: back up the database, files and config directory, replace the application files, and run php bin/console db:update. Stop the update partway on purpose and practise restoring from the backup. In GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates, so include plugin status in the result. For the full restore, rebuild the document root on a separate host with the same PHP and MariaDB or MySQL versions, sign in as a test user, open a ticket and attach a file, then record the elapsed time against the agreed targets. Confirm the required PHP and database versions with the installation prerequisites for your GLPI release.
What to monitor, back up, document and upgrade after go-live
A highly available GLPI cluster only stays available if someone watches its parts, can restore it, and knows how to change it safely. The cards below cover the checks, backups, rehearsals and upgrade steps that keep web nodes, the database, shared files and scheduled work healthy after the project team hands over.
Web node health checks
Each web node behind the load balancer should be checked on its own, not only through the virtual address, because a failed node can hide behind a healthy pool. Check HTTP responses from the GLPI login page, PHP-FPM or Apache error rates, and whether each node reads the same configuration and session store. Confirm with your load balancer how health probes are defined and how quickly a failing node is removed from rotation.
Database replication lag and status
GLPI writes tickets, assets and sessions to one MariaDB or MySQL primary, so replica lag directly affects what users see after a change. Monitor replication thread status, seconds behind source, and replication errors on every replica. Agree in advance what lag GLPI can tolerate and who acts when a replica stops applying changes, and confirm how your failover tool handles the GLPI database.
Shared files volume capacity
Document attachments, inventory files, plugin data and generated files live on the shared files volume that every web node mounts. A full volume can break uploads and file access on all nodes at once. Track free space and inode use, set alerts well before the volume fills, and confirm who owns growth decisions for attachments and retention of old files.
Cron and mail collector run history
Scheduled tasks and mail collectors must run on exactly one designated node, or they run twice or not at all. Review the scheduled task history in GLPI for failures, runs that take longer than expected and tasks that stopped running. Check that the mail collector's mailbox connection is still valid and that the node running it has not changed without a configuration update.
Certificate expiry tracking
Certificates on the load balancer, on each web node, and for the database connection can expire independently, and an expired certificate on one component can take down the whole service path. Keep an inventory of every certificate, its issuer and its expiry date, and set reminders with enough lead time for your change process. Include certificates used by LDAP or IMAP authentication if GLPI connects to them over TLS.
Backups and scheduled restore rehearsals
A backup covers the database, the files volume and the config directory, including glpi.key and glpicrypt.key. Without the key files, encrypted values in the restored database cannot be read, so store copies of both keys separately from the data backups under controlled access. Schedule restore rehearsals on a non-production copy, record the time each step takes, and confirm that a restored instance logs in and finds its attachments.
Upgrade procedure for clustered nodes
Upgrades change the procedure because application files exist on every node. Back up first, replace the application files on every web node with the same release, then run php bin/console db:update once against the database. Since GLPI 11.0, plugins are suspended when a new version is detected, so plan to reactivate and test each plugin after the update. Rehearse this sequence on staging before each release.
Runbook and architecture record
The handover should include a runbook for routine tasks and failures, and an architecture record describing the nodes, the load balancer, replication topology, shared storage, scheduled task placement and key locations. Keep both under version control with dated revisions, and assign an owner who reviews them after each upgrade or topology change. Ask your partner which items are included in the handover and in what format.
Questions teams ask before building GLPI high availability
Can our own team build GLPI high availability in-house?
Yes, if your team already runs Linux web tiers, MariaDB or MySQL replication, shared storage and load balancers, and has time to test failover properly. The hard part is rarely the first install. It is the failure testing: what happens when a web node dies mid-session, when the primary database fails, or when the host running cron or mail collectors goes down. Teams often underestimate three areas: keeping uploaded files and sessions consistent across nodes, making sure only one node runs scheduled tasks and mail collectors, and proving that a restore works within the time your business expects. Start by writing down each component that can fail and what users should see when it does. If that list is hard to write, a fixed-scope design review before the build can reduce rework.
What drives the cost of a GLPI high availability build?
The main drivers are the number of web nodes, the database topology, your storage and load balancer choices, how many integrations (LDAP, mail, SSO, monitoring) must keep working during failover, and how much failover and restore testing you require. Costs fall into two groups. One-time work covers design, build, configuration, testing and documentation. Recurring costs cover the infrastructure you run, database and backup storage, monitoring, patching, plugin upgrades and support time. GLPI is distributed under GPL-3.0, so self-hosting carries no software license fee. DeployOpen does not publish a price list. Most engagements are fixed-scope, so ask for a quote that lists each phase, the environments it touches, the acceptance tests, and which items you provide. Also ask who pays for servers and database licenses, since those are billed by your cloud or data center provider.
How long does a GLPI high availability project take?
The duration depends on the scope agreed in writing, so no single timeline applies to every environment. The main drivers are the number of nodes and environments, whether database replication is new to your team, how many external systems must stay reachable during failover, the availability of change windows, and the number of failover and restore test rounds. Ask for a plan with phases and gates: design sign-off, staging build, failover tests, restore test, cutover and a post-cutover review. Each gate should name who approves it. Delays most often come from waiting on access, load balancer changes, certificates and change approvals, so request those dates early in the quote and confirm them with your own change board.
What does the work need from our infrastructure team?
Expect to provide access to the cloud accounts, hypervisors or data center network where the nodes will run, plus permission to create or change load balancer, DNS and firewall rules. You will also need shared storage for uploaded documents and generated files, a database platform or DBA time, mail relay and LDAP details, monitoring access, and a change window for cutover. Name an owner for each area: platform, network, database, identity and a business approver who accepts test results. Decide early who holds the encryption keys, glpi.key and glpicrypt.key, and where they are backed up, because a restore without them will fail. Without named owners, decisions stall at the first failover test, and that is the point where schedule slips usually start.
Does GLPI officially support a load-balanced, multi-node setup?
Confirm this in the official GLPI documentation for the exact release you will run before design approval. The installation documentation covers the document root, URL rewriting and supported web servers, and it lists MySQL and MariaDB as the only supported databases. Documentation for a multi-node layout should be checked against your release, because shared file handling, session storage, cron execution and mail collector behavior can change between versions. Ask the vendor which configuration it documents and tests. Record any design that depends on behavior the documentation does not describe as a risk, and get the acceptance of that risk in writing. DeployOpen plans, implements and documents the topology in your environment, but the vendor documentation for your release decides what GLPI itself supports.
Does a GLPI Network subscription change the high availability approach?
It can change who runs the platform, which changes the scope of the work. GLPI is maintained by Teclib', which also offers GLPI Network Cloud as a managed service with a 45-day free trial, according to the GLPI project site. GLPI Network public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum, according to the GLPI Network subscriptions page. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). A managed service may move hosting and parts of availability operations to the vendor. Before choosing, confirm in writing what the vendor covers for availability, backups, restores, plugins and support levels, and whether any self-hosted high availability design is still needed for your data residency or network rules.
What does support after go-live cover for GLPI high availability?
Support after go-live covers what is written in the agreed scope and any retainer. Ongoing support, upgrades and continuous testing are available as retainers, so check whether the retainer includes the web tier, database, shared storage, load balancer configuration, cron and mail collectors, and plugins. Updates are a common source of risk. The GLPI update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key, replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so build plugin checks into every change window. Confirm response times and restore test frequency in the written agreement before go-live.
Which PHP and database versions does GLPI high availability require?
Plan around the GLPI release you will run, then check its prerequisites against the documentation for that release. The GLPI README on the main branch lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later. The installation documentation for GLPI 11.0 lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. These lists differ, so confirm the exact versions for your release before ordering hardware or database licenses. According to the glpi-project/glpi releases page, GLPI 12.0.0 was released on October 7, 2026, and 11.0.11 on October 1, 2026. Keep every web node on the same PHP version, use a supported database engine, and test php bin/console db:update on a staging copy before any production change.
How DeployOpen scopes, builds and hands over GLPI high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so GLPI high availability runs in your cloud account, data center or air-gapped network. The work starts with a written, fixed scope that defines which components are made resilient and how each one is verified before go-live.
How we scope
- Map current GLPI web, database, file, cron and mail collector dependencies on your existing servers or virtual machines.
- Agree in writing which tiers, failover behavior and recovery targets the engagement covers, and which items stay out of scope.
- Confirm the PHP and MariaDB or MySQL versions your target GLPI release requires, checking current GLPI prerequisites before committing.
How we build
- Separate the web and database tiers, then configure replication with the database engine version your environment supports.
- Deploy load-balanced web nodes with shared files and sessions, with the document root set to GLPI's public directory.
- Make cron and mail collector runs reliable across nodes, so only one node executes scheduled tasks and email collection at a time.
How we hand over
- Document the topology, configuration, failover runbooks and the location of glpi.key and glpicrypt.key for your operators.
- Run restore tests from backups of the database, files and configuration directory, and record the results against the agreed scope.
- Deliver the verification report and walk your administrators through failover tests so they can repeat them without us.
How we support
- Agree in writing what post-go-live support covers, including patching, failover drills and upgrade planning for later GLPI releases.
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants a standing partner after handover.
- Confirm with your team who owns the backup schedule, monitoring and on-call response before the engagement closes.
