Remote Repository Management - Administrator Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Cortex XSOAR
Creation date
Last date published
Administrator Guide

Overview of how remote repositories work and how to configure a remote repository in Cortex XSOAR.

You can develop and manage content in Cortex XSOAR either manually within the production tenant, or between development and production tenants using a remote repository.

Manual Content Management

Cortex XSOAR is a self-contained system. The Cortex XSOAR tenant serves as the content repository, content is developed using an IDE and stored locally.


If you only use a standalone tenant (with no development tenant), you can develop and manage content manually. You can save content versions and manage revisions locally for scripts, playbooks, integrations, etc. using the Save Version button. For all other content types, changes are automatically saved locally. You can also manage content by importing/exporting it in Cortex XSOAR.

Content Management Using a Remote Repository

In Cortex XSOAR you can use a content management system with a remote repository to develop and test content. You can choose which type of remote repository you want to use, either the Cortex XSOAR built-in remote repository (default), or a private content repository.

The development tenant pushes content to a remote repository and the production tenant or additional development tenants pull content from the remote repository.

If after setting up the remote repository feature you later decide to revert a tenant to standalone, go to Settings & InfoSettingsAdvancedContent Repository and toggle the Content repository slider to off. If you disable the remote repository feature, content on the tenant is not deleted. If you enable the remote repository feature again and the remote repository contains content, you need to choose which content to keep, either the content on the tenant or the content on the remote repository. We recommend backing up any content that you want to keep before enabling again.

The Development Tenant

The development tenant provides a safe environment to develop and test the functionality of custom content before using it in a production environment.


Development tenants are not intended for performance checks.

After you develop your content, if you want it to be available as part of a content update for the production tenant or additional development tenants, you must push content from the development tenant.

The Production Tenant

The production tenant is the operational environment for investigating real data. It pulls content as updates that you can install after the development tenant pushes it to the remote repository.

Push and Pull Content between Tenants

In a cluster of tenants that includes one production tenant and one or more development tenants, only one development tenant pushes. The production tenant and any other development tenants pull from the one development tenant that is configured to push content. For example, you can have an additional development tenant for testing that pulls content from the development tenant configured to create and edit content.

All system content, content updates, and custom (user-defined) content is managed (downloaded, installed, edited, created, and updated) only in the development tenant that pushes content. For example, system content updates from Marketplace are only delivered to the development tenant that is configured to push. You cannot create or edit content in a production tenant or additional development tenant, they are configured only to pull content (except for dashboards and lists).

When pushing content from the development tenant, the content is synchronized and manually pulled into the production or other development tenant(s) as content updates.

You can decide which updates you want to push from the development tenant to pull tenants via the remote repository.

The following types of content can be synchronized between development and production tenants:

  • Scripts

  • Playbooks

  • Integrations

  • Classifiers

  • Mappers

  • Content packs

    When pushing a content pack to the production tenant, we recommend pushing all of the content for the content pack to work properly.

  • Incident fields

  • Indicator fields

  • Evidence fields

  • Incident layouts

  • Incident types

  • Pre-processing rules

    If you re-order your pre-processing rules you must push all of the pre-processing changes to the production tenant.

  • Indicator types

  • Reports

  • Dashboards

  • Widgets