When to install GLPI plugins from the marketplace or manually
Choose the marketplace path when the GLPI instance can reach the marketplace and you want the plugin's registration and updates handled through the GLPI interface. Choose a manual install when the instance sits on a network with no internet access, or when your change process requires every file to be reviewed and staged before it reaches production. Either way, the decision starts with the GLPI version you run, because a plugin is code that extends GLPI core and must match the core release it was built for. GLPI itself is distributed under the GNU General Public License version 3, and its README describes the core platform for tickets, assets, CMDB, contracts and financial management. Plugins add the functions that core does not cover for your organization, such as custom fields, purchasing or reporting, and each one adds code paths, database tables and upgrade work that you must own.
Before you pick a path, confirm three things with the plugin's publisher and in your own environment: which GLPI versions the plugin release supports, whether it needs a GLPI Network subscription, and how it behaves after a core upgrade. The GLPI update procedure in the installation docs states that since GLPI 11.0 plugins are suspended when a new version is detected and must be reactivated after major updates, so a plugin that is not ready for your target release will stop working until you resolve it. Check the GLPI installation docs on updates for the full sequence before you schedule any plugin change alongside a core upgrade.
If the server cannot reach the internet, plan the manual path from the start. Download the plugin package on a connected workstation, record its version and checksum, move it through your approved transfer method, and install it into the GLPI plugin location with a backup of the database, files and the config directory taken first. Keep a separate plugin directory in mind for marketplace downloads, since the GLPI_MARKETPLACE_DIR setting determines where marketplace-managed plugins are stored and must be planned alongside your file permissions and backup scope. Ask the plugin vendor for the exact supported GLPI versions and for release notes before you start, and test the install on a copy of your instance before production.
Marketplace or manual install: which path fits your environment
An instance that can reach the internet can install plugins from the marketplace, which is the path most teams start with. The operator registers the instance with a marketplace registration key, then installs and activates each plugin from the GLPI interface, so the code and update notices come from the same channel. The trade-off is that updates depend on that connection and on each publisher's release schedule, so the team has to track them.
- Registration key: Store the key in your secrets process and confirm which plugins it unlocks. Some plugins are tied to a GLPI Network subscription level, so check that before planning the build.
- Maintenance ownership: Teclib-published plugins and community plugins differ in who ships fixes and at what support level. Ask each publisher for its release and support terms in writing.
- Separate plugin directory: Set GLPI_MARKETPLACE_DIR to a directory you control and confirm in the GLPI documentation how it is read, so plugin code stays apart from the core application files during updates.
- Version matching: Before updating GLPI, confirm that each plugin release supports the target GLPI version, since plugins follow the core release cycle.
- Outbound rules: Allow the connections the marketplace needs through your proxy and firewall, and document them for your security team.
Before go-live, check that the registration key is accepted, that each plugin reports the version you approved, and that your change record names an owner for future updates.
A network with no route to the marketplace needs plugin archives brought in by hand. The team downloads the archive on a staging system, checks it against the publisher's published checksum where one exists, moves it through your approved transfer process, and extracts it into the plugin directory. No update channel reaches the instance, so every upgrade becomes a planned intake event with its own review.
- Staging host: Fetch the archive for the exact GLPI version in use on a connected workstation, then scan it under your malware and supply chain policy before transfer.
- Transfer record: Log the file name, plugin version, hash and approver for each archive so auditors can trace what entered the environment.
- Directory layout: Place the extracted plugin in the directory your instance reads, with ownership and permissions that match the web server user. If you use GLPI_MARKETPLACE_DIR, keep that directory separate from the core application tree.
- Dependency check: Confirm each plugin's PHP version and extension requirements against the runtime on the instance, including any libraries the plugin bundles.
- Review window: Schedule regular reviews for new archives, because no automatic notice will tell you a release exists or that a fix has shipped.
Before activation, confirm that the checksum matches your transfer record, that the plugin appears in the list with the expected version, and that no files were written outside the plugin directory.
Both paths end in the same verification routine, and it matters most after a GLPI update. The update procedure in the GLPI installation documentation calls for backing up the database, the files and the config directory, replacing the application files, then running the database update command. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so a plugin that looked healthy before the update can be off afterward.
- Backups first: Back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, before changing anything.
- Runtime versions: The GLPI README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later for the current release. The GLPI 11.0 installation documentation lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Confirm each plugin supports the runtime you run.
- Database update: Run php bin/console db:update as the procedure describes, and review the output for errors before reactivating anything.
- Plugin status: Reactivate each plugin after a major update, then confirm it appears active at the expected version.
- Functional tests: Test the workflows each plugin supports, such as forms, fields or purchasing, using a test account before users return.
Record the GLPI version, the PHP and database versions and each plugin version in your change log, so the next update starts from a known state.
Plugin installation options and when each fits
This table compares the ways to get a GLPI plugin onto an instance: the marketplace registration key, a manual archive install, a separate plugin directory set with GLPI_MARKETPLACE_DIR, and Teclib-published versus community plugins. Read each row for when the option fits, what it requires and its main trade-off. Confirm key formats, command names and settings in the current GLPI documentation before you plan a change.
| Option | When it fits | What it requires | Main trade-off |
|---|---|---|---|
| Marketplace with registration key | Instance can reach the marketplace and the plugin is listed there | A registration key for your instance; confirm its format and entry point in current docs | Depends on outbound connectivity and on the marketplace reporting compatibility with your GLPI line |
| Manual archive install | Isolated or air-gapped networks, or vetted plugins mirrored internally | Archive obtained and checked outside the network, then placed in the plugin path and matched to your GLPI release | You track versions, integrity and updates yourself, and repeat the checks at each GLPI upgrade |
| Separate plugin directory (GLPI_MARKETPLACE_DIR) | You want marketplace-managed plugins kept apart from core application files | Variable set before installation, a writable path for the web server, and the path added to backups | One more location to back up, permission and monitor; a missed path leaves plugins unprotected |
| Teclib-published plugins | Support, a vendor release path and marketplace distribution matter to your team | Check whether the plugin is in the GLPI Network set; marketplace plugins are tied to a subscription level | Recurring subscription cost; the Enterprise self-hosted tier listed at 4,500 euros per month includes level 3 support and marketplace plugins |
| Community plugins | A needed capability exists only as a community project | Review maintainer activity, license, and whether a build exists for your GLPI 11 or 12 line | Support and release cadence vary, so you test each plugin before every GLPI upgrade |
| Plugin build matched to GLPI release | Applies to every option above | A build for your exact GLPI line; GLPI 11 suspends plugins after a new version is detected | Plugins can lag new releases such as GLPI 12.0.0, which was released October 7, 2026 |
How to match plugin versions to GLPI 11 and GLPI 12 releases
A plugin must be built for the GLPI release you run, and the release history shows why the check matters. GLPI 10.0.0 was released on April 20, 2022, GLPI 11.0.0 on October 1, 2025, GLPI 11.0.11 on October 1, 2026 and GLPI 12.0.0 on October 7, 2026, according to the glpi-project/glpi releases page. Each major line changed the core APIs, database schema and bundled features that plugins hook into, so a plugin written for 10.x may not load on 11.x and a plugin written for 11.x may not load on 12.x. Before you install anything from the marketplace or a manual archive, record your current GLPI version, then confirm the plugin's listed compatibility for that exact line. Do not assume that a plugin which works on a patch release also works on the next major release.
Check the runtime requirements before you match versions. 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, while the GLPI installation prerequisites for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and say only MySQL and MariaDB are supported. Treat the stricter floor as your planning baseline for any GLPI 12 target, and confirm the minimum PHP and database versions for the specific GLPI release you choose in the GLPI installation prerequisites. Then confirm that each plugin supports that PHP and database combination, since a plugin can declare a narrower range than the core. Plugin archives also need to be replaced in the plugin directory during the upgrade, so keep the previous versions available for rollback.
Plan the upgrade order around plugin suspension. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so a plugin that is not yet compatible will stay off until you act. Run the upgrade in a staging copy first, follow the backup and php bin/console db:update steps from the GLPI update documentation, then reactivate plugins one at a time and test the functions each one provides. Record the GLPI version and plugin versions together in your change record, so the next upgrade starts from a verified matrix rather than memory.
Install a GLPI plugin step by step with checks
This sequence takes a GLPI plugin from a backed-up instance to an active, verified install. Each step ends with a check you can record, so a failed install can be rolled back before users see it. Exact commands and plugin-specific steps must be confirmed against the plugin's own documentation.
Back up the database, files and config directory
Before touching the plugin, the administrator takes a full backup of the GLPI database, the GLPI application files and the config directory. The config directory holds glpi.key and glpicrypt.key, which GLPI needs to read encrypted data, so losing them can make stored secrets unreadable even if the database restores cleanly. Store the copies outside the GLPI host. The step is done when a restore of the database dump and files has been tested on a non-production copy, or when you have written down the restore procedure your team will follow.
Confirm GLPI and plugin versions match
Record the installed GLPI version and the version of the plugin you intend to install, then compare them with the plugin's compatibility statement. A plugin built for a different GLPI major version is the most common cause of failed activation or broken pages. Check the PHP and database versions required by the GLPI release you run, since the platform's prerequisites apply to plugins too. The check passes when you have a written note of both versions and the plugin's documentation confirms compatibility. If it does not, stop and choose a matching plugin release or plan a GLPI upgrade first.
Place the plugin in the marketplace directory
Put the plugin in the directory GLPI uses for marketplace plugins. By default this is the marketplace folder under the GLPI installation, but if GLPI_MARKETPLACE_DIR is set in your environment, the plugin must go to that path instead. Keep the marketplace directory separate from the core files so that GLPI updates do not overwrite plugin code. Confirm the directory is readable by the web server user and that the path matches the value your server actually loads, because a mismatch leaves GLPI looking in one place while the plugin sits in another. The check is that the plugin folder appears in the GLPI plugin list after a page refresh.
Register the plugin or copy the archive
For a marketplace install, enter the registration key in the GLPI marketplace section and let GLPI download the package. For a manual or isolated-network install, copy the plugin archive onto the host through your approved transfer method, extract it into the marketplace directory and check the file ownership. Keys and archives must come from the plugin publisher or a source your change process approves. The step is complete when GLPI lists the plugin with its name and version, and the version shown matches the one you recorded in the previous step.
Activate the plugin in the plugin list
In the plugin management screen, install and then activate the plugin using an administrator account. Some plugins need a configuration page to be saved before they work, so open it and review the defaults before you grant any profile rights. Activation can fail if a required PHP extension is missing or the plugin expects a newer GLPI version. The check passes when the plugin status shows as active and no error appears in the GLPI logs for the activation request. Record the time and the account that activated it, since this will appear in your change record.
Run the database update where required
If the plugin ships database changes, run the database update from the GLPI installation directory with the console command php bin/console db:update, and confirm that it completes without errors. Run it again after any GLPI version change, since GLPI suspends plugins when it detects a new version and they must be reactivated after major updates. Review the command output for failed migrations and keep it with the change record. Confirm the exact command and any plugin-specific migration steps in the plugin's own documentation before running it in production. The check is a clean run with no pending migrations reported on the next console run.
Verify the plugin and its rights
Test the plugin with a non-administrator account that matches a real profile, and confirm that the features work and that the permissions are limited to the intended profiles. Check the GLPI logs and the web server error log for new warnings after a few normal actions. Confirm that a restore from the backup taken in the first step is still possible with the plugin's tables present. Record the GLPI version, plugin version, backup reference and test results. The step is done when the test cases pass, the logs are clean and the change record is signed off by the owner of the GLPI instance.
Security risks when adding plugins to GLPI
A plugin runs inside the GLPI process, so it can read and change everything the instance holds. The six risks below connect the install decision to the data, keys and administrative paths that a plugin can reach, and each one names a check to make before or after the install.
Third-party code sees ticket and asset data
A plugin executes with the same database and file access as GLPI itself, so it can read tickets, user records, contracts and inventory. Before installing, review who publishes the plugin, whether it is maintained, and which tables and hooks it touches. Confirm the plugin's compatibility with your exact GLPI version in a staging copy, not production, and record who approved the code.
Registration keys leaking into repositories
Marketplace registration keys tie a plugin download to your account or subscription. Store them in your secrets manager or the instance configuration outside version control, and keep them out of infrastructure-as-code, shell history and ticket attachments. If a key appears in a repository, rotate it through the publisher and review the commit history, not only the current file.
Unverified archives in isolated networks
On air-gapped networks, plugin archives are carried in by hand, so no marketplace check happens on the other side. Download from the publisher, record the file hash at the point of download, and compare it again after transfer. Keep the archive, its source URL and its approver in your change record so the next reviewer can trace what was installed.
Encryption keys missing from backups
GLPI stores its key files, including glpi.key and glpicrypt.key, in the config directory, and its update procedure requires backing them up with the database and files. Without them, encrypted values stored by GLPI and plugins may not decrypt after a restore. Test a restore into a separate environment and confirm the key files are present in that copy.
Plugin directory permissions separate from core
Plugins are placed in a directory that is separate from the GLPI core, and the web server user needs to read it but not change the core application files. Set ownership and write permissions so that only the deployment account can replace plugin code, and check that the path set in GLPI_MARKETPLACE_DIR matches what your web server serves. Review permissions after each update.
Step-up and session controls in GLPI 12
GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Plugin installation is an administrative action, so confirm that these controls apply to the accounts allowed to install, and that revoked sessions cannot continue. Ask your GLPI administrators which actions require step-up in your configuration and test them.
Questions buyers ask about GLPI plugin installation
Can our operators install GLPI plugins without outside help?
Yes, a capable operator can install a plugin from the marketplace or by hand, provided they can follow the installation docs, manage a database backup and work with the web server layout. The harder part is repeating the work safely: every GLPI release changes which plugin versions are compatible, and plugins are suspended after a new version is detected in GLPI 11.0 and later, so each upgrade needs a planned reactivation step. Teams that install one or two plugins on a stable instance often manage this in-house. Teams that run several plugins, isolated networks or frequent upgrades usually benefit from a written plan and a partner for the first cycle. Confirm your team's skills against the GLPI installation docs before deciding.
What drives the effort of a GLPI plugin installation?
Effort grows with four factors. The first is the number of plugins, since each one has its own dependencies, database changes and configuration. The second is version matching, because each plugin must be checked against your exact GLPI release, including minor releases. The third is network isolation: an air-gapped or restricted network needs manual packages, internal mirrors and a plan for updates that cannot reach the internet. The fourth is the upgrade cycle, since each GLPI or plugin update repeats the backup, file replacement and php bin/console db:update steps. Ask any provider to list how each factor applies to your environment.
What does the work need from our team?
Your team usually supplies access to the GLPI application server, database and web server, plus the people who can approve changes in production. You should also provide the list of plugins you need, the GLPI version you run or plan to run, and details about your network, including whether the marketplace is reachable. Someone must own the encryption keys, including glpi.key and glpicrypt.key, and confirm backup and restore procedures. Agree on a test environment before production work starts, because plugin activation and database changes should be checked there first.
How long does a GLPI plugin installation take?
Duration depends on scope, including the number of plugins, the GLPI version, network restrictions and how much testing your team requires. We cannot give a fixed duration without that information. Ask for a written plan that lists the work packages, the environments involved, the acceptance checks and the dates agreed for each step. A fixed-scope engagement is agreed in writing before work starts, so the timeline in that plan is the figure to rely on.
What does a quote for GLPI plugin installation follow from?
A quote follows from the written scope. DeployOpen does not publish a price list. The scope should name each plugin, the target GLPI version, the environments (test and production), the installation method (marketplace or manual), the network constraints, the backup and rollback approach and the documentation you expect at handover. Ask each provider to separate one-time work, such as the first installation and testing, from any recurring work, such as upgrade support or a retainer for ongoing maintenance.
When does a GLPI plugin subscription cost apply?
A subscription cost applies only to plugins that the GLPI Network program requires. According to the GLPI Network subscriptions page, GLPI Network public cloud costs 19 euros per user per month and private cloud costs 21 euros per user per month, with a 25-user minimum. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), which includes level 3 support and GLPI Network marketplace plugins. Check each plugin's license terms before planning, since free and subscription plugins can sit side by side. Installation services are a separate cost from these subscription fees.
What checks confirm a plugin installed correctly?
A correct installation shows the plugin as installed and active in GLPI, with its configuration pages loading and its database tables present. Engineers should also confirm that the plugin version matches the GLPI release, that file permissions match the web server user, and that the plugin behaves as expected for each profile and entity. Record the results in the change log so the next upgrade starts from a known state. Tell the reader to confirm these checks against the plugin's own documentation, because requirements differ by plugin.
How DeployOpen scopes and delivers GLPI plugin installs
DeployOpen plans, installs, hardens, backs up and documents GLPI plugins inside your own infrastructure, including networks that have no route to the internet. The work covers the decisions in this topic: whether a plugin is installed from the marketplace or by hand, which GLPI release it is matched to, where the plugin directory lives, and how the instance is backed up before any change. Every step runs on your servers or in your cloud accounts, so the plugin code, the database and the glpi.key and glpicrypt.key files never have to leave your environment for the work to be done.
Before work starts, the scope, deliverables and timelines are agreed in writing. A typical written scope lists the plugins in use, the GLPI version and PHP and database versions, the target environment (online, proxied or air-gapped), the plugin directory layout, the test instance and rollback steps, and the documentation handed over at the end. Ask for a quote built from that written scope, and check that it names who performs each step, what you must supply (such as an offline package archive or access to a staging server), and what is excluded. DeployOpen does not publish a price list, so the written scope is the basis for any cost you compare.
Plugin installs are rarely a single event. After handover, plugin versions must be rechecked against each GLPI update, and plugins are suspended after a new version is detected until they are reactivated, so someone must own that cycle. Ongoing upgrades, version matching and testing can be covered by a retainer, which is also agreed in writing. Before you commit, confirm with your team who will review plugin releases, who approves production changes, and how long you need an offline copy of each plugin package to stay available.
