GLPI cache with Redis or Memcached

When a GLPI cache backend becomes a multi-server decision

A GLPI cache backend stores data that the application would otherwise rebuild on every request, so pages and lookups can be served faster from the cache. On a single web server, GLPI's default local cache is usually enough, because one server reads and writes its own entries. A shared Redis or Memcached cache becomes necessary when two or more web front ends serve the same GLPI instance, because each front end must see the same cached data and clear it at the same time. If your install sits behind a load balancer, treat the cache as a multi-server decision from the start.

Choosing the backend is an architecture decision, not a tuning tweak. A shared cache is a new stateful service with its own network path, access control, patching, monitoring and failure behavior. Decide where it runs, whether it needs a highly available layout, and what GLPI does when the cache is unreachable. Confirm in the GLPI documentation for your exact version whether a shared cache is required or recommended for your topology, and which backends the glpi:cache:configure command accepts. Do not size the cache from performance claims you have not measured in your own environment.

Before you commit, document your front-end count, the network latency between front ends and the cache host, and who will operate the cache after go-live. Plan a staging test that switches the backend and confirms all front ends behave consistently. Add a cache clearing step to your upgrade runbook, since cached data must not survive a version change. A quote for this work should list the cache deployment, the configuration changes on every front end, the test plan and the operating runbook, so you can compare it with the effort of running the cache yourself.

How the file, Redis and Memcached cache backends differ

On a single web server, the default file-based cache is usually the simplest option. The web server process and the cache share one host, so there is no extra network service to install, patch or monitor. The main work is confirming that the cache directory is writable by the web server user and sits outside any path the web server publishes.

Ownership: the platform team owns directory permissions and disk space, and no separate service needs its own patch cycle.
Shared state: nothing needs to be shared, because one host reads and writes its own cache.
Failure mode: a full disk or wrong permissions degrades caching quietly, so monitor both alongside the web server.
Upgrades: clear the cache after an upgrade so entries written by the previous version are not served.
Prerequisites: the GLPI installation prerequisites list the server requirements that apply to any backend choice.

Confirm in the GLPI documentation for your exact version where the file cache directory is set and how it is configured.

Cache configuration options and when each fits

This table compares the settings you face when running glpi:cache:configure, from backend type to the behavior GLPI should follow when the cache server is down. Read each row as a decision: the right answer depends on whether one server or several web and worker nodes share the cache. Confirm each prompt's exact wording and accepted values in your GLPI version's documentation before you script the setup.

Option	What it controls	When it fits	What to confirm
Backend type	Whether GLPI stores cache entries in Redis or Memcached	Redis fits teams that already run it or want one tool for cache and session data. Memcached fits a simple, dedicated cache tier.	Supported backends for your GLPI version, and which one your web and worker nodes can all reach
Server address and port	Where every GLPI node finds the cache service	Multi-server installs need one address that all front ends resolve to the same cache, not one cache per node	Network path and firewall rules from every GLPI node, and the port your cache service listens on
Authentication	Whether GLPI must present credentials to the cache server	Shared caches reachable from more than one network segment or host	Whether your cache version and GLPI's client support the credential method you run, and where the secret is stored
TLS	Whether traffic between GLPI and the cache is encrypted	Cache servers on networks that cross trust boundaries or hosted outside the application subnet	Whether the GLPI client supports TLS to your cache, and the certificate chain it must trust
Key prefix or namespace	A prefix added to every cache key GLPI writes	Several GLPI instances, test and production, or other applications sharing one cache server	The prefix format accepted by the prompt, and that each instance uses a unique value
Behavior when the cache is unavailable	How GLPI responds when it cannot reach the cache server	Teams that need the application to keep serving pages slowly rather than fail, or the reverse	The fallback behavior in the GLPI docs for your version, and how you will detect the outage through monitoring
Clearing caches after upgrades	Stale entries from the previous version that a shared backend still holds	Any multi-server install, because each node may cache different data until the shared store is cleared	The cache clear step in the upgrade procedure, and whether it must run once or on every node

Configuring GLPI cache with glpi:cache:configure

This sequence takes a GLPI installation from a cache service that is not yet reachable to a shared cache backend that every web node reads from the same settings. It ends with a check that GLPI loads cleanly on each node.

