ServiceNow Private Stack vs self-hosted open-source ITSM

Is ServiceNow Private Stack the right ServiceNow alternative for an air-gapped or sovereign ITSM?

If a renewal, a residency rule or an air-gap requirement is pushing you off ServiceNow cloud, Private Stack keeps the ServiceNow platform on your own hardware, but your team or a partner operates the load balancer, application and database tiers. Self-hosted GLPI or iTop removes the ServiceNow subscription and changes the upgrade model, because you then own the application software, its patching and its database as well. Both paths keep the service desk inside your boundary, so the deciding question is less about feature coverage and more about who will run the stack for the next several years.

Private Stack starts with your ServiceNow account team. The launch material indicates that customers should expect to buy a workshop covering architecture planning, hardware sizing, database selection and operational readiness, as described in the ServiceNow Private Stack launch post. Ask for that scope in writing, along with which party supplies upgrade packages, who handles tier failover and what support covers the infrastructure you own. For GLPI, the equivalent questions are about the PHP and MariaDB or MySQL versions your environment can support, the web server configuration, and who applies each release and reactivates plugins after a major update.

DeployOpen plans, implements, hardens, backs up and documents either path inside your own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing before work starts. We do not issue audit reports or attestations. Independent assessors do that work, so we prepare the systems, controls and evidence they will examine. Before choosing, write down who will own patching, backups and on-call response for each tier, and get that answer from your vendor and your own staff, not from the feature list.

What sovereign and air-gapped constraints require from an ITSM platform

Sovereign and air-gapped networks change what an ITSM platform must do before any feature comparison starts. The cards below cover the requirements that decide whether ServiceNow Private Stack or a self-hosted open-source service desk fits your environment, and what to confirm with your auditor or regulator.

Offline runtime and updates

With no internet path, every runtime dependency, package and update must be staged inside the boundary. Under Private Stack, ServiceNow supplies upgrade packages, but your team or a partner still installs and tests them on infrastructure you operate. For GLPI, the stack is PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, and the install docs cover only MySQL and MariaDB. Confirm which PHP, database and web server versions your offline mirror must hold, and who approves each update before it enters the network.

Customer control of data and backups

Sovereignty requires that you can say where ticket, asset and CMDB data sits and how it is backed up. The GLPI update procedure calls for backing up the database, the files and the config directory, including glpi.key and glpicrypt.key. Losing those keys can make encrypted data unreadable, so they belong in the backup scope and in your key custody records. Ask your auditor which backup location, retention period and restore test they expect, and document who holds each copy.

Verified software integrity at the boundary

Every package, plugin and container image carried across an isolated boundary is a supply chain event. NERC CIP-013-2 asks utilities to address verification of software integrity and authenticity for vendor software and patches in their procurement processes. The same discipline applies to GLPI releases, plugins and the iTop extensions from the iTop Hub. Confirm with your compliance team which hashes or signatures you will verify, who signs off on each transfer, and how plugin updates are recorded.

Remote access control for vendors

If the service desk sits in or near an OT environment, remote access to it is a regulated path. NERC CIP-005-7 requires Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System with encryption and multi-factor authentication, and to detect and disable active vendor sessions. Whether those rules reach a service desk depends on how it connects to BES Cyber Systems, so confirm the scope with your regulator. Treat vendor access to Private Stack support and to any self-hosted vendor help as the same question.

Authentication and admin step-up

Sovereign deployments usually need their own identity source. GLPI tries authentication against its internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, in that order. The GLPI 12.0.0 release adds step-up authentication for certain administrative actions and a view of active sessions that admins can revoke. Confirm that your directory, MFA design and admin approval flow work without a cloud identity provider, and test them offline before go-live.

Who operates what under ServiceNow Private Stack

