Self-hosted ServiceNow alternative for air-gapped networks: the short answer
If your network has no internet path, ServiceNow cloud is off the table and the service desk has to run entirely inside the boundary. Two paths are realistic. The first is ServiceNow Private Stack, where ServiceNow supplies the application software, upgrade packages, deployment guidance and support, while your team or a partner owns the load balancer, application server and database tiers. The second is a fully open-source GLPI install, where the platform, its database and its update process are all yours to operate, with optional commercial support from Teclib' if you want it. Neither path is simpler by default. The choice depends on who will operate the stack day to day, how software reaches the isolated side, and who answers when something breaks.
Upgrades are where the two paths differ most in practice. Private Stack updates arrive as ServiceNow packages that you carry across the boundary and install on infrastructure you run. With GLPI, you receive a new release, verify it, and apply it yourself. GLPI's update procedure requires a backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, followed by php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plugin owners need that step in their change plan. Confirm with each vendor how transfer packages are signed and verified, since that check is the control your supply chain policy will ask about.
Support is the question to settle before you commit. Private Stack starts with your ServiceNow account team, and customers should expect to buy a workshop covering architecture planning, hardware sizing, database selection and operational readiness. Ask for that scope, its deliverables and who on the vendor side owns each tier in writing. For GLPI, ask Teclib' what self-hosted support tiers exist, what response levels they commit to and whether they support air-gapped installs. Then ask your integrator to price the work of building, hardening and maintaining the stack, since that labor, not the software license, usually decides total cost.
What an air-gapped ITSM deployment must satisfy
An air-gapped service desk has to work with no internet path at all, which changes what runs, how software arrives and where records live. The four requirements below apply whether the choice is ServiceNow Private Stack or a fully open-source GLPI install, and each one is a question to settle before procurement.
No runtime internet dependency
The application, its plugins, its email and its authentication must all function with outbound internet blocked. Check every feature for calls to external services, including license checks, telemetry, hosted maps, remote fonts and update notifications. For GLPI, confirm that the web server, PHP extensions and any mail relay resolve only inside the boundary. Test the system with egress blocked before go-live, not after.
Controlled import of packages and updates
Everything that crosses the boundary, including application archives, PHP packages, container images and plugins, should enter through a logged, reviewed transfer process. Keep a internal mirror or artifact store and record the checksum of each item. Updates follow the same path, so the team must plan for the gap between a new release and its arrival inside the network. Confirm with your vendor how signed releases and checksums are published.
Database and file store inside the boundary
The database, uploaded documents, attachments and the configuration directory must all sit on storage you control inside the boundary. GLPI supports only MySQL and MariaDB, so confirm the versions your release requires. Keys such as glpi.key and glpicrypt.key are part of the state, not optional extras, and must be backed up with the database and files. Ask who holds the backups and where they are kept.
Authentication against internal directories
Users should sign in against your own directory services, not a hosted identity provider. GLPI tries its internal database, LDAP directories, IMAP mail servers and other external methods in a set order, so confirm which method resolves each account and what happens when the directory is unreachable. Plan local break-glass administrator accounts, and document how they are protected and audited.
Supply chain integrity for energy sector operators
If the network supports bulk electric system operations, NERC CIP-013-2 expects a documented procurement process that addresses verifying the integrity and authenticity of vendor software and patches. In practice, each package carried across the isolated boundary needs a recorded verification step before installation. Describe this control in your own words in your supply chain plan, and confirm its scope with your compliance team and the standard's text.
How ServiceNow Private Stack handles the isolated network
Private Stack puts the load balancer, application server and database tiers under the customer's or a partner's control, while ServiceNow supplies the application software, upgrade packages, deployment guidance and support. Formerly its self-hosted or on-premise offering, it is the closest ServiceNow option to an air-gapped estate, but the operating burden moves to your team. Before shortlisting it, map each tier to a named owner in your own organization or in a partner's contract, because the vendor's support does not replace the people who keep those tiers running inside an isolated boundary.
Entry starts with your ServiceNow account team, not a self-service download. Customers starting a Private Stack deployment should expect to buy a workshop covering architecture planning, hardware sizing, database selection and operational readiness. Ask the account team to put the workshop deliverables, the sizing assumptions and the database platform in writing, and ask which of them depend on connectivity you may not have. The workshop output is the document your infrastructure and security teams will be held to, so have them review it before any purchase commitment.
The supplied information does not confirm how software and upgrade packages reach an isolated network, how they are verified for integrity and authenticity, or whether any component calls out to ServiceNow during normal operation. Confirm these in writing with ServiceNow: the transfer method for upgrade packages, the process for checking them before they cross the boundary, the licensing check and any telemetry requirements, and the support path when a fault cannot be reproduced from inside the network. These answers determine whether your change control and supply chain controls, such as the software integrity checks described in NERC CIP-013-2, can be met.
Comparing Private Stack and self-hosted GLPI for isolated networks
This table compares ServiceNow Private Stack with a fully self-hosted GLPI install for networks without an internet path, across who operates each tier, licensing, upgrades, support and exit. Read each row as the question your operations team will have to answer, and treat the main takeaway as follows: Private Stack keeps ServiceNow's application and upgrade packages but leaves the infrastructure tiers with you, while GLPI moves more of the stack and the upgrade work into your own hands.
| Area | ServiceNow Private Stack | Self-hosted GLPI |
|---|---|---|
| Who operates the tiers | The customer or a partner runs the load balancer, application server and database tiers in its own data center. | The customer or its partner runs the web server, PHP runtime, database and file storage, all inside the isolated network. |
| License model | Commercial subscription sold through the ServiceNow account team; confirm scope, term and sizing in writing. | GPL-3.0 software with no license fee; cost sits in infrastructure, implementation and staff time. |
| Upgrade path | ServiceNow supplies upgrade packages and deployment guidance; the customer applies them to its own tiers. | Back up the database, files and the glpi.key and glpicrypt.key files, replace application files, then run php bin/console db:update. Plugins are suspended after a new version and must be reactivated after major updates. |
| Platform requirements | Set by ServiceNow's architecture and hardware sizing, confirmed in the workshop it requires before deployment. | GLPI 11.x requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. GLPI 12.0.0, released October 7, 2026, requires PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0 or later. |
| Database support | Database selection is part of the planning workshop; confirm supported engines with ServiceNow. | Only MySQL and MariaDB are supported. Confirm any other engine with Teclib' before planning. |
| Support source | ServiceNow provides application support; the customer or partner covers the infrastructure tiers. | Your own team or implementation partner for the install, with optional Teclib' support subscriptions for the GLPI software. |
| Offline image and package delivery | Confirm with ServiceNow how application packages are delivered across the isolated boundary and how each one is verified. | Pull and verify packages on a connected staging host before transfer. Use GitLab's offline guidance for repository and package handling where GitLab is part of the stack. |
| Kubernetes and container tiers | Not described in the launch material; confirm with ServiceNow whether containers are an option. | Use kubeadm to list and pull control plane images in advance and point kubeadm init at an internal registry if you run Kubernetes. GLPI also ships an official Docker image. |
| Exit | Moving off Private Stack means exporting records through ServiceNow's own export options and rebuilding workflows elsewhere. | Data stays in your database and file store, so exit means a direct database and file export into the next platform, with no vendor-side export step. |
Deploying GLPI inside an air-gapped boundary
This sequence moves GLPI from a connected staging network into an isolated enclave with a web server, database, authentication and a tested backup and update routine that your own staff can run without internet access.
Build the offline media set on staging
On a connected staging network, your build team downloads the GLPI release archive from the official GLPI releases page, verifies its checksum against the published value, and records the exact version (for example, the 11.0 or 12.0 line your team has chosen). The same team collects the PHP runtime, web server, database server and extension packages that GLPI's prerequisites page lists, using your operating system's offline package mirror. Store everything on approved, scanned media with a manifest listing each file and hash. Done when a second engineer can reproduce the manifest from the staging records and the checksums match.
Mirror PHP and database dependencies
Your platform engineers create a local package repository from the staged media so the target enclave can install PHP 8.2 or later (or 8.3 or later if you run the 12.0 line, as the README specifies), MySQL 8.0 or MariaDB, and the required PHP extensions. Confirm the exact minimums for your chosen GLPI version in the installation documentation before you freeze the media set, because the README and the install docs differ for GLPI 11.0. Test the install in a lab replica of the enclave. Done when a clean host installs every dependency with no outbound network traffic and the PHP and database versions match the documented minimums.
Configure the web server document root
Your web administrators set the virtual host document root to GLPI's public directory rather than the installation root, then enable URL rewriting so all requests route through index.php. The docs cover Apache, Nginx, lighttpd and IIS, and your standard hardening baseline (TLS certificates from your internal CA, restricted file permissions) applies. Keep the config directory and the key files outside the web-readable path. Done when a browser on the internal network reaches the GLPI login page over HTTPS and a direct request to a file in the installation root returns an error rather than content.
Connect authentication to LDAP or the database
Your identity team decides whether users sign in against the internal GLPI database, an LDAP directory inside the enclave, or both. GLPI's user documentation says it tries authentication sources in a fixed order (internal database, LDAP, IMAP and other external methods), so confirm that order on your version before you rely on fallback accounts. Create a break-glass administrator in the internal database and record it in your credential vault. Done when a test user from the directory signs in, a disabled directory account is refused, and the break-glass account works with its MFA or access controls as your policy requires.
Inventory assets with GLPI Agent offline
Where endpoints sit inside the enclave, your endpoint team installs GLPI Agent from packages carried on the offline media set. The agent collects hardware and software inventory and can send it to the GLPI server on the internal network, so no cloud path is needed. Confirm which discovery and deployment features your team plans to use, because the agent documentation describes several capabilities and each has its own configuration. Done when a sample Windows, Linux or macOS host appears in GLPI's asset inventory with its hardware and software records.
Set the backup and restore routine
Your database and operations team schedules database dumps, a copy of the GLPI files, and a copy of the config directory, including glpi.key and glpicrypt.key. Losing those keys can make encrypted data unreadable, so store them separately from the database backup under the same access controls. Write a restore runbook and test it on the lab replica. Done when a restore into the lab reproduces a working GLPI instance with the same tickets, assets and logins, and your team has recorded the restore time it observed.
Run the documented update procedure
Each release follows the same order in the installation docs. First, back up the database, the files and the config directory, including glpi.key and glpicrypt.key. Second, replace the application files with the new version from the offline media set. Third, run php bin/console db:update from the GLPI directory. Since GLPI 11.0, plugins are suspended when a new version is detected, so your administrator reactivates each plugin after a major update and retests it. Done when the lab replica completes the same steps, the version shown in the admin console matches the target, and every required plugin is active and passes a smoke test.
Document ownership and the upgrade calendar
Your service owner writes who runs backups, who approves a release, who reactivates plugins, and who carries the next media set across the boundary. Each new GLPI release, such as the 12.0.0 line published on October 7, 2026, needs a fresh offline media set and a lab rehearsal before production. Confirm with Teclib' or your support provider which support tier covers your enclave. Done when the runbook names an owner for each task, and an approver has signed off on the first production update.
How upgrades and support cross an air gap
Every patch that enters an air-gapped network is a controlled transfer, and the two options handle that transfer differently. With ServiceNow Private Stack, ServiceNow supplies the application software and upgrade packages, while your team or partner owns the load balancer, application server and database tiers that receive them. With GLPI, you fetch the release yourself from the GLPI releases page, validate it on a staging copy, and carry it across the boundary on your own media. Whichever path you choose, write down who performs each transfer, who signs off on the import, and where the transfer record is kept. NERC CIP-013-2 is a useful reference here because it expects procurement processes to address verification of software integrity and authenticity for vendor software and patches, and the same discipline applies to any regulated isolated network.
Integrity verification is the step most often skipped. For GLPI, confirm the download against the checksums or signatures the project publishes for that release before it crosses the boundary, then back up the database, the files and the config directory, including glpi.key and glpicrypt.key, before running php bin/console db:update. Losing those key files can make encrypted data unreadable, so store them separately from the application archive. Plugins need separate attention: since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so schedule plugin revalidation as part of every major upgrade, not as an afterthought. Ask Teclib' or your plugin authors which plugins have a version compatible with the target release before you start.
The support gap is where contracts matter most. Teclib' sells self-hosted subscriptions in tiers from Basic to Enterprise, with level 3 support included on Enterprise according to the GLPI Network subscriptions page, so you can buy a support level that matches your staffing. ServiceNow support for Private Stack is governed by your contract with it, and its launch material describes deployment guidance and support as part of the offering. Neither vendor's support can reach into a network with no internet path unless the transfer and remote-access arrangements allow it, so ask each vendor how a support engagement is delivered across your boundary. Before signing, confirm response times, severity definitions, escalation paths and who may open tickets, in writing, and check whether the commitment covers the exact version you run.
Evidence auditors and regulators ask for
An isolated network keeps its ITSM platform out of reach of the internet, so the evidence has to show what crosses the boundary, who approved it and how the platform is operated. DeployOpen prepares these records as part of implementation, while independent auditors or certification bodies decide whether they meet the applicable requirements.
Boundary network diagram
A current diagram of the isolated boundary shows every system inside it, the transfer points where media or approved file paths cross in, and each data flow that leaves or enters the GLPI stack. For OT-adjacent sites, NIST SP 800-82 Rev. 3 gives useful context on segmenting operational networks without quoting its controls. Check that the diagram lists the web server, PHP runtime, database and agent endpoints, and that it is reviewed whenever the topology changes.
Transferred package register
Every installer, plugin, database update or rule set carried across the boundary needs a register entry with its file name, cryptographic hash, source, approver and transfer date. This is the evidence that supports verifying software integrity and authenticity before installation, the control NERC CIP-013-2 addresses for vendor software and patches. Confirm that the approval step is separate from the person who performs the import.
Backup and restore test records
A backup that has never been restored is not evidence of recovery. Keep dated restore tests for the database and the files, plus the config directory that holds the GLPI key files, since a restore without them can fail. The GLPI update procedure requires these backups before each upgrade, so the same records can show that step was performed. Confirm the target recovery time with your own continuity plan.
Access logs and admin session controls
Auditors look for who signed in, from where and what administrative changes they made. 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. Export and retain the authentication and audit logs from the web server and GLPI, and test that a revoked session is actually refused. Confirm how long your retention policy requires these logs to be kept.
Upgrade change records
Each upgrade needs a change record listing the target version, the approval, the test results in a staging copy, the rollback plan and the plugins reactivated afterward. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so those steps belong in the record. Keep the release notes and checksums for the version installed alongside the change ticket.
Questions buyers ask about air-gapped ITSM
Does GLPI work on a fully air-gapped network with no internet at all?
GLPI can be installed and run on a network with no internet path, because it is GPL-3.0 software that you carry in on approved media and host on your own servers. The core application, web server and database run locally. Before you commit, confirm which optional features reach outside the network:
- Plugin installation and updates, since plugins may be fetched from an external source
- GLPI Agent update and package channels on endpoints
- Time synchronization, mail relay and LDAP or IMAP authentication, if you use them
Each of these either needs an internal substitute or a manual transfer step. Document the transfer process and the checks you run on each package before it crosses the boundary.
What drives the cost of ServiceNow Private Stack versus self-hosted GLPI?
The two paths differ mainly in who pays for the software. With Private Stack, you pay ServiceNow for the subscription, which is quoted through the account team, plus the workshop on architecture, hardware sizing, database selection and operational readiness, and the hardware and database licenses for the load balancer, application and database tiers you run. With GLPI, the software license is zero, so the costs are hardware, staff, implementation and an optional support contract. GLPI's published self-hosted subscriptions from Teclib' run from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), according to the GLPI Network subscriptions page. Treat those as a reference point, since support is optional. Hardware and implementation are mostly one-time costs, while subscriptions, staff time and patching recur.
How long does an air-gapped ITSM deployment take?
The timeline depends on the scope, and no fixed duration applies to every network. The main drivers are hardware lead time, the number of environments (production, test and disaster recovery), the volume of records to migrate, how many integrations and plugins you need, and how long your security team takes to approve each media transfer. Private Stack adds the workshop and its scheduling to the path before build work starts. For GLPI, the largest variable is usually the migration and workflow rebuild rather than the install itself. Ask for a schedule with named milestones in the written scope, and ask which steps depend on your own approvals.
What does an air-gapped ITSM project need from our own team?
You need people who own the infrastructure, the data and the process. Expect the following roles to be involved:
- Infrastructure staff for servers, load balancers, storage and backups
- Database administrators for MariaDB or MySQL, which GLPI supports
- Web and PHP administrators, since GLPI requires a recent PHP version and a web server pointed at its public directory
- Security staff to verify packages before transfer and to approve access
- Service owners who define incident, change and asset workflows
For GLPI updates, the documented procedure requires backing up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, then running php bin/console db:update. Plugins are suspended after a new version is detected, so assign someone to reactivate them.
Can our team run an air-gapped GLPI or Private Stack installation alone?
Your team can run either option alone if it already has skills in Linux, databases, web servers and ITSM process, and if it can sustain on-call and patching work. Private Stack operations include three tiers that you own, so the team must be able to maintain them. GLPI is simpler to inspect, because the source and documentation are public, but the team takes on configuration, upgrades, backup and security hardening. If you lack capacity in one area, DeployOpen can plan, implement, harden, back up, document and support self-hosted platforms inside your own infrastructure. Its engagements are fixed-scope, with scope and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
What should we confirm with ServiceNow's account team about the workshop and offline upgrades?
Ask the account team to confirm five things in writing before you commit:
- Whether the architecture, sizing and readiness workshop is mandatory, what it covers, and what it costs
- How upgrade packages and deployment guidance reach a network with no internet path
- How ServiceNow lets you verify the integrity and authenticity of each package before it enters the network
- Which tiers ServiceNow supports, and which failures you handle without its help
- What data and configuration you can export at exit
The ServiceNow Private Stack launch post describes the model, but offline upgrade mechanics and support boundaries need confirmation in your own contract.
How do we verify software packages carried across an isolated boundary?
Set a documented verification step for every package, update and plugin that crosses into the network, and tie it to your compliance obligations. For utilities subject to NERC CIP, the supply chain control CIP-013-2 requires procurement processes that address verification of software integrity and authenticity for vendor software and patches. Confirm with your compliance lead which controls apply to your environment, and whether CIP-005-7 governs any remote access paths to the system. Record the checksum or signature checks, the approver and the date for each transfer. Independent auditors assess whether these controls work, so keep the evidence they will ask for from the start.
How DeployOpen deploys an open-source service desk inside an air gap
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a GLPI service desk, that means scoping the offline build, the database and web tiers, and the evidence trail before any installation begins.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm which ITSM modules, CMDB data and authentication sources the air-gapped GLPI instance must support.
- We map the transfer path for software packages, container images and updates across the isolation boundary.
How we build
- We prepare the PHP, MariaDB or MySQL, and web server stack from offline media, checking versions against the GLPI documentation.
- We configure the web server document root, URL rewriting and the secrets that GLPI requires to be backed up.
- We test the build for ticketing, asset inventory, LDAP or other authentication, and the update path before go-live.
How we hand over
- We document the offline install, update and plugin reactivation steps so your team can repeat them without us.
- We write backup and restore runbooks covering the database, application files and key files in the config directory.
- We prepare the operational records and control evidence that your internal teams or independent auditors may request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We plan each offline upgrade cycle, including verifying every package carried across the boundary before it is installed.
- We confirm with your team which support tier your organization needs from Teclib' or other vendors before relying on them.
