ServiceNow® Private Stack: what it is, and what it takes to run

What Private Stack is

In 2026 ServiceNow® gave its customer- and partner-operated deployment model a name. Private Stack is what used to be called self-hosted, or on-premise.

The mechanics are unchanged. You receive the same application software that runs in ServiceNow's commercial cloud, and you deploy it inside your own infrastructure. You own and operate the hardware, the database, the load balancers, the network and the operating system. ServiceNow provides the application software, deployment guidance, reference architectures, upgrade packages and support.

What changed is status. Private Stack now sits inside a named Sovereign Cloud Platform Portfolio alongside ServiceNow's other deployment options. ServiceNow states it serves more than 500 customers across 28 countries, concentrated in defense, government, banking, telecom and technology.

For a decade, choosing self-hosted meant choosing something the vendor quietly discouraged. That is no longer the case.

Who actually needs it

Private Stack exists for organisations that cannot put the platform in a public cloud. In practice that means one of four constraints:

• Sovereignty. Data must remain within a specific jurisdiction, under a specific legal regime, beyond the reach of foreign authorities. For European organisations this usually means the US CLOUD Act, and it is not solved by choosing an EU region from a US-owned provider.
• Classification. Defense and intelligence contexts where the data cannot traverse infrastructure the organisation does not control.
• Connectivity. Air-gapped environments, industrial networks, isolated facilities.
• Regulation. DORA, NIS2 and sector-specific rules that impose concentration-risk, auditability or exit-plan requirements which are easier to satisfy with an owned deployment.

If none of these apply to you, cloud is almost certainly the right answer, and we will say so.

Architecture

A Private Stack deployment mirrors the architecture ServiceNow runs in its own cloud: a load balancer tier, an application server tier and a database tier. The difference is that you own and operate every layer.

ServiceNow publishes reference architectures for disaster recovery and backup, and expects customers to purchase a workshop covering architecture planning, hardware sizing, database selection, supporting component deployment and operational readiness.

Most organisations default to virtualisation — VMware, Kubernetes, Docker — as the automatic infrastructure choice, without weighing what Private Stack actually requires from the layer underneath it, or what happens when something goes wrong down there.

Take the usual case: ServiceNow® deployed on VMware, default setup, clustering and cluster load balancing enabled. That is a sound choice for most workloads, and virtualisation gives you exactly what you want from it — you do not need to know, and normally should not care, which server room, which data centre, which rack, or which firewall your VM happens to sit behind. You care about availability, and the platform delivers it. That abstraction exists for good reason.

ServiceNow is the exception to that rule. You need to know where the parts are actually running, how many routers and firewalls sit between the load balancer and the application servers, how far the application node is from the database engine, what storage capacity is available, and the overall length and type of cable between components — not out of curiosity, but because all of it measurably affects performance.

Cluster load balancing was never built with ServiceNow's requirements in mind. When it is active, your VMs migrate between racks, server rooms, and sometimes entire data centres, sharing the same cluster infrastructure with other tenants' workloads over network paths that are not fixed and not easy to measure. There is no stable distance between components to point to, because there isn't one.

The result is a specific and dangerous failure mode: a silent fail. Nobody touched any configuration. Nobody has a record of a change. The migration happened automatically, exactly as designed — and instance performance flaps up and down from one day to the next with no obvious cause, because the cause sits in a layer the virtualisation platform deliberately hid from you, and that ServiceNow needs you to see.

Reference and sample topology diagrams — load balancers, application nodes, replicated database, MID servers — available on request.

What you do not get

ServiceNow publishes a feature availability matrix at general availability of every family release. As of the Australia release, the notable unavailable items are:

• Instance Clone — a manual method exists
• Instance Data Replication (IDR)
• Cloud Encryption / ServiceNow Vault
• AI Gateway
• Dynamic Translation
• Workflow Data Fabric connectors — Zero Copy and External Content Connectors
• Impact — Instance Observer
• ServiceNow IDE and Developer Sandboxes
• Third-party Virtual Agent integrations — Teams, Slack and similar

Automated upgrades are available, but only for internet-connected deployments. Air-gapped environments upgrade by other means.

