This decision guide provides an architecture decision framework for running a base ArcGIS Enterprise deployment on a single machine or across multiple machines.
An ArcGIS Enterprise base deployment on Windows and Linux consists of Portal for ArcGIS, a hosting ArcGIS Server site, ArcGIS Data Store configured as a relational store, an object store, and one or more ArcGIS Web Adaptors.
A single-machine deployment installs all of these components on one host. A multi-machine deployment distributes them across two or more hosts to give components dedicated resources, add redundancy for high availability (HA), or to meet other architectural goals related to workload separation or operations.
Single-machine and multi-machine are both supported production configurations. The single-machine model is not limited to development, test, or training use. The right choice depends on availability requirements, workload, expected growth, and the operational model the organization can sustain. Moving from single-machine to multi-machine later is a re-architecture effort that may introduce disruption and includes additional effort, so make this decision deliberately with future goals for the environment in mind.
This guide covers only the decision of how many machines to dedicate to the ArcGIS Enterprise base deployment. Capacity modeling, workload testing, and the requirements of additional individual server sites are out of scope for this guide.
The decision is typically owned by the solution or platform architect, working with the ArcGIS Enterprise administrator and the infrastructure team. Application owners, security, and operations should participate when the workload carries an availability service level agreement (SLA) or significant capacity demands. Review licensing with whoever manages ArcGIS Server core entitlements.
Confirm the ArcGIS Enterprise version and the system requirements for each base component.
Establish the workload profile: expected users, concurrency, service catalog, analysis intensity, and growth. Use existing monitoring data where available; estimate from comparable systems for a new deployment.
Identify availability requirements: uptime SLA, recovery time objective (RTO) and recovery point objective (RPO), and acceptable maintenance windows.
Identify which additional servers may be needed now or later, such as ArcGIS Image Server or ArcGIS Notebook Server. These roles are beyond the base deployment and should be planned separately.
Confirm available ArcGIS Server licensing and how vertical scaling would affect it.
Establish infrastructure capabilities: virtualization platform, snapshot and backup tooling, load balancing, shared storage, and the network between tiers.
Compute and storage sizing. Component footprints are combined on one host or separated across hosts, which changes how CPU, memory, and disk are sized.
Licensing. ArcGIS Server is licensed by CPU core, so the core count across the deployment can drive license requirements and cost.
Backup and disaster recovery (DR). Both single-machine and multi-machine deployments require a supported, coordinated backup and recovery approach. ArcGIS Enterprise backup and restore with the webgisdr utility supports the ArcGIS Enterprise deployment; infrastructure snapshots may be an additional option where appropriate.
Upgrade strategy. Single-machine deployments have fewer hosts and components to coordinate during an upgrade; multi-machine upgrades require sequencing across the participating components.
High availability. Component-level redundancy is only available in a multi-machine deployment, so any HA requirement forces that topology. This redundancy also increases the number of components and dependencies that must be operated and maintained.
Future scaling requirements. If service usage grows over time or one component experiences significant load, scaling horizontally to add additional hardware may require re-architecting, and scaling vertically in place scales all components, which may not be desirable.
ArcGIS Server site placement. Resource-intensive ArcGIS Server sites are added as separate federated machines, a choice influenced by but independent of the base topology.
Before making a decision, consider the context for each option.
A single-machine ArcGIS Enterprise base deployment on Windows and Linux installs Portal for ArcGIS, the hosting ArcGIS Server site, ArcGIS Data Store (configured for relational and object), and ArcGIS Web Adaptor on one host. It is a supported production topology when the combined workload can be served by one host, does not require component-level high availability, and is expected to remain reasonably stable in users, workflows, and capabilities. This configuration can be deployed manually, through cloud-native automation, or through tools like ArcGIS Enterprise Builder.
Single-machine base deployments offer:
Operational simplicity. One host to install, patch, monitor, secure, and back up.
Simpler backup coordination. With all base components on one host, there are fewer infrastructure elements to coordinate. Use the supported ArcGIS Enterprise backup and restore workflow for application-consistent protection; infrastructure-level snapshots can be an additional option for virtualized deployments where appropriate. See Backups and disaster recovery.
Simpler upgrade and rollback coordination. A single host can reduce the number of infrastructure elements that must be sequenced, validated, and returned to service during an upgrade or rollback. See Blue-green deployments.
Lower footprint and cost. One appropriately sized host can serve workloads that fit within the combined capacity of that host, with no inter-component network dependency. In many deployments, resource usage is low during operational hours, and a single host may provide the most cost-effective infrastructure for the level of user traffic.
Limitations:
Resource contention. In this configuration, all components share the host’s CPU, memory, and disk I/O, and under sustained load one can starve another. Size for the combined footprint and leave headroom. Where workloads differ enough to interfere, workload separation is an appropriate design response.
Vertical scaling has a licensing consequence. Because ArcGIS Server licensing is based on CPU core entitlements, increasing cores on a deployment machine can change licensing requirements. Treat this as a decision constraint when comparing vertical growth with a multi-machine design, and validate the applicable entitlement and virtualization guidance before resizing. See Virtualization and ArcGIS Enterprise.
No application-level high availability. The host is one failure domain. Host restart and infrastructure-level replication can provide resilience, but they do not provide component failover, so a strict uptime SLA is not a fit. See High availability.
Additional server sites are outside the base deployment. When additional ArcGIS Server sites are required, evaluate placing them on separate federated machines sized for their workload rather than assuming they belong on the base host.
A multi-machine ArcGIS Enterprise base deployment on Windows and Linux distributes the base components across two or more hosts, separating components onto dedicated machines, adding redundancy per component, or both. It suits larger workloads, deployments with an availability SLA, systems expected to scale horizontally, and systems that are expected to evolve over time to host additional service types or ArcGIS Server sites.
Multi-machine base deployments offer:
Workload separation. Each component can run on a host sized for its own demand, reducing contention. See Workload separation.
Horizontal scale-out. Add ArcGIS Server machines to the hosting site behind a load balancer and scale components independently. See Load balancing and reverse proxies. Additional ArcGIS Server sites can also be created and federated for specific purposes such as referenced service hosting, mobile editing or geoprocessing services.
High availability. Component-level redundancy is only available in this topology. High availability covers what each ArcGIS Enterprise component requires — including the load balancer, shared storage, and configuration store that an HA design depends on.
Limitations:
Operational complexity. A multi-machine deployment means more hosts to patch, secure, monitor, and keep version-aligned. See Upgrades and patching.
Coordinated backup and upgrade. Multi-machine deployments require a coordinated ArcGIS Enterprise backup approach and sequenced upgrades across components. Infrastructure snapshots taken independently should not be treated as a coordinated application restore point. See Backups and disaster recovery.
Network dependency. Components need a reliable, low-latency network, which becomes part of the system dependencies.
Higher cost. More machines, cores, and ArcGIS Server sites increase infrastructure and licensing costs and create fixed, ongoing costs.
A common growth pattern keeps the base deployment on one machine while placing additional or resource-intensive ArcGIS Server sites on separate federated machines sized for their workload. This extends the overall system beyond the base deployment without changing the base topology itself.
The overall system is multi-machine, but the base stays a single, easily managed unit. This is often the right way to grow a single-machine deployment without giving up its benefits.
Use the comparison matrix to compare the two architecture types at a high level, then apply the scenarios and recommendations to determine a recommended topology.
| Decision factor | Single-machine | Multi-machine |
|---|---|---|
| Availability | Infrastructure resilience only; no failover | Component-level high availability |
| Scaling model | Vertical (scale up the host) | Horizontal (add machines) and vertical (scale up existing machines) |
| Workload isolation | Shared host; components contend | Components on dedicated hosts |
| Backup and restore | Supported ArcGIS Enterprise backup/restore; fewer hosts to coordinate | Supported ArcGIS Enterprise backup/restore; coordinated multi-component recovery |
| Upgrade and rollback | Fewer components to coordinate | Sequenced across components |
| Operational complexity | Lower; one host | Higher; multiple hosts to align |
| Licensing impact | Vertical scaling raises licensed cores | ArcGIS Server core entitlements apply across the licensed ArcGIS Server machines; verify total licensed cores for the selected topology |
| Best fit | Workload fits one host, no strict HA requirement, and demand is expected to remain stable | HA, workload separation, expected growth, new capabilities, or scale-out requirements |
Match system topology to organizational requirements for availability, workload, expected growth, licensing, and operational support. A single-machine base deployment is a supported production configuration when those requirements can be met on one host; choose multi-machine where high availability, workload separation, scale-out, or foreseeable changes in workload or capabilities justify it.
| Scenario | Recommended topology | Rationale |
|---|---|---|
| Production workload that fits one host, has no strict HA requirement, and is expected to remain stable | Single-machine | Meets current and foreseeable demand with lower operational overhead. |
| Development, test, or training | Single-machine | A single machine can be appropriate for isolated non-production use; environments intended to validate production architecture should mirror the relevant production topology. |
| Strict uptime SLA | Multi-machine (HA) | Only multi-machine provides component failover and removes single points of failure. |
| High concurrency or heavy analysis | Multi-machine (scale-out) | Add machines to serve demand beyond a single host. |
| Base plus a resource-intensive role | Single-machine base deployment plus a separate ArcGIS Server site machine | Keep the base simple; give the heavy role dedicated capacity. |
| Foreseeable growth in users, workflows, or ArcGIS Server capabilities | Multi-machine, or plan the transition before the single-machine deployment reaches its practical ceiling | Avoids delaying a known re-architecture until after the workload has outgrown the initial topology. |
These are the practices specific to the topology choice. For the backup, upgrade, high-availability, and monitoring practices that apply to any ArcGIS Enterprise deployment, follow the reliability pillar pages linked above.
Do not select topology by convention alone. Match the base deployment to availability, workload, growth, licensing, and operational requirements, and consider the cost and disruption of later re-architecture when future growth is likely.
Size a single-machine host for the combined component load, and leave headroom for contention and growth.
Account for the licensing consequence of vertical scaling before committing to a single-machine deployment that is expected to grow. For virtualized or cloud deployments, validate the applicable core-allocation and entitlement guidance, then compare the licensing impact of scaling up with scaling out.
Deploy resource-intensive ArcGIS Server sites on their own federated machines, regardless of the base topology.
Add high availability only when an SLA requires it. HA multiplies the operational surface and should answer a stated requirement rather than a general preference.
Design single-machine deployments so migration to multi-machine stays feasible. Keep DNS names, certificates, and data store locations independent of the host wherever the platform allows. Consider using cloud-native storage for the configuration store and directories of ArcGIS Server, and for the Portal for ArcGIS content directory, to allow a move to high availability or separate machines later in the evolution of the system. This practice keeps the decision flexible in the future.
Treat the initial topology as a decision to be revisited, not a permanent one. On a single-machine host, the specific signal to watch for is contention — one component degrading another — since that is the failure mode the topology introduces and the trigger for separating components. Reassess your decisions as load grows, ArcGIS Server sites are added, or an availability requirement emerges, and plan the single-to-multi-machine transition before the deployment reaches its ceiling rather than after. For what to measure and how, see ArcGIS and IT infrastructure monitoring.
This guide assumes a base ArcGIS Enterprise deployment on Windows and Linux of Portal for ArcGIS, a hosting ArcGIS Server site, ArcGIS Data Store, and one or more Web Adaptors. It does not replace capacity modeling, workload testing, or review of specific ArcGIS Server sites requirements. Confirm licensing against current entitlements, and validate high-availability and disaster-recovery requirements against organizational standards. Deployments with specialized ArcGIS Server sites or strict regulatory constraints should be evaluated individually.
High availability — ArcGIS Architecture Center
Backups and disaster recovery — ArcGIS Architecture Center
Load balancing and reverse proxies — ArcGIS Architecture Center
ArcGIS and IT infrastructure monitoring — ArcGIS Architecture Center
Workload separation — ArcGIS Architecture Center
Virtualization and ArcGIS Enterprise — ArcGIS Architecture Center
Environment isolation — ArcGIS Architecture Center
Upgrades and patching — ArcGIS Architecture Center
ArcGIS Web Adaptor and alternatives — ArcGIS Architecture Center
Base ArcGIS Enterprise deployment — ArcGIS Enterprise
Configure a highly available ArcGIS Enterprise — ArcGIS Enterprise
Overview of ArcGIS Enterprise backup and restore (webgisdr) — ArcGIS Enterprise
Best practices for system architecture — ArcGIS Server
Licensing ArcGIS Enterprise deployments in virtualized and cloud environments — Esri technical paper