Deploy the cache service and restrict access
Install Redis or Memcached on a host or service endpoint that the GLPI web nodes can reach, and bind it to a private network interface rather than a public address. Enable authentication where your chosen version supports it, and limit inbound access to the GLPI web nodes with host firewall rules or security groups. Confirm the service starts on boot and record the address, port and any credentials in your secrets store. The step is done when the service runs, is reachable only from the intended private network, and the settings are documented for the next step. Redis Open Source runs on Linux and, on Windows, only through Docker, so confirm the host operating system before choosing the install method.
Confirm connectivity from every GLPI web node
From each GLPI web node, test a TCP connection to the cache host and port using a tool such as nc or a short PHP check run under the same user as the web server. Confirm the PHP extension that matches your chosen backend is loaded on every node, since a node missing the extension will fail even when the network path is open. Check that a rejected connection produces a clear error rather than a silent timeout. The step is done when every web node connects successfully and the extension check returns the same result on all of them. Ask your team to confirm the exact extension names for your GLPI version in the installation documentation.
Run glpi:cache:configure from the installation
From the GLPI installation directory on one web node, run the GLPI console command glpi:cache:configure and follow the prompts to select the backend, host, port and any authentication details. Use the same console user that owns the GLPI files so that the generated configuration can be written without changing file ownership later. Review the summary the command prints before accepting it. The step is done when the command reports that the cache configuration was written and the new settings appear in the GLPI configuration file. Keep a copy of the previous configuration so you can restore it if the change fails.
Verify the configuration on all nodes
Compare the cache configuration file on each GLPI web node against the one you wrote, checking the backend type, host, port and key prefix. Where the GLPI files sit on shared storage, confirm that each node reads the same file, and where they do not, confirm the file was copied with identical content. Run a read and write test against the cache from each node, such as a short PHP script or the cache test built into your GLPI administration tools, and record the result. The step is done when all nodes show identical settings and every node completes the read and write test. Any node that differs needs its file corrected before you continue.
Clear caches and check that GLPI loads
Clear the GLPI caches through the console or administration interface so that each node starts from the new backend, then load the login page and a few core screens such as the ticket list and asset search on every web node. Watch the GLPI logs in the files directory and the web server error log while you do this, looking for cache connection errors, warnings about unavailable keys or PHP fatal errors. Repeat a login from two different nodes to confirm sessions and cached data behave consistently. The step is done when all pages load without errors on every node and the logs show no cache connection failures. Keep the log excerpts with the change record in case the same checks are needed after an upgrade.

Securing the cache service and what it stores

A cache service sits between GLPI and its data, so its exposure matters as much as the database's. The cards below cover how to isolate the service, what authentication and encryption it can offer, and what GLPI may place in it. Confirm each point with your own installation before you go live.

Isolate the cache on a private network

Place Redis or Memcached on a network segment that only GLPI web and worker servers can reach. Neither service should be reachable from user networks, the internet or other tenants in a shared cloud account. Restrict the listening address and use host firewall or security group rules to allow only the GLPI servers on the service port. Check this from a host outside the allowed set, because a cache that answers from a user subnet is a direct path to whatever it holds.

Treat an open cache as an open door

An unauthenticated cache accepts any client that can reach its port. An attacker who connects can read stored values, overwrite them or flush the store, which can break sessions or force unexpected GLPI behavior. Do not expose the cache port on any interface that is not required. Ask your team to confirm that the cache refuses connections from outside the GLPI hosts during a scheduled port scan, not only in the configuration file.

Confirm authentication and TLS support

Check the authentication and transport options for the version you deploy. Redis can require a password and supports TLS in supported builds, and Memcached support for SASL and TLS depends on the build and version in use. Confirm which options your distribution provides, then configure GLPI's cache connection to match, including any credentials or certificate paths. If the product in your environment cannot encrypt traffic between hosts, keep the cache on a segment that carries no other traffic.

Map what GLPI writes to the cache

Cached data may include values tied to sessions or users, such as lookups, preferences, rights information or rendered content, depending on the GLPI version and plugins. Ask the GLPI administrator and your plugin vendors to list the cache keys and data classes in use, and check whether any contain personal data or authentication material. Treat the cache as holding sensitive records until that inventory is complete, and set your retention and access rules from it.

Confirm how encryption key files relate

GLPI stores configuration secrets and uses key files such as glpi.key and glpicrypt.key for encryption. Confirm with your GLPI team whether any cached value is encrypted with these keys, whether it is stored in clear text, and how a cache flush or key rotation affects existing entries. Back up the key files with the config directory as the update procedure requires, and keep them off the cache host so a compromised cache does not expose both the data and the keys together.

Limit access and review cache exposure

Restrict administrative commands on the cache to a small operations group, and log connections and configuration changes where the product supports it. Include the cache in your access review and in vulnerability scanning for the host. After each GLPI upgrade or plugin change, recheck the cache host's firewall rules and listening addresses, since defaults or package updates can reopen access. Record the owner of the cache service in your asset inventory.

Clearing caches after a GLPI upgrade