Available capabilities include Now Assist, AI Agents and Knowledge Graph from Zurich onward, AI Search and Predictive Intelligence, RPA, Process Mining and Automation Center, Security Incident Response and Threat Intelligence, Field Encryption and the Key Management Framework, Health Log Analytics from Yokohama onward, and Store app downloads.

Each of these capabilities depends on ServiceNow's own development and release cycle, and on which family release you are running — that part is outside anyone's control, ours included. What can be addressed is the gap between what cloud customers get through the support portal — clone, upgrade and backup management for their instance — and what a Private Stack deployment ships with on its own. Closing exactly that gap, for Instance Clone and for upgrades on disconnected deployments, is what SH-SIM was built for: repeatable instance cloning without ServiceNow's cloud tooling, and planning, rehearsal and execution automation for family releases and patches, including in air-gapped environments. It will not help with AI Gateway, Zero Copy connectors or the other vendor-side items on the list above — no tooling works around those — but for the two gaps that cost the most operational time, it does.

GenAI on Private Stack

The strongest argument against self-hosting used to be that you would never get the AI features. That argument no longer holds.

Generative AI is available on Private Stack across ITSM, CSM, ITOM, HRSD, SecOps, FSM and SPM, running in one of three ways:

1. ServiceNow's production models on your own GPU infrastructure
2. Bring-your-own-key, using Azure OpenAI, AWS Anthropic or Google Gemini
3. Your own LLM, with a more limited experience

Practical constraints worth knowing before you plan: GenAI images are refreshed twice a year rather than continuously, data sharing is off by default, AI Agents require Zurich or later, Now Assist credits are consumed under the same pricing model as commercial SaaS, and not every feature reaches parity with the cloud release.

What it costs to run

We are not going to pretend this fits in a spreadsheet. No cost model, however detailed, gives you a reliable five-year number here — not an Excel sheet, not a sizing tool, not anything resembling a crystal ball. Anyone who hands you a confident total at this stage is guessing, however well-dressed the guess.

In short: running Private Stack costs at least as much as running the equivalent instance in ServiceNow's own cloud, plus everything below. The reasons it resists estimation are specific, not vague:

• ServiceNow licence cost itself cannot be estimated in advance. It depends heavily on negotiation on both sides, can swing by tens of percent year to year and release to release, and depends on contract length and any upfront payment — and licensing is usually the largest single line item in the total.
• Underlying and shared infrastructure — power, connectivity, data-centre or co-location fees — known only inside your own organisation.
• Virtual machine costs, sized to whatever target architecture you land on.
• Hardware costs — procurement, implementation fees and renewal cycles, again tied to the architecture decision.
• General hardware, software and OS operations and maintenance.
• Storage, sized to allocated capacity on whatever array, NAS or SAN you run.
• Backup management, as its own line item, not an afterthought.
• A dedicated operations team. Private Stack specifically needs administrators who understand the platform in depth, not generic infrastructure staff. Depending on deployment size, that is typically 3 to 10 people, with at least two genuine platform experts among them.
• GPU capacity, if Now Assist or AI Agents are in scope.
• The ServiceNow architecture and sizing workshop ServiceNow itself expects you to purchase before you start.
• Upgrade-cycle effort — not routine patching, but re-validating customisations and integrations against every new family release.
• Monitoring and observability tooling, built for a platform ServiceNow does not instrument for you the way it does in its own cloud.
• Keeping that operations team's knowledge current release after release — training is not a one-time cost.

None of this can be estimated without your specific architecture decisions and the outcome of your own licence negotiation with ServiceNow — so we are not going to produce a number that pretends otherwise. What we can do is help you build the real model once those two things are known.

Deciding

There is a third option many organisations overlook: a Sovereign Partner Cloud provider hosts and operates ServiceNow for you inside your jurisdiction. You get sovereignty without owning the operational burden. For many European organisations this is the better answer, and we will tell you when we think it is.

Related reading

• Private Stack Implementation Study — what a self-hosted rollout actually involves, phase by phase, and where implementations typically fail. Available on request.
• SH-SIM in action — short use-case recordings of cloning, installation, inventory configuration, scheduling and data transfer. See it in action.

Working through this decision?

Our Private Stack Readiness Assessment produces the target architecture, sizing, cost model and migration roadmap in two to three weeks, at a fixed price. You keep the deliverable regardless of what you decide next.