GLPI Network Cloud vs self-hosted GLPI

GLPI Network Cloud removes most infrastructure work but limits LDAP, VPN, disk and automation options. Self-hosted GLPI gives full control of data and configuration, at the cost of running it yourself.

On this page

Which GLPI hosting model fits your team

Choose GLPI Network Cloud when your priority is a managed service with predictable subscription costs and your team does not want to patch, back up or monitor GLPI itself. Teclib' hosts and manages the instance on OVHcloud infrastructure with automatic updates and built-in backups, and its own GLPI Network subscriptions page recommends the cloud option for organizations wanting quick setup, minimal maintenance and predictable costs. Public Cloud is the lower-cost tier on shared resources, while Private Cloud runs on a dedicated server and adds the internal LDAP reach and IP filtering that the shared tier lacks. Before signing, confirm the limits that matter to you: the Public Cloud disk, attachment and inventory caps, and the availability and recovery commitments for the tier you pick.

Self-hosting fits a team that has specific security, network or customization requirements that a managed platform cannot meet, and that already has staff able to run the infrastructure. The GLPI installation docs describe the work involved: a PHP and MySQL or MariaDB stack, the web server document root pointed at GLPI's public directory, backups of the database, files and the glpi.key and glpicrypt.key files before each update, and php bin/console db:update after the code is replaced. Plugins are suspended after a new version is detected and must be reactivated after major updates, so plan that step into every upgrade window. Self-hosting also gives you control over LDAP and CAS reachability without a VPN workaround, and over the backup retention and recovery targets you define yourself.

Use the cloud and self-hosted models as a set of questions rather than a default. Ask Teclib' for the written availability, RPO and RTO commitments for your tier, the backup retention periods, and the data reversibility terms, which promise a complete copy of the MySQL database and attachments in a standard format within 30 calendar days of a written request. Then ask your own team whether it can meet the recovery targets you need, cover patching and on-call, and maintain any plugins you depend on. If the answers to the first set are acceptable and the second set is not, the managed route is usually the better fit; if your network rules forbid the hosted reach or your customizations need full control, self-hosting is the path, and the effort it adds should be costed in the planning phase.

How the two hosting models compare on the published terms

This table sets the published GLPI Network Cloud terms for Public Cloud and Private Cloud against running GLPI on your own servers. Read each row as a question to answer for your environment: where the cloud terms fit your network and recovery needs, and where your own infrastructure must cover the gap. Self-hosted costs depend on your own infrastructure and any GLPI Network subscription you choose.

CriterionGLPI Network Cloud (Public or Private)Self-hosted GLPI
Control and data locationTeclib' hosts and manages the instance on OVHcloud infrastructure, with system backups and archiving at the providers Teclib' listsYour servers, your data center or cloud account, and your choice of backup and archive locations
Pricing structurePublic Cloud at 19 euros per user per month on shared resources; Private Cloud at 21 euros per user per month on a dedicated server with a 25-user minimum, excluding taxYour own server, database, backup and staff costs, plus any GLPI Network subscription you select; confirm the total with Teclib' and your infrastructure team
Availability commitmentPublic Cloud 97% annual availability; Private Cloud 99% (GLPI Network subscriptions page)Set by your own design, redundancy and staffing; no vendor commitment unless you contract one
RPO and RTOPublic Cloud 24 hour RPO and 8 hour RTO; Private Cloud 1 hour RPO and 4 hour RTO; custom architectures quoted for RTO under one hourDefined by your own backup frequency and restore process; confirm targets against your business requirements
Backup retentionPublic Cloud daily backups kept 30 days; Private Cloud adds hourly incremental database backups kept 7 daysSet by your backup policy and storage; confirm retention and offsite copies meet your obligations
LDAP and CAS reachabilityLimited to publicly reachable LDAP and CAS servers on both tiersAny directory your network can reach, including internal LDAP and CAS servers
IPsec VPN access to internal LDAPAvailable on Private Cloud only; not available on Public CloudAvailable through your own network design; confirm the VPN and firewall setup with your network team
Disk, attachment and inventory limitsPublic Cloud: 5 GB disk, 20 MB attachments, 500 agents per hour; Private Cloud: 50 GB disk, unlimited inventorySized by the storage, PHP and database resources you provision
Automatic action frequencyPublic Cloud every 5 minutes; Private Cloud every minuteSet by your cron schedule and server capacity
Data reversibilityComplete copy of the MySQL database and attachments in a standard format within 30 calendar days of a written request, free of charge, during or after the contractFull control of the database, files and config keys, with exit steps defined by your own runbooks