Clear the cache on every GLPI node after each upgrade, because a stale cache entry can keep serving values from the previous version even though the database and application files have changed. The GLPI update procedure in the installation docs has you replace the application files and run php bin/console db:update. Until that step and the cache clear both finish, one web node may run new code against cached data written by old code. Treat the cache flush as part of the upgrade runbook, not an optional tidy-up afterward.

The same procedure matters for plugins. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Reactivating a plugin on one node does not change what the other nodes have cached, so confirm the plugin state from the console or the administration interface after the flush, not only on the node you used. Keep the order fixed in your runbook: back up, replace files, run the database update, flush caches on every node, then reactivate plugins and verify each node serves the same version.

Confirm two things with your vendor documentation before you rely on a flush command. First, check whether FLUSHALL or FLUSHDB on Redis, or the equivalent Memcached operation, clears only the GLPI keys or the whole instance, since a shared Redis or Memcached server may also hold data for other applications. Second, check in the GLPI console what the cache clear action removes and whether it reaches the shared backend once for all nodes or must run per node. Test the procedure on a staging copy of the same topology, and record which node you cleared and when.

Limits to confirm before choosing Redis or Memcached

Each of these limits can change the cache choice for a multi-server GLPI install, from the license that governs the Redis build you pull to the platforms it runs on. Confirm them against your own environment and the GLPI version you plan to run before you commit to a backend.

Redis license depends on version

Redis 8.0 and later are available under a license of your choice among RSALv2, SSPLv1 and AGPLv3, and that choice has to be recorded in your own software review. Redis 7.4.x through 7.8.x carry the dual RSALv2 or SSPLv1 terms, which are not OSI-approved, while Redis 7.2.x and earlier remain under BSD-3-Clause. If your organization requires an OSI-approved license, pin the exact version and confirm its terms with your legal or procurement team before the cache is built.

Confirm the GLPI cache drivers

Redis and Memcached support depends on the GLPI version and its cache configuration, so do not assume a driver is available because the cache server is. Run glpi:cache:configure on the target version and confirm which backends it offers in your release. Test the chosen backend on a staging copy first, because a driver that works in one release may need different connection settings in the next.

Redis on Windows needs Docker

Redis Open Source runs natively on Linux, macOS and the BSD systems, but on Windows only through Docker. If your GLPI application servers run on Windows, plan a container host for Redis or choose a Linux cache host. Confirm that the container runtime, persistence settings and network path meet your operations standards before you rely on it for session or cache data.

Sentinel needs three instances

Redis Sentinel provides automatic failover by promoting a replica to master when the primary fails, but the Redis documentation says a robust deployment needs at least three Sentinel instances. Each Sentinel needs to run on separate infrastructure so that a single host failure does not remove the quorum. Plan the extra hosts, network paths and monitoring into your cost estimate, and confirm with GLPI how it reconnects after a failover.

Check the Redis build you install

Redis Open Source 8.x includes modules such as JSON, time series and the Redis Query Engine, and the Intel SVS-VAMANA optimizations are closed source and only usable under RSALv2. A GLPI cache does not need these features, so use a build that matches the cache workload and document which modules are loaded. Inspect the installed modules during your build review, not after go-live.

Plan for managed or self-managed service

Redis Software and Redis Cloud are commercial products from Redis Ltd. and are not open source, so choosing one changes both your license position and your support model. If the cache must stay inside your infrastructure under your control, confirm that the open-source build meets your availability goals with your own team. Ask any managed provider to state in writing which Redis version and license they run.

Questions teams ask before configuring GLPI cache

Do I need a cache backend on a single GLPI server?

Not always. A single GLPI server with one web and PHP front end can run without a shared cache, because the cache mainly exists to share state between several web or PHP nodes. The practical test is whether requests for the same instance land on different servers, or whether you plan to add a second front end later. If the answer is no, the default file-based setup is usually enough, and the cache decision can wait until the architecture changes. Confirm the current cache defaults and recommendations in the GLPI installation documentation for your release before you decide.

What drives the cost and effort of a Redis or Memcached setup?

The cost comes mostly from labor and from the number of environments that need the change. Cost components include the time to design the topology, build or allocate the cache host or cluster, configure GLPI through the console, test failover and clear caches during each upgrade. Recurring costs include patching the cache service, monitoring it and keeping its network rules current. Costs rise with the number of GLPI nodes, the need for high availability, and the number of environments such as test, staging and production. Ask any partner for a quote that lists each component separately.

How long does a cache rollout take?

Duration depends on the environment rather than on the cache product alone. The main drivers are how many GLPI web and PHP nodes must share the cache, whether the cache needs high availability, how much change control your organization requires, and whether a staging copy exists for testing. Teams with existing Redis or Memcached services and a staging environment usually move faster than teams that must provision new hosts and approve network changes. Ask for a timeline tied to a written scope, and confirm the approval steps that apply to your change process.