Under ServiceNow Private Stack, ServiceNow supplies the application software, upgrade packages, deployment guidance and support, while the customer or a partner owns and operates the load balancer, application server and database tiers in the customer's own data center. That split is the core of the model. Your team keeps the infrastructure that the platform runs on, so patching, capacity, backups, failover and database administration sit with you, even though the application code and upgrade content come from ServiceNow. Before comparing this with self-hosting GLPI or iTop, map each tier to a named owner in your organization or in a partner's contract, and note which of those owners already staff the skills, such as database administration and load balancer configuration, that the platform will need.

Starting a Private Stack deployment goes through your ServiceNow account team. According to the ServiceNow Private Stack launch post, customers should expect to buy a workshop covering architecture planning, hardware sizing, database selection and operational readiness. Ask the account team for the workshop scope in writing: which deliverables it produces, who from ServiceNow attends, what the customer must prepare beforehand, and whether the output is a sized architecture you can take to your data center team. Ask for the cost of the workshop in the same written quote, and confirm whether hardware, database licenses and any partner operations work are priced separately from the platform subscription.

Treat the workshop output as the baseline for the rest of this comparison. Hardware sizing and database selection decide your recurring infrastructure cost and your upgrade window, so compare them line by line with the self-hosted GLPI or iTop estimate your own team or implementation partner prepares. Ask ServiceNow to confirm, in writing, which upgrade tasks it performs, which tasks your operations team must perform, and how much notice you get before a package requires downtime. If your network is air-gapped, confirm how upgrade packages reach the isolated boundary and who verifies their integrity before they are installed.

How Private Stack and self-hosted GLPI or iTop differ by environment

With no internet path, every package, container image, vulnerability feed and update has to cross the boundary by hand. Under Private Stack, the customer or a partner runs the load balancer, application server and database tiers, while ServiceNow supplies the application software, upgrade packages and deployment guidance. Under self-hosted GLPI or iTop, the customer also assembles the full dependency chain, from PHP and the database to the web server and the GraphViz package that iTop needs.

Operations ownership: Private Stack leaves the infrastructure tiers with the customer or partner, while GLPI or iTop leaves the application tier with the customer too, so the operating team carries the full stack.
Upgrade mechanics: Private Stack upgrades arrive as ServiceNow packages. GLPI requires a backup of the database, files and the config directory including glpi.key and glpicrypt.key, replacement of application files, then 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.
iTop install requirements: iTop 3.3.x requires PHP 8.2 to 8.4, MySQL 5.7 or later or MariaDB 10.6 to 11.8, and GraphViz, all of which must be staged offline.
Support sources: Private Stack support comes from ServiceNow. GLPI support comes from Teclib' through GLPI Network, and iTop support comes from Combodo, both of which should be confirmed for offline delivery terms.
Offline staging: Confirm with the vendor how upgrade packages, GLPI releases and iTop releases are delivered across the boundary and how integrity is verified.

Before committing, confirm which upgrade artifacts can be delivered offline and who signs off on each package entering the enclave.

A sovereign data center keeps data and operations within the organization's own facilities and jurisdiction, usually with connectivity but no dependence on a vendor cloud. Private Stack places the ServiceNow platform in that data center, but the customer carries the infrastructure lifecycle. Self-hosted GLPI or iTop places a community-licensed application in the same facility, with the database and web tiers under the same administrative control.

Operations ownership: Private Stack splits the stack between ServiceNow software and customer-run tiers. GLPI and iTop keep every tier under the organization's administration, which simplifies accountability for data location.
Upgrade mechanics: For GLPI, schedule the backup, file replacement and db:update steps in a maintenance window, and plan plugin reactivation after major versions. For iTop, check the PHP and MariaDB versions against the target release before upgrading.
Sizing: Combodo suggests an all-in-one iTop server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, and separate web and database servers of up to 8 vCPU and 16 GB for larger installations.
Support sources: Private Stack support is contracted with ServiceNow, while GLPI and iTop support is optional and separately contracted from Teclib' or Combodo, or delivered by an implementation partner.
Data residency: Confirm where any hosted or support-side data flows occur, since GLPI Network and Combodo SaaS options are separate from self-hosting.

Check whether your sovereignty rules permit vendor support access to production data and what the support contract must say about it.