What data location and access mean for compliance evidence

A compliance assessment asks where data lives, who can reach it and what records prove it. Under GLPI Network Cloud, much of that answer sits with Teclib' and its providers, while self-hosting moves the answer to your own team. The cards below cover what to request from each model before an assessor asks.

Provider locations for each data type

Teclib' publishes a provider split: OVHcloud for primary data, Acronis in Strasbourg for system backups and Scaleway in Paris for archiving. Each provider holds a different class of data, so an assessor may ask for the location of each one separately. Ask Teclib' to confirm these locations in writing for your tier, and check whether the list changes over the contract term.

Sub-processor terms and notice

Each provider in the chain acts as a sub-processor for your GLPI data, which affects your data processing terms and any transfer analysis your regulator expects. Ask Teclib' for the current sub-processor list, how it notifies customers of changes, and whether you hold a right to object. Self-hosting removes this layer, but your own hosting provider or data center still needs equivalent terms.

Administrative access in each model

On GLPI Network Cloud, Teclib' operates the platform, so the question is which Teclib' roles can reach your database, backups and attachments and how that access is logged. On self-hosting, your administrators hold root access to the server, database and the glpi.key and glpicrypt.key files. Map every privileged role in both models before comparing them.

Read-only database access and IP filtering

Private Cloud adds read-only MySQL access and IP filtering, which narrows who can query data directly. Public Cloud does not list these controls in the supplied terms. Confirm with Teclib' whether any administrative path bypasses these controls, and record the source address rules your assessor will test.

Backup copies and restore evidence

Backups live with the system backup provider, and retention differs by tier. Public Cloud keeps daily backups for 30 days, and Private Cloud keeps hourly incremental database backups for 7 days. Ask for restore test records, since a retention promise alone does not show that a backup restores. On self-hosting, you produce these records yourself.

Evidence you must produce yourself

DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Confirm the provider locations, sub-processor terms and contract clauses directly with Teclib' before you scope an assessment, and treat the answers as inputs your auditor will verify.

Which features each model gives you

Public Cloud runs on shared resources, and its feature set is the most constrained of the three models. LDAP and CAS connections are limited to servers that are publicly reachable, so a directory that sits only on your internal network cannot be used for sign-in or group sync. Disk space is capped at 5 GB, attachments at 20 MB and inventory at 500 agents per hour, and automatic actions run every 5 minutes.

  • Directory reachability: LDAP and CAS must be exposed to the public internet, which many identity teams will not accept.
  • Storage caps: The 5 GB disk limit and 20 MB attachment limit shape how much evidence and documentation you can store in the ticket flow.
  • Inventory throughput: The 500 agents per hour cap affects large rollouts of the GLPI Agent.
  • Automatic actions: Actions run every 5 minutes, which matters for escalations and reminders with tight timing.
  • No internal VPN path: IPsec access to internal directories is not offered on this tier.

Before choosing Public Cloud, confirm with Teclib' whether your directory and sign-in design can work with public reachability and whether the caps fit your ticket and inventory volume.

What your team runs in each model

This table lists the recurring GLPI tasks by owner in each model, so you can see what the Teclib' subscription covers and what stays with your team. Read the Network Cloud column for what Teclib' operates, and check each cell against the subscription terms before you sign, since scope details can change.