What must our team provide for a cache rollout?

Your team needs to provide the cache hosts or an approved place to run them, network rules that allow the GLPI nodes to reach the cache port, and administrative access to the GLPI console with rights to run the cache configuration command. You also need the current GLPI version, a staging copy of the instance for testing, and a named owner who can approve changes. If you use a managed Redis or Memcached service, confirm its access model, encryption options and support terms with the provider before you start.

Can our own team configure the GLPI cache without a partner?

Yes, if your team already runs Linux services, understands GLPI's console and has a tested rollback plan. The configuration itself is a short command-line task, but the work around it includes network access, service hardening, failover testing and cache clearing after upgrades. Teams without experience in those areas often benefit from an outside review of the design and the test plan, even when they do the build internally. Decide based on the skills you have in house and the risk of a cache outage during business hours.

Should we choose Redis or Memcached for GLPI?

Choose based on the features you need, the licensing terms you can accept, and the operating skills you already have. Redis offers persistence options and a broader feature set, and Redis Sentinel provides automatic failover when you are not using Redis Cluster. Memcached is a simpler in-memory cache. Before you pick Redis, read the licensing history carefully, because the terms changed across releases. Check the Redis licenses page for the version you plan to run, and confirm with GLPI's documentation which backend your release supports and how it is configured.

What should we check after a GLPI upgrade that involves the cache?

Clear the caches after the upgrade, then confirm that every web and PHP node serves the new version and reads the same backend. Teams often miss a node that still holds stale data, so check each front end. Also verify that the cache host still runs a supported version and that failover, if configured, behaves as tested. Record these steps in your upgrade runbook so the next release follows the same checks.

What to confirm with your own environment

Start by confirming which GLPI release you run and what its documented cache options are. The supplied facts list GLPI 11.0.11 and GLPI 12.0.0 as current releases, but the cache configuration commands and supported backends are the things to check against the documentation for your exact version, not against this page. Confirm whether glpi:cache:configure accepts Redis, Memcached or both for that release, and whether your installation method (Docker image, Ubuntu package or source tree) changes how the cache is wired in. Record the result in your change ticket so an upgrade does not silently change the backend.

Next, confirm the cache product and the license terms your organization accepts. Redis licensing changed across versions: the supplied facts say Redis 8.0 and later can be used under RSALv2, SSPLv1 or AGPLv3 at your choice, while Redis 7.4.x to 7.8.x carry the dual RSALv2 or SSPLv1 terms and Redis 7.2.x and earlier carry BSD-3-Clause. Pin the exact version your procurement and legal teams have reviewed. For Memcached, confirm the version and license with your own review, because this page does not cover its terms. Also confirm which Redis build you are allowed to run, since distributions and managed offerings may differ from the upstream project.

Then measure the network path between the GLPI web nodes, the database and the cache host. Latency and packet loss between nodes decide whether a cache helps or slows page loads, and firewall or security group rules often block the cache port in ways that only appear under load. Confirm the cache is reachable only from GLPI nodes and that TLS or network isolation meets your policy. Finally, agree in writing who owns backups and failover for the cache, whether a cache loss is acceptable (GLPI can rebuild cache contents, but sessions and locks may behave differently), and who applies security patches to the cache service and on what schedule. If you need high availability, confirm the topology with the Redis Sentinel documentation rather than assuming it.

How DeployOpen scopes and delivers GLPI cache work

DeployOpen plans and implements GLPI cache configuration with Redis or Memcached inside your own infrastructure, from the cache backend choice through to the upgrade runbook. Engagements are agreed in writing before work starts, so the cache design, test evidence and handover material are defined up front.

How we scope

We review your GLPI version, node count and whether the install runs on one server or several front ends.
The written scope names the cache backend, the glpi:cache:configure settings and the servers that will host Redis or Memcached.
The scope states who clears caches after upgrades, and which steps your team runs on each release.

How we build

We configure the cache backend in a staging copy of your GLPI instance and confirm every front end uses the same cache.
We test failure cases, such as cache service restarts and unreachable cache hosts, and record how GLPI behaves in each.
We write the cache upgrade procedure into the runbook, including the cache clearing step after each GLPI update.

How we hand over

You receive the final cache configuration, network paths, service access rules and the test results from staging.
We document the Redis or Memcached version, its update procedure and the owner of each cache host.
Your team walks through a live cache clearing and recovery drill before the engagement closes.

How we support

Ongoing support and upgrades for the cache layer are available as a retainer alongside your GLPI support.
Retainers can cover reviewing cache settings when you move to a new GLPI release or add a front end.
Continuous testing of the cache layer can be added to the retainer if your security team requires it.