Running GLPI in Docker with the official image: when containers fit
The official image fits a team that wants GLPI packaged as a container it builds, runs and upgrades inside infrastructure it controls. The GLPI 12.0.0 release, published October 7, 2026, lists an official Docker image among its distribution options, so the image is a supported way to deliver the application. The image runs the application only. Your team still owns the database, the storage for configuration and uploaded files, the TLS endpoint and the upgrade process. Before you commit, check the runtime requirements for your target release. The GLPI README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later. The installation docs for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and they state that only MySQL and MariaDB are supported. Confirm which PHP and database versions the image tag you plan to use actually ships, and confirm that your database service meets the same floor.
The quick start gets a working GLPI instance on one host, but it leaves most production decisions open. It usually does not separate the database onto a service with its own backups, and it does not settle where the glpi.key and glpicrypt.key files live. The installation docs require both keys to be backed up with the database and files before any update, and losing them can make stored secrets unreadable. Map those files to a persistent volume, record where each volume sits on the host, and test a restore into a second container. Also confirm how the image handles the web server, the document root and URL rewriting, because the docs require the public directory to be the served root. Ask the image maintainers for the variables and paths they document, and check them against the update procedure in the GLPI installation docs.
A container deployment fits best when your organization already runs a container host, has a managed database service and pins image tags through a change process. It fits less well if you need heavy web server changes or per-server tuning that the image does not expose. For a small team, a single Docker Compose stack with an external database may be enough. For many users or many inventory agents, plan the front ends, shared storage and database capacity together before you choose the layout. Whatever the size, write down the image tag you run, the PHP and database versions it targets, and the order of your backup and upgrade steps. Those records will matter when you move from one major line to the next, since GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates.
Which Docker deployment options fit which situation
This table compares three ways to run the official GLPI image: a single-host compose stack with a bundled database, a compose stack pointing at an external MySQL or MariaDB server, and a multi-host layout with separate database and shared storage. Read each row to see when the option fits, what it requires from you, and which responsibilities stay with your team. The main takeaway is that moving the database out of the stack shifts backup, patching and version duties onto infrastructure you must size and confirm yourself.
| Decision point | Single host with bundled database | External database server | Multi-host with shared storage |
|---|---|---|---|
| When it fits | Pilot, lab or small team with one administrator and a modest asset count | Production instance where a database team already runs MySQL or MariaDB | Many agents, many users or a requirement to separate web and database tiers |
| Database version | Confirm the bundled image meets the MySQL 8.0 or MariaDB 10.6 minimum for your GLPI release | Match the GLPI prerequisites for your target version, such as MariaDB 10.11 or MySQL 8.0 for GLPI 12 | Same database rules as the external option, checked on the server every web node connects to |
| Backup responsibility | Your team must dump the database and back up the files and config volumes on the same host | Database team owns database backups; you still back up files and config keys | Split backups across database, file store and every config location, with restore tests for each |
| Volume placement | Named or bind volumes on local disk of the single host | Local volumes for GLPI files and config, with the database on its own server | Shared storage for the files directory so every web container sees the same uploads |
| Keys and config | Keep glpi.key and glpicrypt.key in a persistent volume and back them up with the database | Keep key files on a persistent volume outside the container image | Keys must match across all nodes, stored in shared or synchronized config |
| Upgrades | Change the image tag, then run the database update command in the container | Back up the database first, then change the image tag and run the update | Roll nodes one at a time after confirming the database update succeeded once |
| What you still operate | Host patching, disk capacity, container restarts and the database itself | Network path, TLS, connection limits and account rights for the GLPI user | Load balancer, shared storage, session handling, cron or scheduled tasks and monitoring |
| Questions to confirm | Whether the bundled database version and storage meet your recovery targets | Which team owns restores and how long the database team needs for a restore request | Which shared storage product, latency and locking behavior your platform supports |
Setting up GLPI in Docker for production
This sequence takes a GLPI container stack from a chosen image tag to a running instance with a working web installer, persistent data and backed-up encryption keys. Each step closes with a check the operator can confirm before moving on.
Confirm the image tag and runtime versions
The platform engineer selects the GLPI image tag that matches the target release and reads the prerequisites for that release before writing any configuration. Check the PHP and database versions listed in the GLPI installation prerequisites for your release, since the README on the main branch and the installation docs do not list the same minimums for every version. Confirm that the official image you plan to use is among the distribution options for that release, and record the exact tag in your change record. Done means you have a written tag, a PHP version and a database engine and version that all appear in the official requirements for that release.
Prepare the database and its credentials
The database administrator creates a dedicated database and a GLPI application user with privileges limited to that database, and generates a long random password stored in your secrets manager. Use MySQL or MariaDB only, since GLPI supports no other engine, and confirm the server version against the step above. Keep the database on a network path reachable from the GLPI container but not from user networks. Done means a test login with the new account succeeds from the Docker host network and the account cannot read other schemas.
Define the compose file, variables and volumes
The platform engineer writes a compose file that pins the image tag, passes database connection values through environment variables sourced from a
.envfile or secrets, and mounts named volumes for the GLPI files directory, configuration and logs. Store the file outside any public web path and restrict its permissions, since it holds credentials. Confirm the exact variable names against the official image documentation for your tag before you rely on them. Done meansdocker compose configrenders the full file with no unresolved variables and every persistent path maps to a named volume.Start the stack and complete the web installer
The operator runs
docker compose up -d, checks that the GLPI container reports healthy, and opens the browser to complete the web installer against the database created earlier. The installer creates the schema and asks for the initial administrator setup, so change the default account passwords immediately after first login. Put the instance behind your TLS terminator before users reach it, because the installer and login pages carry credentials. Done means the installer finishes without errors and the administrator can log in over HTTPS.Verify logins, scheduled tasks and file persistence
The administrator tests logins for a standard user and a technician profile, then confirms that GLPI's automatic actions run by checking the task status screens in the console, since cron or an equivalent scheduler must trigger them from outside the GLPI web flow. Restart the container with
docker compose restart, then check that uploaded documents, sessions and the configured settings still exist. Done means both user logins work after the restart, scheduled actions show recent runs, and an uploaded test file is still readable.Back up the encryption keys and configuration
The operator copies the database, the files volume and the configuration directory, including the
glpi.keyandglpicrypt.keyfiles, to backup storage that is separate from the Docker host. The GLPI update documentation treats these keys as required for a working restore, and a restore without them can leave encrypted fields unreadable. Store the key copies with restricted access and record where they are kept. Done means a restore test on a separate host brings up GLPI and decrypts a stored credential field.
Production settings beyond the quick start
The official quick start gets GLPI running, but it leaves the decisions that matter in production to you. The six items below cover how traffic reaches the container, where secrets and logs live, and which paths stay reachable. Confirm each one against the GLPI installation and security documentation for the exact version you deploy.
TLS termination in front of the container
Decide where HTTPS ends. Many teams terminate TLS at a load balancer or reverse proxy and forward plain HTTP to the GLPI container, which keeps certificate renewal out of the image. Whichever path you choose, session cookies must be marked secure and the public URL must be HTTPS, or sign-in and redirects break. Confirm the cookie and HTTPS settings for your GLPI version before you go live.
Reverse proxy headers and document root
GLPI must be served from its public directory with URL rewriting routing requests through index.php. When a proxy sits in front of the container, confirm that forwarded protocol and host headers reach GLPI, otherwise generated links and redirects point to the wrong scheme. Test direct requests to other application paths through the proxy to confirm they are not reachable.
Secrets kept out of compose files
Database passwords and any values that protect GLPI's encryption keys should not sit in plain text in a compose file committed to version control. Use Docker secrets, an external vault, or an environment file with restricted permissions. Also back up glpi.key and glpicrypt.key separately from the database, because losing them can make stored encrypted data unreadable after a restore.
Resource limits for the container
Set memory and CPU limits on the GLPI container so a busy inventory run or a runaway scheduled task cannot starve the host. Size the limits from observed load during testing, not from the minimums in the requirements. Keep the database on its own sizing plan, since it usually needs more memory than the PHP container. Confirm supported PHP and database versions for your GLPI release first.
Log collection from the container
Container logs are lost when a container is replaced unless you collect them. Send Apache or PHP-FPM output and GLPI's own log files to your central logging platform, and write GLPI's log directory to a persistent volume if the image is configured that way. Review which events GLPI records for authentication and administrative actions, and confirm the log locations for your image version.
Restricting exposed endpoints
Only the user-facing web port and the paths users need should be reachable from outside. Block direct access to the database port, to the container's internal management interfaces, and to status or installation pages that reveal version information. Apply the same rule to the inventory endpoint that agents use, and allow it only from the networks where agents report. Verify the rules with an external scan after each change.
Upgrading GLPI by image tag without losing data
An upgrade in a Docker deployment means changing the image tag in your compose file to the new GLPI version, recreating the container, and then running the database update step so GLPI migrates its schema to match the new code. Do not change the tag until you have a complete backup. The GLPI update procedure in the installation docs requires three things saved first: the database, the application files, and the config directory, which holds glpi.key and glpicrypt.key. Those two key files decrypt stored secrets, so a restored database without them cannot read passwords and tokens it previously saved. In a container setup, the persistent volumes for the files directory and config must be included in that backup, along with a database dump taken from the database container or its volume.
Plugins need separate attention. Since GLPI 11.0, plugins are suspended after GLPI detects a new version, so the instance may look healthy while plugin features are switched off. After a major update, you must reactivate each plugin deliberately and confirm that its data and forms still work. Inventory the active plugins and their versions before the upgrade, and confirm with each plugin's publisher that a build exists for the target GLPI version. Plan this as a test step in a staging copy rather than a surprise on production day.
Check the release notes before you move between major versions. GLPI 11.0.0 was released on October 1, 2025, and GLPI 12.0.0 on October 7, 2026, while 11.0.11 followed on October 1, 2026, according to the GLPI releases page. Read the notes for the target tag, then confirm the PHP and database versions it requires against the GLPI prerequisites before changing anything. Run the upgrade on a restored copy of production first, and keep the previous tag and backup set until the restored copy has passed your functional checks.
Questions teams ask before running GLPI in Docker
How much effort does a production GLPI stack in Docker take to stand up?
The container image itself is quick to start, but a production stack takes more work than the quick start shows. Effort depends on the database setup, persistent volumes, TLS termination in front of the container, backups of the database and the glpi.key and glpicrypt.key files, email delivery, authentication and monitoring. Each of these adds configuration and testing time. Ask any partner for a written scope that lists these items individually so you can compare it with your own estimate.
What does our internal team need to provide for a Docker-based GLPI deployment?
Your team should provide the hosting platform, the container runtime, network routes to the database, LDAP or identity sources, mail relays and DNS records. Someone must own the secrets, the backup targets and the change approvals for upgrades. A named administrator who understands GLPI profiles, entities and the console also helps, because many decisions after go-live are about configuration rather than infrastructure. Confirm these responsibilities in writing before work starts.
Can our team run GLPI in Docker without an outside partner?
Yes, if your team already runs containers in production, has database administration skills and can test backups and restores. The harder parts are usually the upgrade path and plugin compatibility rather than the first launch. Teams that lack capacity in one of these areas often bring in a partner for a fixed-scope piece, such as the initial build or the upgrade runbook, and keep day-to-day operations in-house.
How long does a GLPI version upgrade take in Docker?
The duration depends mostly on plugins and data volume. Upgrading by image tag is only one step. The GLPI update procedure requires a database backup, a backup of files and the config directory, replacing the 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 every installed plugin needs a compatibility check. Large databases and many plugins extend the test cycle. Ask for the upgrade steps and test plan in the written scope.
What drives the cost of running GLPI in Docker?
Cost is driven by scope, plugins, integrations and support. Scope covers the number of environments, the backup and monitoring design and the authentication setup. Plugins add testing and upgrade work for each release. Integrations with directories, mail, device management tools or monitoring add build and test effort. Support can be one-time or recurring. Teams also budget for infrastructure and their own staff time. Teams evaluating the vendor-run option can compare the GLPI Network subscription tiers, which start at 100 euros per month for self-hosted Basic with up to 10 agents and 500 assets, and the public cloud option at 19 euros per user per month. Use these figures only as a reference for comparison, and request a quote based on your written scope.
When is an external database or Kubernetes worth the added complexity for GLPI?
Add an external database when you need separate backup, performance tuning or high availability controls that the database team already runs. Consider Kubernetes when your organization already operates clusters with the required storage, ingress and secrets practices, and when you need replicated front ends or rolling upgrades. Both choices add moving parts, so they are worth it when the workload or governance requirement justifies them. For a small or single-site install, a single container host with a managed or well-run database is often simpler to operate. Confirm the sizing with your own user and agent counts before choosing.
What should we check in GLPI's security settings before going live in Docker?
Check that the application is served over HTTPS only, that the encryption key files are backed up and stored separately from the database, and that the database is not reachable from outside the container network. Review authentication order, since GLPI tries the internal database, LDAP directories, IMAP and other external methods in that order, so confirm which sources are enabled. Confirm session behavior and administrative access controls, and check the security hardening guidance for exposed endpoints. Record these checks as evidence for your own review process.
Security and operational considerations for containerized GLPI
A containerized GLPI moves configuration, secrets and data into volumes and environment variables, so the risks shift from the host to the container lifecycle. The cards below cover what survives a rebuild, how credentials reach the container, how you track image updates, who can reach administrative functions, whether restores actually work, and what the running instance reveals to outsiders.
Encryption key handling across rebuilds
GLPI relies on the glpi.key and glpicrypt.key files in the config directory to protect stored secrets and encrypted data. If those files live only inside a container layer, a rebuild or image pull can leave you with an instance that cannot decrypt its own credentials. Keep both files on a persistent volume or a managed secret store, and confirm in a test rebuild that stored integration passwords still work. Losing these keys is not a recoverable mistake without a backup taken before the change. Confirm the exact handling in the installation documentation for your image version.
Database credential management
The MySQL or MariaDB credentials for GLPI are passed to the container as environment variables, which can appear in docker inspect output, process listings and orchestration dashboards. Prefer Docker secrets or a secret manager that injects values at runtime, restrict who can read container configuration, and use a database account limited to the GLPI schema. Rotate the password through a planned change that updates the container and the database together, and test that the application reconnects cleanly afterwards.
Image provenance and update monitoring
Pinning the image by tag is only useful if you know which tag you run and when a new one ships. GLPI published 12.0.0 and 11.0.11 in October 2026 according to the release page, so track both release lines and record the exact image digest in your deployment record. Subscribe to release notifications, scan the image with your usual tooling, and confirm that the image source and signing approach match your supply chain policy before promoting it. Ask the vendor or DeployOpen to document the verification steps you adopt.
Session and administrator access controls
Administrative accounts in GLPI can change configuration, plugins and data for every entity, so the container should not be the only control. Put the web entry point behind your identity provider or a reverse proxy where that fits your design, enforce strong passwords and two-factor authentication for administrators, and review profiles and authorization rules after each upgrade. GLPI 12.0.0 adds a view of active sessions with the ability to revoke them and step-up authentication for some administrative actions. Confirm which of these controls your chosen release and configuration enable.
Backup and restore testing for volumes and database
A compose stack has at least three things to back up: the database, the files directory and the config directory with its keys. Take them at the same point in time, because a database restored from one moment and files from another can produce broken attachments and references. Schedule restores into a separate stack, start GLPI there, and check logins, ticket attachments and inventory records. A backup that has never been restored is an assumption, not a control. Record the restore duration you measure so the recovery expectation rests on evidence.
Exposure of status and endpoint information
A default web deployment can reveal version details, installation paths, status pages and API or agent endpoints to anyone who can reach the port. Limit network access to users and agents that need it, block access to directories other than the public entry point at the proxy, and review which endpoints accept unauthenticated requests. The GLPI security hardening guidance covers these exposed endpoints in more detail. Scan the running instance from outside your trusted network after each change and confirm the results against your own baseline.
How DeployOpen scopes and delivers a containerized GLPI
A containerized GLPI engagement starts with a written, fixed scope that names the image tag, the compose or orchestration target, the database service, the reverse proxy, the storage for the files and config directories, the identity sources and the hosts that will run GLPI Agent. DeployOpen reviews your environment before any build: container runtime and its version, host sizing, outbound network rules, DNS and TLS certificates, backup tooling, and whether the instance will be reached only from inside your network or published to users. The output of that review is a short list of decisions you approve, such as where the glpi.key and glpicrypt.key files are kept, which volumes are persistent, how secrets reach the container, and which GLPI release line you start on. The quote follows from that written scope, so the cost reflects the components and decisions you asked for rather than a generic package.
Build and verification follow the agreed plan in your own accounts or data centers. The work covers the compose stack, environment variables for the database connection, persistent volumes, health checks, the first-run installation, and a test of backup and restore into a separate environment before go-live. Verification includes confirming that files survive a container recreation, that the database is reachable only from the GLPI container network, and that scheduled tasks run from the intended service. DeployOpen also delivers a runbook for upgrades by image tag, including the backup order, the database update step and the reactivation of plugins that GLPI suspends after a new version is detected. Your team receives the configuration as code, the runbooks and the evidence of each test. Ask any provider to confirm which of these items are included in the fixed price and which are optional.
Ongoing work is optional and sold as a retainer. A retainer can cover patch and image tag reviews, upgrade rehearsals against a copy of production, restore tests, monitoring tuning and support for plugin changes. Retainers are useful when your team does not want to own every GLPI release, but they do not replace internal ownership of the data, the backups and the access decisions. Before you sign, confirm the response expectations, the upgrade cadence, who holds the registry credentials and the database administrator rights, and how the handover of configuration will be tested. DeployOpen prepares systems and evidence for compliance reviews, but independent auditors and certification bodies issue any audit report or certification.
