> 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/cortex-xsiam/configure-cortex-xsiam/remote-repository-management/push-and-pull-content.md).
# Push and pull content
The remote repository allows you to synchronize content, such as playbooks and scripts, across different environments. This ensures that automation logic and integrations developed and tested in a development tenant can be deployed consistently to a production tenant.
Push content from the development tenant
When content you develop is ready for production, you push the content update from the development tenant to the remote repository.
### Push content considerations
* **Push**
* **Role-level requirements**: The ability to push playbooks and scripts to a remote repository is governed by a specific set of RBAC permissions. Your role must have **Scripts** and **Playbooks** enabled (under **Investigation & Response** → **Automations** with **Edit Public** selected for both) and **Cases and Issues** (under **Cases & Issues**) set to **View/Edit**.
* **Push scope**: When a push is initiated, the system synchronizes all custom content, such as all playbooks and scripts, within the tenant to the remote repository.
{% hint style="info" %}
For more information, see [Manage access to playbooks and scripts](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-playbooks-and-scripts.md), including the Remote Repositories (Push/Pull) section.
{% endhint %}
* **Manual export**: Do not manually export content from the development tenant to import to the production tenant. Use only the procedures outlined in the documentation to ensure that your content is properly updated in the production tenant.
* **Version compatibility**: We do not recommend pushing content from a development tenant to a production tenant if they have different versions. This helps avoid compatibility conflicts, versioning errors, and unintended behavior in the production environment.
### Development and production environments in different deployment phases
Separating your development and production environments into different deployment phases enables testing an upgrade version in the development environment before upgrading the production environment. Since new features available in the upgrade version may not function in the pre-upgrade environment, Cortex XSIAM provides warning messages and visual indicators to alert users about incompatible items between development and production environments, and collapsible release notes in the list of changes.
### How to push content from the development tenant
On each page you can decide whether to include or exclude items, which prevents them from being pushed to production, on a temporary or permanent basis. You can only exclude individual content items, not content packs.
1. In the development tenant, select **Settings** → **Configurations** → **Remote Repository Content** → **User-Defined Content**.
2. Under the Included for **Prod** tab, search for the items you want to push. The results are displayed in a table according to:
* **NAME**: The name of the content item.
* **TYPE**: The content type, for example playbook, script, issue layout, and issue field.
* **STATUS**: The date the content item was created.
* **MESSAGE**: Additional details about the content item that were added by the content owner.
* **BY**: The content item of the person who performed the commit for the change or creation of the content.
3. Select the items you want to push to production, and click **Push to Prod**.
4. If the items have dependencies, review the contents and click **Push**.\
Sometimes you may not want to push all content, content pack dependencies, etc. For example, when a user makes a change in a playbook that includes a script dependency to which another user is adding a feature, and the change does not require the new feature (version) of the script, you can push the playbook without the new script.
5. In the dialog box, add an optional message and click **Push**. You can now pull the content into the production tenant as explained below.
Pull content into the production tenant
After you push content from the development tenant, the navigation bar in the production tenant will notify **Remote Repository Content Available**. In case of conflicts, you have the choice whether to keep local content or delete and replace.
### Pull content considerations
When pulling content from a remote repository, Cortex XSIAM handles ownership differently depending on whether the content is new or already exists in the environment:
* **Existing playbooks and scripts**: If the playbook or script already exists in the target environment, the content is updated while the current ownership and access configurations remain unchanged.
* **New playbooks and scripts (access and ownership)**: New playbooks and scripts always arrive in a **Restricted** state, regardless of the access or sharing permissions they had in the development tenant. Ownership assignment depends on your Remote Repository Settings for access to new content as explained in the task below.
{% hint style="info" %}
In a production (pull) tenant, manual editing of synchronized content is blocked:
* Users cannot be granted **Editor** permissions.
* Any existing **Editor** permissions (set before the tenant was configured for remote repository synchronization) are effectively treated as **Viewer** access. These capabilities are removed from Cortex XSIAM and blocked by the system regardless of role-level permissions.
{% endhint %}
{% hint style="warning" %}
## PREREQUISITE
When pulling playbooks or scripts from a remote repository into a production tenant, you must define how ownership and access are assigned for the incoming object's new content.
1. Select **Settings** → **Configurations** → **General** → **Remote Repository Settings**.
2. Under **Access to new content**, choose how to assign ownership for pulled content:
* **Keep the original owner**: Select this when the user managing access is the same in both tenants. This user is designated as the **Owner** in the production tenant. Recommended option when the same users exist in both the pushing tenant and the pulling one.
* **Owner is the user pulling content into the production tenant (default)**: Select this when users pulling content should also manage their access. The user who manually triggers the pull action is designated as the **Owner**.
* **Assign new content to this user**: Select this when a specific user is responsible for managing access to new content. An administrator specifies a specific user as the **Owner** of all playbooks and scripts included in the pull.
3. Set the **General access** state:
* **Restricted**: Private to the new **Owner**.
* **Public**: Visible to all authorized users.
{% endhint %}
### How to pull content into a production tenant
1. If you click **Remote Repository Content Available** in the navigation bar, the **Content update available** window opens with a list of content available for installation, including content packs and content items.
2. Click **Check for new content** or **Install content**.
3. If conflicts appear, click Resolve conflicts.
4. In the **Action** column, select one of the following:
* **Skip**: Keeps the local content in your production environment.
* **Replace**: Deletes the local content and installs the content from the content repository.
5. Click **Continue** to install the content.
---
# 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 current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam/configure-cortex-xsiam/remote-repository-management/push-and-pull-content.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.