TaskGLPI Network CloudSelf-hosted GLPI
Hosting and infrastructureTeclib' hosts and manages the instance on OVHcloud infrastructureYour team provisions, secures and runs the servers, network and PHP and web stack
GLPI application upgradesAutomatic updates are included, but confirm timing and any plugin impact in writingYour team runs the update: back up the database, files, config and glpi.key and glpicrypt.key, replace files, run php bin/console db:update
Plugin reactivation after updatesConfirm with Teclib' how plugin compatibility is handledSince GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates
OS, PHP and database patchingCovered by the managed service; confirm the patch window and noticeYour team patches the OS, PHP (GLPI 12.0.0 README lists PHP 8.3 or later) and MariaDB or MySQL
BackupsBuilt-in backups: Public Cloud daily with 30-day retention; Private Cloud adds hourly incremental database backups kept 7 daysYour team designs, schedules and stores backups, including config keys
Restore testingAsk Teclib' how restores are tested and how often you may request oneYour team must test restores of database, attachments and config regularly
Recovery commitmentsPublic Cloud 24 hour RPO and 8 hour RTO; Private Cloud 1 hour RPO and 4 hour RTO (GLPI Network subscriptions page)Set by your own design; no vendor commitment applies
Monitoring and capacityTeclib' manages platform capacity; you manage disk, attachment and agent limits within the planYour team monitors CPU, memory, disk, database, cron and inventory load, and scales the stack
On-call and incident responseEscalate to Teclib' under the subscription support terms; confirm response timesYour team carries the on-call rota for outages, failed updates and restores

Moving GLPI between Network Cloud and your own servers

This sequence takes a GLPI instance from one hosting model to the other with the database, attachments, encryption keys, directory connections and agent endpoints all accounted for. It ends when inventory and automatic actions run correctly on the destination.

  1. Confirm reversibility terms in writing

    Before any move, ask Teclib' to confirm in writing the scope of the data reversibility clause, the format of the copy, and whether it applies during the contract and after it ends. Confirm which items are included: the MySQL database and GLPI attachments are the stated scope, so ask whether configuration files, plugin data and the glpi.key and glpicrypt.key files are covered. The step is done when the answers are on file and your team knows who requested the copy and when.

  2. Request the complete data copy

    Send a written request to Teclib' for a complete copy of the cloud data, which the reversibility clause describes as the MySQL database and GLPI attachments in a standard format. The clause states the copy is delivered within 30 calendar days of the written request and is free of charge. Record the request date and the delivery date, then verify the archive checksum and file count against what Teclib' provides. The step is done when the archive is received and checked.

  3. Rebuild the web and PHP stack

    On your own servers, build the web server and PHP stack for the GLPI version you run, following the installation prerequisites for your target release. Point the web server document root at GLPI's public directory rather than the installation root, and configure URL rewriting so requests route through index.php. Confirm the database engine matches the supported MySQL or MariaDB versions for that release, since GLPI supports only those two. The step is done when a blank GLPI install loads through the web server.

  4. Restore keys, database and attachments

    Restore the MySQL database and attachments from the cloud copy, then place the glpi.key and glpicrypt.key files in the config directory before starting GLPI. Without the original keys, encrypted values stored in the database, such as credentials, cannot be read. Check that the restored database version matches the GLPI version it came from, then run the database update with php bin/console db:update only if the release requires it. The step is done when administrators can log in and open a sample ticket, asset and attachment.

  5. Re-point LDAP, CAS and mail connections

    Reconfigure directory and mail connections on the new host, because Network Cloud restricts LDAP and CAS to publicly reachable servers unless you use Private Cloud with an IPsec VPN. On your own servers, LDAP can reach internal domain controllers directly, so confirm the bind account, base DN and group filters still match your directory. Test one login through each method, including the fallback order of database, LDAP and other external authentication. The step is done when every user group authenticates as expected.

  6. Re-point GLPI Agents and inventory endpoints

    Update the server address in each GLPI Agent configuration so endpoints report to the new host, and confirm the agent uses the correct certificate or trust settings for the new URL. Because the agent is the collector for hardware and software inventory, check a sample of machines from each network segment. Keep in mind that Network Cloud limits Public Cloud inventory to 500 agents per hour, so plan the rollout in batches if you move a large fleet. The step is done when test endpoints appear with updated inventory timestamps.

  7. Validate automatic actions and plugins

    Confirm that scheduled automatic actions run on the new host at the frequency you need, since Network Cloud limits Public Cloud to every 5 minutes and Private Cloud to every minute. Reactivate plugins after the update, because GLPI 11.0 and later suspend plugins when a new version is detected and they must be enabled again after major updates. Check mail collectors, notifications and SLA calculations. The step is done when a test ticket triggers its notifications and escalations on schedule.

  8. Close the cutover and retain the old copy

    Once validation passes, switch DNS or the public address, update the backup schedule on your own servers, and keep the cloud copy and the cloud subscription in place until your team has confirmed a full business cycle. Decide with Teclib' how long the cloud instance remains accessible during parallel running and what happens to its backups after the end of the contract. The step is done when the cutover is signed off, backups have run once on the new host and the retention arrangement is documented.

