How GLPI can hold a cloud VM inventory alongside on-premises assets
Cloud instances run outside your data center, so an asset register built from on-premises discovery alone misses them. The Cloud Inventory plugin for GLPI is the supported way to bring instances from public cloud providers into GLPI, and it does this through the plugin's own scheduled synchronization rather than through a custom connector written for your environment. Each sync cycle calls the provider's API with credentials you supply, reads the instances in the accounts or subscriptions you have authorized, and writes them into GLPI as computer-type assets so they sit beside the hardware and virtual machines your agents already report. Because the plugin is the collection layer, the design question is what it should be allowed to see and how often it should look.
The boundary to plan for is between what the plugin collects and what GLPI decides. The plugin gathers instance attributes such as identifiers, names, states, and reported configuration. GLPI rules then decide what happens to that data: which entity an instance belongs to, how it is classified, whether it is linked to an existing record, and whether it is refused or ignored. Define these rules before the first full sync, because an unfiltered import can create large numbers of duplicate or out-of-scope records that are costly to clean up later. Ask who owns each cloud account, which entities should receive its instances, and how instances that have been terminated will be marked over time.
Provider coverage, required API permissions and plugin versions must be confirmed in the Cloud Inventory plugin's own documentation for the GLPI version you run, since support for each provider can change between releases. Check the read-only permissions the plugin requests in each cloud account and record them in your access review. DeployOpen scopes this work in writing before any credentials are configured, so the list of providers, accounts, entities, rules and dashboards is agreed up front and changes go through the same written scope.
What you need before connecting cloud accounts to GLPI
Cloud VM inventory is only as reliable as the GLPI platform, credentials and network paths behind it. Settle the GLPI version, the matching plugin release, identities, routes and ownership before the first sync so that failures trace back to one known cause.
GLPI version and database baseline
GLPI 11.0 requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. GLPI 12.0.0, released October 7, 2026, raises the floor to PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Only MySQL and MariaDB are supported, so confirm your database engine and PHP build against the target version before you install anything. Check the exact version pair on the server you will use for the sync, not just the one in your design document.
Plugin version matched to GLPI
Install the Cloud Inventory plugin release that is certified for your GLPI version, and confirm that compatibility in the plugin's own release notes before upgrading either side. Plugin compatibility is the most common reason a sync stops after an otherwise healthy GLPI upgrade. Record the plugin version in your change log so that a later GLPI update has a known pairing to test against.
Read-only identity per provider
Create a dedicated, read-only identity in each cloud account (AWS, Azure, Google Cloud, OVHcloud, Scaleway and Alibaba Cloud). Do not reuse administrator keys or a personal login. Confirm the exact permissions each provider needs in the plugin documentation, then test them with a non-production account first. Store the credentials in your secrets tooling and document who can rotate them.
Outbound paths from the GLPI server
The GLPI server must reach each provider's API endpoints over HTTPS. Map the egress path for every account, including any corporate proxy, NAT gateway or firewall rule that governs it, and check whether a provider region or endpoint is restricted by your policy. Test name resolution and TLS from the actual GLPI host, because a sync that works from a laptop can still fail on the server.
A named owner per cloud account
Assign one accountable person to each cloud account or subscription, with a backup contact. The owner approves which regions, projects or tags are in scope, receives credential rotation requests and decides how orphaned instances are handled. Without a named owner, stale instances stay in GLPI as if they were still running, and nobody can explain a missing or duplicated asset.
Verified backup before plugin install
Take a backup of the GLPI database, the files directory and the config directory, including the glpi.key and glpicrypt.key files, before installing or enabling the plugin. The plugin writes new tables and asset records, and restoring without the original keys can leave encrypted credentials unreadable. Test the restore on a copy so that you know the rollback path works before you need it.
Configuring the Cloud Inventory plugin in sequence
This sequence takes cloud VM inventory from a safe GLPI baseline to scheduled synchronization with asset rules. Each step ends with a check against the cloud provider's console, so the team knows the data is right before automation runs unattended.
Confirm GLPI and plugin compatibility
The platform engineer checks the GLPI version in use against the Cloud Inventory plugin's published compatibility notes and the GLPI prerequisites for PHP and the database. Confirm the plugin release matches your GLPI major version before anything else, because a mismatch is the most common reason an install stalls. Done when the target versions are written in the change record and the database engine is MariaDB or MySQL, the only supported options for GLPI 11.0 according to the installation prerequisites.
Back up database, files and config keys
The GLPI administrator takes a full database dump, a copy of the GLPI files and the config directory, including the glpi.key and glpicrypt.key files. Without the key files, encrypted values such as stored credentials cannot be read after a restore, so store them with the other backups in a separate location. Done when a restore has been tested on a non-production copy and the backup set is confirmed as complete.
Install and activate the plugin
The GLPI administrator copies the plugin into the plugins directory, runs the install from the plugin page and activates it. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so check the plugin list after every GLPI upgrade. Done when the plugin shows as active, its configuration page opens without errors and the GLPI logs show no failed plugin hooks.
Create scoped read-only cloud credentials
The cloud administrator creates one read-only identity per cloud account, limited to listing and describing compute instances and their metadata. Each account gets its own credential so that a leak, rotation or revocation affects one account at a time. Done when each credential has been tested with a direct call to the provider's API from a管理 workstation and returns instance lists only, with no write permissions present.
Add accounts in a test entity
The GLPI administrator creates a dedicated test entity and adds each cloud account there, entering the scoped credentials and the region list to scan. Using a separate entity keeps test imports away from production asset records and makes them easy to clean up. Done when each account shows a successful connection status in the plugin and the stored credentials do not appear in plain text on any configuration screen.
Run one manual sync and compare counts
The GLPI administrator runs a single manual synchronization for each account and records the number of imported instances. The platform engineer compares those counts with the instance lists in the provider console for the same accounts and regions, noting any instances in stopped, terminated or unusual states. Done when the counts match per account and region, and every mismatch has a recorded explanation before the next step.
Test asset rules on sample instances
The GLPI administrator reviews the asset rules that map cloud instances to asset types, locations and entities, then applies them to a few sample instances from the test sync. Sample instances should include at least one from each provider and one with unusual tags or naming, so the rules are exercised on real variation. Done when each sample lands in the expected entity and asset type, and the rule results are signed off by the asset owner.
Enable schedule and production rules
After the test results are accepted, the GLPI administrator moves the accounts to the production entity, enables the scheduled sync and activates the asset rules. The first scheduled run is then checked against the provider console, and the GLPI automatic actions log is reviewed for errors. Done when the first scheduled run matches the expected counts and the dashboards show the inventory for each account.
How cloud instance attributes map to GLPI assets
This table lists the provider attributes a cloud instance sync typically brings into GLPI, the asset type and entity each one usually lands in, and who owns the decision. Read it as a checklist to confirm in the plugin for each provider, because field availability differs between AWS, Azure, Google Cloud, OVHcloud, Scaleway and Alibaba Cloud. Tags are the usual key for entity assignment, so treat that mapping as the first decision to settle.
| Attribute | Target GLPI asset or field | Entity and ownership | What to confirm |
|---|---|---|---|
| Instance ID | Computer record, unique identifier used for matching on re-sync | Team owns; keys updates so duplicates are not created | Confirm the ID is stable across stop and start for each provider |
| Name | Computer name | Team owns; often reviewed with the cloud account owner | Confirm whether the provider name tag or the instance hostname is used |
| Region or zone | Location or custom field on the computer | Team owns; can drive entity placement by geography | Confirm how each provider reports zones versus regions |
| Instance type | Model or custom asset type attribute | Team owns; feeds sizing and cost reports | Confirm naming differences between providers for the same size class |
| State (running, stopped, terminated) | Status field used by reports and retirement workflows | Team owns; decides when a record is marked inactive | Confirm how terminated instances are reported and how long they remain visible |
| Operating system | Operating system name and version on the computer | Team owns; may need normalization across providers | Confirm whether the provider reports image or detected OS |
| IP addresses (private and public) | Network port records on the computer | Team owns; relevant to security and exposure reviews | Confirm which address types each provider exposes to the plugin |
| Tags or labels | Input to import and entity assignment rules | Key decision: the usual basis for routing instances to an entity | Agree a tag taxonomy with cloud owners before the first sync |
| Account or project | Entity or custom field identifying the cloud account, subscription or project | Team owns; maps each cloud account to a GLPI entity or scope | Confirm the account identifier format for each provider and multi-account layout |
| Creation or last-seen time | Last synchronization date and provider creation field | Team owns; drives stale record cleanup | Confirm which timestamps each provider returns and how the plugin stores them |
Why scheduled sync and asset rules decide data quality
Collection and classification are separate jobs, and most data quality problems come from confusing them. The Cloud Inventory plugin collects instance data from each provider on a schedule. It does not decide what an instance is in GLPI. Entity assignment, asset type and whether a cloud instance is recorded as a computer, a virtual machine or a custom asset type are set by the rules that run after collection. Before you connect a single account, write down the target for each provider and account: which entity owns the instance, which asset type it becomes, and what happens when a rule matches nothing. Then confirm the rule options the plugin documents for these decisions, since the exact conditions and actions available depend on the plugin version you deploy.
Scheduled sync also creates a retirement problem. An instance that is terminated in the cloud does not disappear from GLPI on its own. Decide in advance how a missing instance is marked, how long it stays in the inventory before it is retired, and who approves the change. The same question applies to instances that were never reported as terminated but stopped appearing in a region or account. Duplicates are the other common failure. When GLPI Agent is installed on a VM that the cloud sync also reports, the same machine can arrive from two sources with different identifiers. Check how the plugin and the agent identify a host, such as by instance ID, hostname or serial number, and test a VM that has both sources before you roll out rules across all accounts.
Test rule order with real instances, not sample data. Rules are evaluated in sequence, so an early rule that matches too broadly will decide the outcome for instances a later, more specific rule was meant to catch. Build a test set from a few accounts that covers each provider, a stopped instance, a terminated instance, an instance with an agent and one without, and an instance in a second entity. Run the sync against that set, review where each record lands, and only then widen the scope. Keep the rule set under version control so each change can be traced and reverted, and repeat the test set after each plugin or GLPI upgrade.
Securing cloud credentials and inventory data in GLPI
A cloud sync gives GLPI standing read access to every account it covers, and the inventory it stores maps those accounts in detail. The controls below cover the identities GLPI uses, how it stores their secrets, how administrators change sync settings and how failures surface.
Read-only identity per account
Create one read-only identity per cloud account that GLPI syncs, and grant only the read permissions the Cloud Inventory plugin documentation lists for that provider. Do not reuse a shared administrator key, a root account key or an identity that also deploys workloads. Separate identities keep a leak contained to one account's inventory. Confirm the exact permission list for AWS, Azure, Google Cloud, OVHcloud, Scaleway and Alibaba Cloud before you issue keys, because the lists differ by provider.
Protect stored credentials and key files
GLPI keeps the cloud API credentials in its database, so their protection depends on the instance's encryption keys. Back up and protect glpi.key and glpicrypt.key in the config directory as you would any production secret, and keep them out of the web root. Limit read access on the config directory to the service account and administrators. If the keys are lost without a backup, stored credentials may become unreadable, so test a restore before you depend on it. Confirm with the plugin documentation where it stores credentials.
Rotate and revoke keys on a schedule
Set a rotation interval for each cloud key and record its owner and expiry date. A safe sequence is to create the new key in the provider, add it to the plugin for one account, run a manual sync to confirm it works, then disable the old key. Wait through a full sync cycle before you delete it. When staff leave or a key may be exposed, disable the key first and rotate afterward. Confirm whether the plugin caches credentials until the next sync, since that affects how fast a revocation takes effect.
Restrict who sees cloud account records
Cloud account records are sensitive, because they show account identifiers and the instances running in each account. Use GLPI profiles and entities to limit which technicians can view cloud account objects and their imported inventory. Grant edit rights only to the small group that maintains sync settings. Pair this with the authorization rules that assign imported instances to the right entity. Check that saved searches, reports and dashboards do not expose these records to broader profiles.
Harden sync administration in GLPI 12
GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, plus step-up authentication for certain administrative actions. Changing a cloud account's credentials, schedule or import rules can redirect where inventory lands, so treat those screens as administrative actions. Confirm which actions the release covers, enable step-up authentication for sync configuration where it applies, and revoke sessions belonging to departed administrators.
Review sync errors and plugin state
Failed cloud syncs fail quietly unless someone reads the logs. Review sync errors on a fixed schedule, and treat repeated authentication or permission errors as a sign of a revoked, expired or over-scoped key. After any GLPI upgrade, confirm the Cloud Inventory plugin is active. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so a suspended plugin stops sync without an obvious alarm. Confirm where the plugin writes its logs and whether it can send failure notifications.
Why cloud instances are missing, duplicated or stale in GLPI
This table lists the failures most often seen when cloud instances reach GLPI through the Cloud Inventory plugin, with the likely cause and the first check to run for each. Work down the rows in order when a sync looks wrong, because several symptoms share a root cause such as credentials or scope. Confirm each check against your own GLPI logs and provider console before changing any rule or configuration.
| Symptom | Likely cause | First check |
|---|---|---|
| Sync fails with an authentication error | The provider credential lacks a read permission needed to list instances in the account, subscription or project | Test the same credential directly against the provider's API outside GLPI and confirm which read permission the error names |
| Instances from a region or project never appear | The region, zone, subscription or project was not added to the sync configuration | Compare the list of regions or projects in the plugin configuration with the locations where your instances run |
| The same instance appears twice | GLPI Agent and the Cloud Inventory plugin each created a record for one machine, so the two records do not match on the same identifier | Check whether the agent is installed on the instance and compare the serial number, UUID and name fields of both records |
| Terminated instances stay active | No retirement rule moves records for instances that no longer exist at the provider | Confirm the instance state returned by the provider sync and check whether any rule changes the asset status when an instance disappears |
| Plugin shows as inactive after a GLPI update | Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates | Open the plugin list in the GLPI administration area and reactivate the Cloud Inventory plugin before testing sync |
| Instances land in the wrong entity | Tags used by the entity assignment rule are missing or spelled differently across instances | Export the tags for a sample of instances from the provider and check the key and value spelling against the rule conditions |
| Newly launched instances are delayed | The scheduled sync interval has not yet run, or the task is disabled | Check the last run time and status of the scheduled task in GLPI before adjusting any rule |
Questions buyers ask before connecting cloud accounts to GLPI
What drives the cost and effort of bringing cloud VMs into GLPI?
The effort follows the shape of your cloud estate and how clean you need the data to be. The main drivers are the number of cloud accounts and subscriptions, how many providers are involved, how many asset rules you need to route instances into the right entities and asset types, how much existing asset data must be cleaned up or matched, and how many test cycles your team wants before switching on scheduled sync. Each of these adds configuration, review and validation work. Ask any partner for a quote that lists each account, provider and rule set as a separate line, and that states which test cycles are included and which are optional. Costs are mostly one-time for the build, with recurring effort for rule changes when new accounts or instance types appear.
Can our own team set up cloud inventory in GLPI without a partner?
Yes, a team can do this in-house if it has two things: people who own GLPI administration, including plugin installation, entities, profiles and rules, and people who own cloud identity and access management for each provider you plan to connect. The plugin's own documentation is the starting point for configuration. The in-house risk is usually not the first sync but the ongoing work: keeping credentials scoped, reviewing what the rules assign, and testing again after GLPI or plugin upgrades. Decide early who signs off on asset types and entity assignment, because those decisions are hard to reverse once inventory data exists in GLPI.
How long does a cloud inventory project take?
Duration depends on the scope agreed in writing before work starts, so there is no standard timeline to quote here. The scope should name the cloud accounts, the providers, the entities that will receive assets, the number of rule groups, and whether dashboards and data cleanup are included. A small, single-provider setup with one entity moves much faster than a multi-account estate with several providers, approval steps and legacy asset records to reconcile. Ask for a schedule with milestones for test sync, rule review and production sync, and confirm which of these steps depend on your change windows or approvals.
What do we need to provide before the work starts?
The work needs a short list of inputs from your organization before anything is configured. Expect to provide:
- Named owners for each cloud account or subscription, who can approve credential creation and answer questions about tags and ownership
- Read-only credentials or roles for each provider, scoped to the inventory data the plugin needs, not to administrative access
- A test entity in GLPI where first syncs land, so rules can be checked without touching production asset records
- A decision on which asset types instances should become, and which entity should own each account's assets
Having these ready early shortens the test cycle and reduces rework in the rule set.
Does the plugin cover every cloud provider we use?
Do not assume full coverage. The provider list in scope for this topic includes AWS, Azure, Google Cloud, OVHcloud, Scaleway and Alibaba Cloud, but the depth of data collected, the authentication method and the supported resource types can differ by provider and by plugin version. Confirm each provider against the plugin documentation and your installed version before you commit to a design. For any provider where the documentation is unclear, test with one read-only account in a test entity and inspect what arrives in GLPI before you plan the rest of the estate.
How do dashboards and reports depend on the asset rules?
Dashboards and reports are only as reliable as the rules that classify each instance. If an instance lands in the wrong entity, gets the wrong asset type, or is duplicated because a rule did not match an existing record, every chart built on that data inherits the error. Before building dashboards, review rule order, check how instances are matched to existing assets, and confirm that tags or naming conventions used by your teams map to the entities and types you report on. Plan a periodic review of rules after new accounts, instance families or GLPI upgrades are added, since a rule that worked last quarter can silently stop matching.
Who can see cloud inventory data once it is in GLPI?
Visibility in GLPI is controlled by profiles, entities and access rules, so cloud instances are only as visible as the entity they land in. Map each cloud account to an entity that matches the team responsible for it, and confirm which profiles can view, edit or delete those assets. Cloud inventory often contains IP addresses, instance names and tags that reveal internal structure, so treat it as sensitive operational data. Check that credentials used for sync are stored and rotated under your own policy and that only the GLPI administrators who need them can read them.
What happens to cloud inventory when GLPI or the plugin is upgraded?
Upgrades can change how plugins load and how data is stored, so cloud sync should be part of your upgrade test plan. Before updating, back up the database, files and configuration keys as the GLPI update procedure describes. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so schedule time to reactivate and verify the Cloud Inventory plugin, run a test sync, and confirm that rules still match expected instances before you return to scheduled sync in production.
How DeployOpen scopes and delivers cloud inventory in GLPI
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For cloud VM inventory, we start from the cloud accounts, regions and asset rules your organization needs, then build and hand over a sync design that your team can run.
How we scope
- Every cloud provider, account, subscription and region in scope is listed in the written scope before work starts.
- The scope records which instance attributes must reach GLPI and which asset types and entities they should map to.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and quotes follow from that written scope.
How we build
- We set up the GLPI instance and the Cloud Inventory plugin in your infrastructure, with read-only credentials for each cloud account.
- We configure scheduled sync intervals and asset rules, then test them against sample accounts before enabling the full scope.
- We build the dashboards and reports your teams requested and check that retired instances are handled as the scope defines.
How we hand over
- You receive configuration records for credentials, sync schedules, rules and dashboards, with the reasons behind each decision.
- Runbooks describe how to add an account, rotate credentials, review failed syncs and confirm that inventory data is current.
- Knowledge transfer sessions with your platform and cloud teams cover the operational tasks you will carry out after handover.
How we support
- Ongoing support, plugin and GLPI upgrades, and continuous testing are available as retainers after handover.
- Upgrade planning covers GLPI releases and plugin compatibility, including the plugin reactivation steps that follow major updates.
- We review sync logs, rule changes and new cloud accounts with your team so inventory keeps matching your cloud estate.