Which open-source ITSM options fit a Private Stack replacement

This table compares GLPI, iTop and Znuny-style ticket systems against the constraints that usually drive a move off ServiceNow Private Stack: license terms, database and PHP requirements, and who provides support. Read each row as a check to run against your own environment, since the supported versions and editions change over time. The main takeaway is that all three run on your own servers, but they differ in licensing, agent limits and the commercial support you can buy.

Requirement	GLPI	iTop	Znuny-style ticket systems
License	GPL-3.0, maintained by Teclib'	AGPL-3.0, sponsored and supported by Combodo	GPL-3.0 (Znuny continues OTRS Community Edition); confirm current license terms with the vendor
Database	MySQL 8.0 or MariaDB 10.11 or later per the current README; confirm against your version	MariaDB preferred; MySQL 5.7 or later and MariaDB 10.6 to 11.8 supported, MySQL 8 discouraged for performance	Confirm supported database engines and versions with Znuny before sizing
PHP requirement	PHP 8.3 or later per the current README; GLPI 11.0 docs list PHP 8.2 or later	PHP 8.2 to 8.4, plus GraphViz for impact diagrams	Confirm the PHP and Perl stack for your release line
Free tier limits	No agent cap in the free GPL-3.0 edition; paid GLPI Network plans are separate	Community edition free for up to 10 agents; Atelier and Forge editions are paid	Community use is governed by the license; confirm any edition limits with the vendor
Commercial support	Optional support and hosted GLPI Network offering from Teclib'	Commercial support, training and consultancy from Combodo	Confirm support options and LTS release commitments with Znuny before choosing
Air-gapped install	Full install needs no internet path once packages are staged; confirm any plugin or agent downloads	Full install needs no internet path once packages are staged; confirm extension downloads from the iTop Hub	Confirm offline package and update procedures for your release
Offline adjacent tools	GLPI Agent inventory must reach the GLPI server on your network; confirm agent update paths	Data synchronization and CSV import run on your network; confirm any external feeds	Confirm which ITSM add-on packages you need and how they are staged offline
Operations to confirm	Plugins are suspended after a new version is detected and must be reactivated after major updates	Upgrade path between 3.2.x and 3.3.x and extension compatibility	Package-based setup and process modeling choices should be reviewed with your change board

How to deploy GLPI or iTop inside an isolated network

This sequence takes GLPI or iTop from a sized and verified package set to a tested, restorable and updatable service inside a network with no internet path. Each step names who performs it and the check that confirms it is complete.

