> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.15/onboard-cortex-xsoar/high-availability/sizing-requirements-for-high-availability-deployments.md). # Sizing Requirements for High Availability Deployments Review sizing requirements for a Cortex XSOAR 6.15 high availability deployment. ### Cortex XSOAR high availability app server requirements Cortex XSOAR recommends you have at least 2 application servers meeting the requirements listed below, as well as a load balancer and shared file system. | Component | Dev Environment Minimum | Production Minimum | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CPU | 8 CPU cores | 16 CPU cores | | Memory | 16 GB RAM | 32 GB RAM | |

Storage

Note

The storage requirement is irrespective of the file share.

| 100 GB SSD |

250 GB SSD with minimum 1k dedicated IOPS

Note

Depending on the size of your log files, consider increasing this to 500 GB.

| ### Cortex XSOAR high availability file share server requirements Cortex XSOAR recommends your file sharing server meet the following minimum requirements. {% hint style="info" %} ### Note * If you are using Amazon EFS, GCP File Store, or Azure Files, verify that you are only using these systems for your file sharing and not as the database or application servers. * The file sharing server must be in the same virtual private cloud as the application servers. {% endhint %} | Component | Dev Environment Minimum | Production Minimum | | --------- | ----------------------- | ----------------------------------------- | | Storage | 100 GB SSD | 250 GB SSD with minimum 1k dedicated IOPS | ### Elasticsearch development configuration for high availability | Environment | Number of Nodes | Elastic Node Roles | | ----------- | --------------- | ------------------------------------------------------------------- | | Minimum | 1 | Data node | | Recommended | 3 | All three must be data nodes, but can also function as other roles. | ### Elasticsearch production configuration for high availability | Environment | Number of Nodes | Elastic Node Roles | | ----------- | --------------- | -------------------------------------------------------------------- | | Minimum | 3 | All three must be data nodes, but can also function as other roles. | | Recommended | 6 | | ### Elasticsearch high availability hardware requirements | Component | Dev Node Minimum | Production Node Minimum | | --------- | ---------------- | ----------------------------------------- | | CPU | 8 CPU cores | 16 CPU cores | | Memory | 16 GB RAM | 32 GB RAM | | Storage | 250 GB | 500 GB SSD with minimum 3k dedicated IOPS | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.15/onboard-cortex-xsoar/high-availability/sizing-requirements-for-high-availability-deployments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.