When a GLPI Docker image beats an archive installation, and when it does not
Choose the official Docker image when your team already runs containers and wants the image itself to carry the repeatable parts of the deployment. The official GLPI image installs or updates GLPI automatically when the GLPI_DB_HOST, GLPI_DB_PORT, GLPI_DB_NAME, GLPI_DB_USER and GLPI_DB_PASSWORD variables are set, and the README for the glpi-project/docker-images repository recommends pinning image digests so a deployment can be locked or rolled back. The image is rebuilt weekly for the latest release of each supported GLPI version to pick up OS, PHP and library updates without changing GLPI application code. The Docker model also fits horizontal scaling: the same README advises setting GLPI_CRONTAB_ENABLED to 0 on web and API nodes and running cron in one dedicated container. If you run Kubernetes or a similar scheduler, that separation is the main reason to choose the image.
Choose the archive when your standards already define PHP, the database and the web server, or when you need direct control of the host. The archive gives you the installation docs' requirements as written: PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, a web server whose document root points to the public directory with URL rewriting, and no container layer to patch or monitor. Confirm the current PHP and database minimums for the release you plan to run, because the README on the main branch lists newer versions. Plugins also behave differently. In the image you must mount a separate volume for custom plugins, and on GLPI 10.0.x the marketplace path sits outside the default volume. On the archive, plugins live in the application tree you already manage.
Both models are self-hosted, so neither removes work from your team. You own the database and file backups, the glpi.key and glpicrypt.key files in the config directory, the cron schedule and each upgrade. The archive update procedure replaces application files and runs php bin/console db:update, and since GLPI 11.0 plugins are suspended when a new version is detected and must be reactivated after major updates. With the image, an upgrade is an image change plus a database update, so the pinned digest and the volume contents must be backed up and tested together. Before you decide, run a rollback and a plugin reactivation test in a staging environment with your real plugin set.
How the two deployment models compare on the factors that matter
This table compares running GLPI from the official Docker image against installing the release archive on your own PHP and web server stack, across setup, configuration, cron, plugins, scaling and upgrades. Read each row as a question to answer for your environment, and treat the version minimums as something to confirm before you commit to a stack.
| Factor | Official Docker image | Release archive on your own stack |
|---|---|---|
| Platform requirements | Host runs a container runtime; PHP and OS come bundled and are rebuilt weekly for the latest release of each supported version | You provide the PHP, web server and OS; you patch them yourself |
| PHP and database versions | Follow the versions in the image; confirm the GLPI 11.0 minimum, since the README lists PHP 8.3 or later and MariaDB 10.11 or later, while the install docs list PHP 8.2 or later and MariaDB 10.6 | Must meet the version set for your release; the install docs say only MySQL and MariaDB are supported, so PostgreSQL is not an option on either path |
| Automatic install | Installs or updates GLPI when the GLPI_DB_HOST, GLPI_DB_PORT, GLPI_DB_NAME, GLPI_DB_USER and GLPI_DB_PASSWORD variables are set; otherwise runs the web wizard | Web installation wizard or command-line steps on the host, with your own database provisioning |
| Config and key handling | Config, marketplace and files sit in a default volume; back up the volume so glpi.key and glpicrypt.key survive a rebuild | Config directory, including glpi.key and glpicrypt.key, lives on the host and must be included in your backups |
| Web server layout | Preconfigured by the image; you control exposure through the container and reverse proxy | Document root must point to GLPI's public directory with URL rewriting to index.php on Apache, Nginx, lighttpd or IIS |
| Cron | Set GLPI_CRONTAB_ENABLED to 0 on web and API nodes and run cron on one dedicated container when scaling horizontally | Schedule the GLPI cron job on the host yourself, once per instance |
| Plugin storage | Needs a separate volume for custom plugins; on GLPI 10.0.x the marketplace path is not in the default volume | Plugins sit in the application directory and survive only as long as you keep them through each file replacement |
| Scaling | Horizontal scaling or Kubernetes is documented, with pinned digests and a single cron container | Scaling means you build the load balancer, shared storage and cron scheduling yourself |
| Upgrade path | Pin image digests to lock or roll back; back up the database and volumes before pulling a new tag | Back up the database, files and config directory, replace application files, then run php bin/console db:update |
| Plugins after upgrade | Plugins are suspended after a new version is detected since GLPI 11.0 and must be reactivated after major updates | Same rule applies: plugins are suspended after a new version is detected and must be reactivated after major updates |
| Skills needed | Container operations, volume management and reverse proxy setup | PHP runtime tuning, web server configuration, database administration and file-level backups |
How the official image installs and updates GLPI automatically
The official GLPI Docker image decides what to do at startup based on its environment. When the GLPI_DB_HOST, GLPI_DB_PORT, GLPI_DB_NAME, GLPI_DB_USER and GLPI_DB_PASSWORD variables are set, the container installs GLPI into that database or updates an existing installation automatically. When those variables are absent, it starts the web installation wizard instead. For a platform team, this means the database connection settings are the switch between unattended and manual setup, so they belong in your deployment manifest and secrets store, not in a one-time shell session. Confirm the exact behavior for your target version in the glpi-project docker-images README before you write the automation, because the README is the documented source for this startup logic.
The image publisher rebuilds images for the latest release of each supported GLPI version every week. Per the README, each rebuild updates the operating system, the PHP runtime and system libraries, and does not change GLPI application code. That separates two kinds of change you need to track: GLPI version changes, which you control by choosing a tag, and base-layer changes, which arrive on the same tag without a new GLPI release. The documented way to lock a deployment is to pin image digests rather than floating tags, and the same digest is the way back if a rebuild causes a regression. Ask whether your registry mirror preserves digests, and record which digest each environment runs.
Treat every rebuilt image as a candidate, not a drop-in replacement. Pull the new digest into a staging environment with a copy of the production database, run the startup path and confirm that the database update completes, that your plugins load and that login, inventory sync and scheduled tasks behave as before. GLPI's own update guidance also calls for backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, before any change. Only promote a digest after that test passes, and keep the previous digest available so you can redeploy it quickly.
Where cron, plugins and scaling change between the two models
The Docker image and the archive installation both run the same GLPI application, but they put cron, plugin files and scaling in different places. Each card below covers one of those operational points and what to verify in your own environment before choosing a model.
Cron scheduling per container role
The Docker image documents a container setting, GLPI_CRONTAB_ENABLED, which should be set to 0 on web and API nodes when you scale horizontally. You then run cron in one dedicated container so scheduled GLPI tasks execute once rather than on every node. In the archive model, cron is a host-level job you configure yourself, usually on the same server or on one designated node. Confirm which node runs scheduled tasks and that no task runs twice or never runs after a container restart.
Plugin storage in the image
The official image provides a volume for config, marketplace and files by default, but custom plugins need a separate volume that you mount yourself. On GLPI 10.0.x, the marketplace path is not part of the default volume, so plugins installed through the marketplace can be lost when a container is replaced unless you map that path explicitly. In the archive model, plugins live in the application directory and survive as long as you keep that tree during an update. Map the plugin and marketplace paths before your first upgrade and test a container replacement.
Horizontal scaling and session handling
The image documentation gives guidance for horizontal scaling and Kubernetes, which is the reason cron is split out and digests are pinned for controlled rollouts. Scaling out, however, does not make state disappear. Sessions, uploaded documents and generated files must be shared or sticky across nodes, or users may be logged out or see missing attachments. Test session behavior, file storage and the update path under load before you add replicas, because the documentation does not settle these questions for your topology.
Web server document root and rewriting
The archive installation requires the web server's document root to point to GLPI's public directory, not the installation root. URL rewriting must route requests through index.php on Apache, Nginx, lighttpd or IIS. Pointing the root at the wrong directory exposes application code and configuration, so this is a security check, not only a functional one. The container image handles this layout for you, which shifts the verification to your reverse proxy and TLS termination. Verify the document root and rewrite rules on every web server you run.
Upgrades, backups, monitoring and skills for each model
This table compares what each model asks of your team after go-live: upgrade steps, backup scope, rollback, monitoring ownership and skills. Read it as a checklist of duties you would keep in house under each model. The main takeaway is that the image shifts work toward volume, digest and database handling, while the archive keeps every step, including plugin reactivation, on your own runbook.
| Operating duty | Archive installation on your PHP and web stack | Official Docker image |
|---|---|---|
| Upgrade steps | Back up the database, files and config directory, replace application files, then run php bin/console db:update. Your team sequences each step. | Pull the new image or digest and restart the container. Database changes run automatically when the GLPI_DB_* variables are set, so confirm the upgrade path in the image README before each change. |
| Backup scope | Database, GLPI files and the config directory, including glpi.key and glpicrypt.key. Losing those keys can leave stored secrets unreadable, so confirm the restore path before relying on it. | Database plus every Docker volume: config, marketplace, files, and any custom plugin volume. The image does not back up volumes for you, and marketplace data on GLPI 10.0.x sits outside the default volume. |
| Rollback method | Restore the pre-update database, files and config backup, then point the web server at the restored code. Tested restores are the only reliable rollback. | Redeploy an earlier image pinned by digest. Rollback also needs the matching database and volume state, so a digest alone does not undo schema changes. |
| Plugin handling on upgrade | Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Plan a plugin compatibility check in every upgrade window. | The same suspension rule applies because the application code is GLPI itself. Mount plugins from a separate volume and test each one against the new version before cutover. |
| Monitoring ownership | Your team monitors the web server, PHP-FPM, database and the cron job that GLPI relies on. Nothing is preconfigured for you. | Your team monitors the container runtime, volumes, database and cron. With horizontal scaling, confirm that GLPI_CRONTAB_ENABLED is 0 on web and API nodes and that one dedicated container runs cron. |
| Image currency | You choose when to take OS, PHP and library updates, and you manage those patches on the host. | Images for the latest release of each supported version are rebuilt weekly to update the OS, PHP runtime and libraries without changing GLPI code. Pin digests so that a rebuild does not change production without a test. |
| Operating skills required | PHP runtime tuning, web server rewrite rules that send requests through index.php, database administration and Linux host patching. | Container orchestration, volume management, secret handling and database administration. Teams without container experience should confirm they can run restores and rollbacks in a test environment first. |
What drives the cost and effort of each model
The main cost in both models is internal staff time, and the difference is where that time goes. With the Docker image, your team owns the container platform (the host, the orchestrator if you use one, the registry and the pipeline that pulls and redeploys images), while the GLPI application code arrives pre-packaged. With the archive, your team owns the PHP runtime, the web server, the file layout, the document root and the update steps. Any external implementation work, such as a DeployOpen engagement scoped in writing, is a separate line item that depends on how much of that setup you hand over. Database and backup operations are paid for in both models: someone must own the MySQL or MariaDB instance, the backups of the database, the files and the config directory with glpi.key and glpicrypt.key, and the restore tests that prove those backups work.
The one-time work is the initial build: the image or server configuration, the pipeline, the volume layout (including a separate volume for custom plugins), the cron approach, and the documentation and cutover from any existing service desk. The recurring work is what drives the long-term cost. With the Docker image, expect to review the weekly rebuilds, decide when to move an image digest forward, and retest plugins after each change. With the archive, expect to schedule each release, replace the application files, run php bin/console db:update and reactivate plugins, since plugins are suspended when a new version is detected. Ask any quote to price these recurring items separately from the initial build, and to state who performs restore tests and how often.
Cost also rises with plugin count, custom code and scale. Under the docker-images guidance, horizontal scaling or Kubernetes means setting GLPI_CRONTAB_ENABLED to 0 on web and API nodes and running cron on one dedicated container, which adds design and monitoring work. Plugin testing is a recurring cost in both models, and it grows with every plugin you rely on. DeployOpen does not publish prices, and a quote follows the written scope, so list your plugins, expected instances, backup retention and upgrade cadence before asking for one. If you also plan a GLPI Network subscription, its published tier prices are on GLPI Network subscriptions. Those fees are separate from the deployment choice and should be compared on their own line.
How to move an existing GLPI install to a new release safely
This sequence gets an existing GLPI instance onto a newer release with a known rollback point, whether it runs from the official Docker image or from an archive on your own PHP and web server stack. Each phase closes with a check you can record, so the cutover is a decision rather than a hope.
Confirm target release requirements
Before touching anything, the platform owner checks the target GLPI release's PHP and database requirements in the GLPI installation docs and compares them with the running stack. For the Docker model, confirm the image tag and the PHP and database versions it bundles. For the archive model, confirm the PHP version, extensions and MariaDB or MySQL version on the host. Done means you have a written note of any gap, such as a PHP upgrade that must land first, and you have confirmed the plugins you rely on support the target release.
Back up database, files and config keys
The administrator takes a full database dump, a copy of the GLPI files directory, and a copy of the config directory, including the glpi.key and glpicrypt.key files. In the Docker model, this means the volumes for config, files and any custom plugin volume, plus the database. In the archive model, it means the application tree and the config directory on the host. Done means the backups are restored once to a scratch host or container, and the restored instance logs in and shows tickets and assets. Without the key files, encrypted data may not be recoverable.
Stage the new release in a test environment
The team builds a copy of production in a separate environment using the restored backups and the target release, either a pinned image digest or the new archive unpacked beside the current one. The platform owner records the exact image digest or archive checksum so the deployment can be reproduced or rolled back. Done means the staged instance serves the login page, the web server document root points to GLPI's public directory, and a sample of tickets, assets and reports loads without errors.
Run the database update
On the staged instance, the administrator runs the database update. In the Docker model, the container performs installation or update automatically when the database variables are set, so the operator checks the container logs for the update result. In the archive model, the administrator runs the console command php bin/console db:update from the new application directory. Done means the command or log reports success with no pending migration errors, and the GLPI interface shows the target version in its about or administration view.
Check plugin status and reactivate
Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. The administrator reviews the plugin list, confirms each plugin has a version compatible with the target release, and reactivates them one at a time while watching for errors. For the Docker model, confirm custom plugins sit on their dedicated volume and are visible to the new container. Done means every required plugin is active, and a short test of each plugin's main function passes in the staging instance.
Test cron and scheduled tasks
Scheduled tasks such as mail collection, inventory processing and notifications must run on the new version. In the Docker model, check the GLPI_CRONTAB_ENABLED setting and confirm cron runs in the intended container, especially if the deployment spans several nodes. In the archive model, confirm the host scheduler still runs the GLPI cron job and that its user and PHP binary still match. Done means scheduled tasks execute on schedule in the staging environment and the job log shows no failures over a monitored period the team sets.
Cut over with the rollback path ready
The team schedules the production change, stops write activity where practical, takes a final database backup, and applies the new release. In the Docker model, the operator updates the image reference to the pinned digest. In the archive model, the team swaps the application directory or the web server path to the new release, keeping the previous tree intact. Done means users can sign in and create a test ticket, and the rollback path is written down: restore the previous image digest or application tree and the pre-change database backup, then reactivate plugins on the old version.
Document the outcome and retire the old copy
The platform owner records the release, image digest or archive checksum, backup locations, plugin list and test results in the change record. The old application tree or image stays available until the new release has run in production for a period the team agrees. Done means the change record is complete, the rollback path is tested or reviewed, and the team confirms its support or subscription terms still match the release in use.
Which model fits which team and environment
This tab fits a team that already builds, scans and deploys containers through a pipeline and treats infrastructure as code. The official GLPI image installs or updates GLPI automatically when the database variables are set, and the image is rebuilt weekly to refresh the OS, PHP runtime and system libraries without changing GLPI application code. That shifts routine patching into your registry and pipeline, where you already have controls for it. The trade-off is that you own the image lifecycle, the volume layout and the plugin path, rather than a server you patch by hand.
- Pipeline fit: Your existing build, scan and promotion steps can gate each rebuilt image before it reaches production.
- Rollback control: The docker-images README recommends pinning image digests so a deployment can be locked or rolled back.
- Volume discipline: Config, marketplace and files sit in a default volume, but custom plugins need a separate volume you must define.
- Argues against: If your container platform is new to the team, the image adds a layer to troubleshoot alongside PHP and database issues.
- Argues against: Frequent weekly rebuilds mean you must test or accept image churn on every update cycle.
Before choosing, confirm which GLPI major version you will pin, how plugins are sourced and mounted, and who owns the rebuild and digest promotion process.
This tab fits an organization that already runs a shared PHP and web server stack for other applications and wants GLPI on the same platform. The release archive installs into that stack, so you control the PHP version, extensions and web server configuration directly. The GLPI installation docs require PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and the document root must point to the public directory with URL rewriting on Apache, Nginx, lighttpd or IIS. Those requirements must fit the versions your other applications already use.
- Version alignment: GLPI 12.0.0 lists PHP 8.3 or later in the README, which may require a runtime upgrade that affects neighboring apps.
- Cron ownership: You configure cron yourself on the host, which is simple on a single server but must be coordinated with other jobs.
- Plugin control: Plugins install into your own directory tree and follow the GLPI update procedure, including reactivation after major updates.
- Argues against: A shared stack means GLPI upgrades can be blocked by the needs of other applications, and vice versa.
- Argues against: Your team carries the full update routine: backing up the database, files and config including glpi.key and glpicrypt.key, replacing application files and running php bin/console db:update.
Confirm the supported PHP and database versions for the GLPI release you target, and whether your change process can schedule a shared runtime upgrade.
This tab fits a deployment that runs several GLPI web or API nodes behind a load balancer, or runs on Kubernetes. The docker-images README recommends setting GLPI_CRONTAB_ENABLED to 0 on web and API nodes and running cron on one dedicated container, so scheduled tasks do not run once per node. The archive model can scale too, but you must build that separation yourself with the web server, cron and shared storage. Scaling choices here affect session handling, file storage and plugin consistency across nodes.
- Single cron owner: Designate one container for scheduled tasks and disable cron on every other node through GLPI_CRONTAB_ENABLED.
- Shared state: Confirm how the config, marketplace and files volumes are shared across nodes and where the glpi.key file lives.
- Image pinning: Use digests so every node runs the same build during a rolling update.
- Argues against: Multi-node setups add failure modes that a single host does not have, including volume locking and inconsistent plugin versions during upgrades.
- Argues against: The plugin volume must be mounted identically on every node that serves requests.
The illustrative question to settle is how a rolling update will handle plugin suspension after a new version is detected, and which node runs the one cron container.
This tab fits a team that cannot pull images from public registries or run unreviewed software. In a tightly controlled network, the release archive is often easier to verify and mirror, because it can be checked, stored in an internal artifact repository and installed on hosts already under your change control. The official image requires a registry path you control, and the weekly rebuild cycle means each rebuilt image needs its own review before it reaches the enclosed network. Both models require mirrored dependencies for the OS, PHP and database.
- Artifact control: An archive can be hashed, stored and approved once per release, while an image needs a mirrored registry and a digest review.
- Update cadence: Weekly image rebuilds mean more frequent reviews unless you pin digests and promote them on your own schedule.
- Plugin provenance: Plugins from the marketplace need a source review whichever model you pick, and the plugin volume must be governed.
- Argues against the image: Pulling and promoting images across an air gap adds transfer steps that the archive avoids.
- Argues against the archive: Your team must mirror the PHP runtime, extensions and OS packages for the host, which the image bundles.
Confirm with your security team how software enters the enclave, whether your approval process works per image digest or per release archive, and whether GLPI's authentication order (internal database, LDAP, IMAP, then external methods) matches your identity design.
What buyers ask before choosing a GLPI deployment model
Can our team run GLPI from the Docker image or the archive without outside help?
Yes, many teams can, provided they already operate the underlying stack. The Docker route still needs a container host, a database, persistent volumes, a reverse proxy and a backup process. The archive route needs a supported PHP version, a web server with the document root pointed at GLPI's public directory, URL rewriting, and a database. Both models require someone to own upgrades, backups of glpi.key and glpicrypt.key, and plugin management. Ask whether your staff have run PHP applications, container platforms or both in production, and who will perform upgrades on a fixed schedule.
What skills does a GLPI deployment demand from our staff?
The Docker model asks for container and volume administration, environment variable management and image digest pinning. The archive model asks for PHP configuration, extension management, web server rewrite rules and database administration. Both need familiarity with GLPI's update sequence, which requires a database backup, file backup, replacement of application files and running php bin/console db:update. Name a primary and a backup owner for each layer, then check whether they can rehearse a restore. Gaps in these skills are usually the largest hidden cost of self-hosting.
How long does a GLPI deployment take, and what sets the timeline?
No fixed duration is published here for either model, so ask for a scoped timeline in writing rather than relying on a general estimate. The timeline depends on the number of environments, whether you need migration from an existing ITSM tool, the size of the database, the number of plugins, the authentication source (internal database, LDAP, IMAP or REMOTE_USER), integrations with mail and identity systems, and how many approval rounds the change process requires. Ask for milestones tied to acceptance tests, not only to installation dates.
What drives a DeployOpen quote for a GLPI engagement?
Most engagements are fixed-scope, so the quote follows from a written scope that lists deliverables, environments and timelines before work begins. The main drivers are the deployment model you choose, the number of environments (production, staging, disaster recovery), the volume and cleanliness of data to migrate, the plugins to install or customize, the authentication and mail integrations, the hardening and backup requirements, and the documentation and handover you need. Ask for each of these as a separate line item so you can see what is one-time work and what recurs. DeployOpen does not publish a price list.
How are cron jobs and plugins handled in Docker and archive installs?
In the Docker model, the official image runs cron inside the container by default. For horizontal scaling or Kubernetes, the docker-images README recommends setting GLPI_CRONTAB_ENABLED to 0 on web and API nodes and running cron on one dedicated container. Custom plugins need their own volume, and on GLPI 10.0.x the marketplace path is not in the default volume. In the archive model, cron is a host scheduler job you configure and monitor yourself. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Confirm in writing who tests each plugin against each target version.
When does fixed-scope work or a retainer fit a GLPI deployment?
Fixed-scope work fits a defined project: planning the target architecture, installing and hardening the chosen model, migrating data, configuring authentication, writing runbooks and handing over. A retainer fits ongoing needs: upgrades that follow GLPI's release cadence, backup testing, plugin updates, monitoring follow-up and periodic security testing. Many teams use both, with the project delivered as a fixed scope and support under a separate agreement. If your staff can run the platform alone, you may need only the project. If they cannot cover upgrades on schedule, a retainer is the question to price against the written scope.
How DeployOpen scopes, delivers and supports GLPI deployments
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For GLPI Docker image vs archive installation, that means agreeing in writing whether the container or the archive route fits your PHP, database, cron and plugin requirements before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We record your target GLPI version, database engine, web server, plugin list and whether cron runs on one node or many.
- The written scope states who maintains the image pin, backup routine and upgrade path after the first deployment.
How we build
- We install GLPI in your own cloud account, data center or air-gapped network, using the route your scope selects.
- For containers, we set database variables, persistent volumes for config, files and custom plugins, and digest pinning.
- For archives, we configure the document root, URL rewriting, PHP extensions and scheduled cron on the agreed web server.
How we hand over
- We document the deployment, including volume layout or directory layout, cron configuration and the plugin reactivation steps.
- Handover covers the backup set, including the database, files and the config directory with its key files.
- We walk your operators through a documented update and rollback procedure before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Retainers can cover tracking of new GLPI releases and rebuilt images, with changes tested before they reach production.
- Ask for the support boundaries in writing, including who handles plugin compatibility and which environments are covered.