Confirm the platform and size hosts
The service owner chooses GLPI or iTop, then the infrastructure lead sizes the hosts before anything is downloaded. For iTop, Combodo's requirements page suggests an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, with separate web and database servers of up to 8 vCPU and 16 GB for larger installations. For GLPI, the README and the installation docs list different PHP and MariaDB minimums, so confirm the versions for the release you intend to run. The step is done when the host list, runtime versions and expected ticket and user volumes are written down and approved.
Stage and verify every package
The platform engineer collects the application archive, PHP, the database server, the web server and, for iTop, GraphViz on a connected staging host. Each file is checked against the hashes and signatures the vendor publishes, and the security team scans it before it crosses the boundary. This is the control that NERC CIP-013-2 describes in its supply chain requirements, which call for verifying software integrity and authenticity for vendor software and patches. The output is a transfer manifest listing each file, its hash, the scan result and the approver. Nothing enters the isolated network without a matching manifest entry.
Install the database and runtime tier
The infrastructure lead installs PHP and the required extensions, then MariaDB, from the approved transfer set. For iTop, MariaDB is the preferred database, and Combodo's requirements page discourages MySQL 8 for performance reasons. The database administrator creates a dedicated schema and an application account limited to that schema, and allows connections only from the application host. Confirm the exact PHP and MariaDB versions against the release notes of the version you chose. The step is done when the application host connects to the database with the new account and the PHP version reported by the server matches the manifest.
Set the web root and URL rewriting
The web server administrator points the document root at GLPI's public directory rather than the installation root, then enables URL rewriting so requests route through index.php. GLPI's installation docs cover Apache, Nginx, lighttpd and IIS, so use the configuration for the server you run. For iTop, follow the web root and rewriting guidance in its own installation documentation. Test that the login page loads over the internal name, and that a direct request for a file outside the public directory is refused. Keep the web server's TLS certificate issued by your internal certificate authority. The step is done when the application responds only through the public directory and the test request is refused.
Configure directory and mail authentication
The identity team and the service owner set the sign-in methods. GLPI's user documentation says it tries the internal database, then LDAP directories, then IMAP mail servers, then external methods such as REMOTE_USER, in that order. Decide whether local accounts remain for break-glass access, and restrict them to named administrators. Confirm the LDAP bind account, search base and group mapping with the directory team, and confirm the equivalent settings for iTop in its documentation. The step is done when a standard user signs in through the directory, a user who is not in the approved group is refused, and the break-glass account is documented and tested.
Deploy GLPI Agent for inventory
The endpoint team packages GLPI Agent from the approved transfer set and deploys it to Windows, macOS or Linux machines through the internal software distribution tool. The agent collects hardware and software inventory and sends it to GLPI. It is the successor to FusionInventory Agent and can also run network discovery and package deployment, so decide which of those functions your policy allows before enabling them. Configure the agent to send data only to the GLPI server inside the network. The step is done when a pilot device appears in the GLPI asset inventory with the expected hardware and software records.
Back up data, files and encryption keys
The database administrator and the service owner define one backup routine that covers the database, the application files and the configuration directory. GLPI's update guidance names two keys, glpi.key and glpicrypt.key, that must be included, because the stored data depends on them. Store copies of these keys separately from the backups, under restricted access and with a record of who holds them. For iTop, include its configuration files and database in the same routine. The step is done when a restore to an isolated test host brings back the database and files, the application starts, and an existing record can be opened with the restored keys.
Rehearse the update procedure in staging
The platform engineer runs the vendor's update procedure on a staging copy of production before the first live upgrade. For GLPI, the steps are to back up the database, files and config directory, replace the application files, and run 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 list the plugins in use and check each one for compatibility first. Record the commands, the plugin list and the rollback steps in a runbook. The step is done when the staging upgrade completes, plugins are reactivated, and the runbook has been reviewed by the service owner and the security team.

Questions buyers ask before choosing Private Stack or self-hosted GLPI

What does ServiceNow Private Stack cost to run beyond the license?

The license is only one line. ServiceNow quotes the subscription through its account team, and a Private Stack deployment also needs customer-owned hardware, a database, a load balancer tier and the staff who run them. ServiceNow's launch post says customers should expect to buy a workshop covering architecture planning, hardware sizing, database selection and operational readiness. The main cost drivers are the number of users and instances, the size of the hardware and database tier, the internal or partner staff needed to operate three tiers, and the support level. Ask ServiceNow for the workshop fee, the sizing assumptions, the support tier and the recurring subscription as separate lines in the written quote, so you can compare them with the infrastructure and people you already pay for.

How much effort does self-hosting GLPI take, and what drives it?

GLPI carries no license fee, so the effort is mostly setup, hosting and operations. The installation needs a supported PHP version, MariaDB or MySQL, and a web server whose document root points to GLPI's public directory with URL rewriting. Effort rises with the number of assets and agents, the depth of customization such as custom asset definitions, workflows and forms, the number of plugins, integration with LDAP or SSO, and how much inventory you collect through GLPI Agent. Backup, monitoring, certificate management and patching are recurring tasks. Confirm the current PHP and database requirements against the installation documentation before sizing the server, because they change between major versions.

Can an internal team run self-hosted GLPI without a partner?

