Remote Repositories Overview
Overview of how remote repositories work and how to configure
a remote repository in Cortex XSOAR. content repository dev-prod
dev prod repo
In Cortex XSOAR, you can develop and test your content
on other machines, before using it in a production environment.
You can do this by using one of the following options:
- The remote repository feature in the UI.
- Use the CI/CD Process
The Remote repository feature in the UI
Cortex XSOAR supports the ability to work with
separate repositories for development and production environments.
This enables you to develop and test all of your content in one
location, and when it is ready, you push the content to the remote
repository. On your production environment, you pull the content
as you would all other content updates. This feature does not need
the resources for CI/CD process and is designed for less complicated
content, usually one or two developers working on a local machine.
Working with the Remote repository feature in the UI
In the production environment, the content appears as a content
update, just like any other, and you pull the content from the remote
repository into your working branch.
The development and production environments must be running on
the same version of Cortex XSOAR.
In addition, Cortex XSOAR content updates are only delivered
to the development environment. This enables you to determine which
updates you want to push to production.
- Working with remote repositories is Git-based. Any service that supports this protocol can be used, for example, GitHub, GitLab, Bitbucket, etc. In addition, on-premise repositories are also supported.
- Verify that your Cortex XSOAR has access to the remote repository as this feature can not be configured to work with Engines.
To work with remote repositories, you must have two separate
Cortex XSOAR environments on two separate machines. The development
environment is used to write the following content:
- Automations
- Playbooks
- Integrations
- Classifiers
- Mappers
- Content packsWhen pushing a content pack to the remote repository, you should push all of its content, listed in the Local Changes window, for the content pack to work properly.
- Agent tools
- Incident fields
- Indicator fields
- Evidence fields
- Incident layouts
- Incident types
- Pre-processing rulesIf you have more than two pre-processing rules in your Local Changes queue, you must push all of those changes to the remote repository.
- Indicator types
- Reports
- Dashboards
- Widgets
On the production environment, it is not possible to edit these
elements.
You need to configure a remote repository both on a development environment and
a production environment.
After you develop your content, if you want it to be available as
part of a content update for the production environment, you must push the changes
to the remote repository. If you experience issues, learn how to troubleshoot remote
repositories.
If after setting up development and production machines,
you later decide to revert to a standalone environment, without
a remote repository, disable the option for .
Private content
repository
under Settings
Advanced
Content Repository
The Remote Repository UI feature and High Availability
The remote repository feature in the UI is not supported on development
environments that run as High Availability (multi-app servers).
You can still use a development > staging > production set up, where
development is a single server (not High availability), but production
can be High Availability. In this setup, both staging and production
pull from the same git repository. If your development environment runs
as High Availability, use the CI/CD Solution.
Recommended For You
Recommended Videos
Recommended videos not found.