Questions buyers ask before choosing a GLPI hosting model

What drives the cost of GLPI Network Cloud compared with self-hosting?

On the cloud side, the published list prices are 19 euros per user per month for Public Cloud on shared resources and 21 euros per user per month for Private Cloud on a dedicated server, with a 25-user billing minimum, both excluding tax, according to the GLPI Network subscriptions page. Those fees recur monthly and cover hosting, updates and backups. On the self-hosted side, the subscription page lists GLPI Network tiers from 100 euros per month (Basic) to 4,500 euros per month (Enterprise), but you also pay for servers, storage, your team's time, and any outside help. Ask Teclib' or your reseller to confirm which items are included in each quote, including support level, Network-only plugins and instance counts. Ask DeployOpen for a fixed-scope written quote covering only the work you decide to outsource.

How long does a move between GLPI hosting models take?

The duration depends on data volume, the number of integrations, how many LDAP or CAS connections must be re-pointed, custom plugins, and how much testing your team requires before cutover. Public Cloud has a 5 GB disk limit and Private Cloud 50 GB, so a large attachment library or inventory history can change the plan. Teclib' publishes a 45-day free trial for its cloud offers, which gives you a window to test before committing. No timeline is published for a migration project, so ask Teclib' for its migration process and ask DeployOpen to define the timeline in a written scope before work starts.

Can an internal team run self-hosted GLPI without outside help?

Yes, if your team can handle the work that the cloud service otherwise takes on. Teclib' describes on-premise GLPI as suited to organizations with specific security and customization requirements and an IT team able to manage infrastructure and maintenance. Your team would own the web server, PHP, MariaDB or MySQL, backups, and the update procedure. That procedure requires a database, file and config backup (including glpi.key and glpicrypt.key), replacing 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 plan for that step. If your team lacks capacity for this routine, consider outside operations support on a retainer basis.

What do the GLPI Network Cloud RPO and RTO commitments cover?

The subscriptions page commits Public Cloud to a 24 hour RPO and an 8 hour RTO, and Private Cloud to a 1 hour RPO and a 4 hour RTO, with custom architectures quoted for RTO under one hour. These are recovery targets for the platform, not guarantees about your data integrity, your application configuration, or plugin behavior. Public Cloud backups run daily with 30-day retention, and Private Cloud adds hourly incremental database backups kept for 7 days. Confirm in writing whether a restore covers attachments, custom plugins, and your own configuration, and what happens when a restore is needed after a corrupted change made by your team. Also confirm the 97% and 99% annual availability figures and how they are measured.

Can LDAP stay on our internal network with GLPI Network Cloud?

Not on Public Cloud. On GLPI Network Cloud, LDAP and CAS connections are limited to publicly reachable servers. Private Cloud can reach internal LDAP over an IPsec VPN, and it also adds IP filtering, read-only MySQL access and a preproduction instance. If your directory is internal, Private Cloud is the published option to evaluate, and you should confirm the VPN setup, network ownership and who manages the tunnel. If you cannot expose a directory, self-hosting remains the simpler path for internal authentication, because GLPI tries the internal database, LDAP, IMAP and other methods in order. Test this with your own directory before signing.

How do I exit GLPI Network Cloud later without losing data?