Many teams can, provided they have someone comfortable with Linux, PHP, a relational database, web server configuration and backups. The harder parts are usually the ones outside the install itself: designing ITIL processes for incidents, changes and problems, modeling assets and relationships, building reports, and writing an upgrade and restore runbook that someone other than the original builder can follow. Teclib' sells GLPI Network with support tiers, and DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure under a written, fixed scope. A useful test is whether your team can restore a backup and complete a test upgrade in a non-production environment without outside help.

How do upgrades differ between Private Stack and self-hosted GLPI?

With Private Stack, ServiceNow supplies the application software and upgrade packages, while your team or partner operates the infrastructure tiers and schedules the upgrade work. With GLPI, you take the full upgrade path yourself. The GLPI update procedure requires backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, replacing the 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 plugin compatibility belongs in your test plan. Check the release notes for each version, such as the GLPI 12.0.0 release, before you schedule a change window.

How long does a migration from ServiceNow take?

The honest answer depends on data volume, the number of customizations and how much of the process has to be rebuilt. No duration is supplied for this migration, so treat any figure you hear as provisional until it is tied to a scope. The main variables are the number of incident, problem, change and configuration item records you keep, how far ServiceNow's export limits require you to extract data in batches, how many workflows, business rules, catalog items and reports must be rebuilt by hand, and how many integrations need new connectors. Attachments usually need a separate extraction path. Ask for a data inventory and a mapping workbook before agreeing a timeline.

Is Private Stack the only option for an air-gapped ServiceNow replacement?

For networks with no internet path, the realistic choices in this comparison are Private Stack, which your team or a partner operates, or a fully open-source GLPI installation. Both require you to supply software packages, container images and vulnerability data across the isolated boundary, so your process for verifying integrity and authenticity of each package matters as much as the platform. Confirm with ServiceNow whether the Private Stack deployment you are considering has the connectivity and update model your network allows. For GLPI, plan for offline package transfer, an internal mail relay for notifications, and an update path that does not depend on the public internet.

What should a written quote include from ServiceNow, Teclib' or DeployOpen?

Ask each party to state scope, deliverables, assumptions and exclusions in writing before work begins. For ServiceNow, request the subscription, the Private Stack workshop, the hardware sizing assumptions, the database and support tier, and any upgrade or deployment guidance as separate lines. For Teclib', ask which GLPI Network tier, support level and plugins are included, and whether hosting is public or private cloud. For DeployOpen, expect a fixed scope covering planning, implementation, customization, integration, hardening, backup, upgrade and documentation, with timelines agreed in writing. Compare the quotes on the same assumptions for users, assets, environments, data volume and recurring support, and ask what is one-time and what recurs each year.

Evidence auditors and regulators ask for in an isolated ITSM

Whichever platform runs inside an isolated network, the people who assess it will ask for the same kinds of records: how it is built, what was installed, how it is restored, who touched it, and how it changed. The cards below cover the evidence to plan for, whether you run ServiceNow Private Stack or a self-hosted GLPI or iTop. DeployOpen prepares this evidence, but auditors and certification bodies issue any attestation.

Architecture and data flow diagrams

Auditors start by asking where data lives and which paths cross the isolation boundary. Keep a diagram that shows the load balancer, application, database and any agent or inventory collector tiers, with the network zones each sits in. Under Private Stack, the diagram also has to show which tiers your team or a partner operates. Check that the diagram matches the running environment, not the design from the initial workshop.

Patch and package verification records

Every package carried across an isolated boundary needs a record of where it came from and how its integrity was checked. This is the evidence behind NERC CIP-013-2 supply chain procurement expectations, which address verifying software integrity and authenticity of vendor software and patches. For Private Stack, record ServiceNow upgrade packages. For GLPI or iTop, record the release tag, checksum and approval for each file moved in.

Backup and restore test records

A backup is only evidence once a restore has been performed and written down. Keep records of the database, application files and, for GLPI, the glpi.key and glpicrypt.key files, which are needed to read encrypted data after a restore. Log the date, the restore target, the person who ran it and the outcome. Ask your platform owner how often restores are tested and who signs off the result.

Access logs and remote session controls