Teclib' states a data reversibility clause: on a written request, it provides a complete copy of your cloud data, meaning the MySQL database and GLPI attachments, in a standard format within 30 calendar days, free of charge, during or after the contract. Before you rely on that clause, confirm the exact format of the database export, how attachments are packaged, and whether plugin data and custom configuration are included. Plan a test restore into your own environment, because a copy you cannot load is not an exit. If you move to self-hosting, your team or DeployOpen would need to rebuild the stack and reconfigure LDAP, mail, and integrations against the target platform.

Which GLPI version and database should a new self-hosted install target?

The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs 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. Use the requirements that match the version you choose, and confirm them against the GLPI installation prerequisites before provisioning. GLPI 12.0.0 was published on October 7, 2026, with 11.0.11 on October 1, 2026, so check whether your plugins are certified for the release you pick. Cloud customers do not make this choice; Teclib' manages the version.

What changes in your daily work after the choice

The biggest daily difference is who controls the change window. On GLPI Network Cloud, Teclib' runs the hosting, updates and built-in backups, so your team agrees timing and scope with the vendor rather than scheduling its own maintenance. On self-hosted GLPI, every update is your job: back up the database, files and the config directory including glpi.key and glpicrypt.key, replace the application files, and run php bin/console db:update. Plan that as a recurring window in your calendar, not a one-off project. Confirm with Teclib' how cloud maintenance windows are announced and whether you can hold a release for testing on the Private Cloud preproduction instance.

Plugin management is where the two models diverge most during the first year. GLPI 11.0 suspends plugins after a new version is detected and requires reactivation after major updates, so a self-hosted team should test each plugin against a copy of production before every upgrade and keep a rollback path. On cloud, the plugin set is limited to what Teclib' supports, so confirm early whether the plugins you depend on, including any GLPI Network marketplace plugins, are available on your tier. Inventory agent work also differs. The GLPI Agent runs on Windows, macOS and Linux and is deployed by your team on self-hosted GLPI, while cloud instances still need your endpoints to reach the service. Public Cloud caps inventory at 500 agents per hour, so an initial rollout across a large estate should be paced with that limit in mind.

Audit requests are where cost and control show up in the first year. Self-hosting gives you direct access to logs, configuration and the database, which helps when an assessor asks how access, authentication and backups are controlled, but it also makes you the owner of that evidence. On cloud, ask Teclib' in writing for the backup records, restore test results and access logs you will need, and check how they are delivered. Your model stays a good fit as the estate grows only while the people doing these tasks are available: a small team with a predictable user count often prefers the cloud model, while an organization with custom integrations, strict network placement or an IT team already running infrastructure usually stays comfortable self-hosting.

How DeployOpen scopes and supports self-hosted GLPI

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted GLPI inside the client's own cloud accounts, data centers or air-gapped networks. We do not operate Teclib' GLPI Network Cloud, so this work applies when the self-hosted route is the chosen option.

How we scope

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
  • The written scope lists which GLPI modules, authentication sources, inventory agents and plugins are in and out.
  • We confirm your PHP, MariaDB or MySQL, and web server versions against the GLPI release you intend to run.
  • Scope also records backup retention, recovery targets and who on your team owns patching and updates.

How we build

  • We install GLPI with the web server document root set to the public directory, following the vendor installation guidance.
  • We configure LDAP or other directory authentication, inventory through the GLPI Agent, and any GLPI Inventory plugin in scope.
  • We test backups by restoring the database, files and config directory, including the glpi.key and glpicrypt.key files.
  • We document the build so your team can reproduce the environment and review its security settings.

How we hand over

  • Handover includes runbooks for updates, covering the db:update step and reactivating plugins after new versions.
  • You receive configuration documentation, backup and restore procedures, and a record of the access and network paths used.
  • We walk your administrators through daily operations so the internal team can run GLPI without outside help.
  • Evidence for compliance assessments is prepared for your auditors, who issue any formal report or certification.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
  • Upgrade work covers backing up before each release, testing plugins and validating the instance after changes.
  • Security testing of the GLPI instance and its integrations can be scoped alongside support if you need it.
  • Ask any provider, including us, to confirm in writing which recovery targets, backup retention and support windows apply.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.