Regulators in the energy sector expect remote access into high and medium impact systems to pass through a controlled intermediate point, with encryption, multi-factor authentication and a way to detect and end vendor sessions. Keep administrator login logs, privileged action logs and records of every remote session opened by a vendor or partner. Confirm which of these your chosen platform produces natively and which need a log collector.

Change records for upgrades

Each upgrade is a change that needs a request, an approval, a test and a rollback plan. For GLPI 11.0 and later, plugins are suspended after a new version is detected and must be reactivated after major updates, so record that step as well. Private Stack upgrades follow ServiceNow's packages and guidance. Keep the same change record format for both paths so the audit trail reads consistently.

Role assignments for each tier

Auditors ask who can change each tier and who can approve that change. Write down who operates the load balancer, the application server and the database, and who holds the administrator role in the ITSM itself. Under Private Stack, the split between ServiceNow, your team and any partner must be explicit. Review the list at least when staff change, and confirm that the same person cannot both request and approve their own privileged change.

How exit and data portability differ between Private Stack and open-source ITSM

The exit question comes down to where your ticket, asset and CMDB data sits and who controls the software that holds it. With GLPI or iTop, the records live in MySQL or MariaDB on servers you operate, so you can query the database directly, export with the platform's own tools and keep a copy of the schema without asking anyone for permission. With ServiceNow Private Stack, the application runs in your data center, but it remains ServiceNow's software under ServiceNow's terms. Before committing, ask ServiceNow in writing what export formats are available for your instance, whether direct database or schema access is permitted for your team and partners, and what the license permits you to do with the application after termination. The answers determine how much of your data you can extract on your own schedule.

For GLPI, confirm three things with your own environment rather than assuming them. First, which export paths your version supports for each record type, including tickets, assets, contracts and the knowledge base. Second, whether your team needs read access to the database schema for bulk extraction, and who in your organization will own that access. Third, that your backup set covers the database, the files and the config directory with glpi.key and glpicrypt.key, because the encrypted fields cannot be read back without those keys. For iTop, check the CSV import and export behavior for your CI classes and confirm the data synchronization options if you plan to federate. Run a test extraction of a representative sample of each object type into a second system before the migration decision is final.

Plan the exit as a recurring discipline, not a one-time event. Under a Private Stack model, the exit runs through ServiceNow's export tooling and any attachments may need separate extraction, so schedule test exports against a non-production copy and measure how long they take. Under an open-source model, a scheduled database dump plus file and key backups gives you a standing copy that does not depend on a vendor. Ask any implementation partner to document the export runbook, the schema version it applies to and how it is tested after each upgrade. Your exit cost is then mostly staff time and storage, which you control, rather than a negotiated term you must renegotiate at the point of leaving.

How DeployOpen deploys GLPI or iTop under an air-gap or sovereignty constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For ITSM, that means GLPI or iTop deployed, integrated and handed over in your environment, under a written scope agreed before work starts.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Scope records which ITSM processes move, such as incident, change, problem and asset management
Scope states the network boundary, the approved offline media path and who holds the database and config keys
Ongoing support, upgrades and continuous testing are available as retainers after handover

How we build

Installation covers the web server document root, PHP and database versions checked against the vendor requirements
Container images, packages and plugins are staged and verified before they cross the isolated boundary
Authentication is wired to your directory, such as LDAP, and tested before users are onboarded
Asset inventory and CMDB feeds are configured and checked against a sample of your real estate

How we hand over

Documentation covers installation, configuration, backup, restore and the offline update procedure
Runbooks describe how to verify each package and update before it is imported into the network
Backups of the database, application files and the config directory are tested by restoring them
Compliance evidence is prepared for your assessors, who decide conformance, as DeployOpen does not issue attestations

How we support

Support after handover is available as a retainer, scoped in writing like the original engagement
Upgrade work follows the vendor's update procedure, including reactivating plugins after a new version
Security testing of the ITSM application and its integrations can be scheduled as part of ongoing support
Ask for the support scope, response expectations and what is excluded before you sign