Transferring Packages With A Separate Project

One way to transfer deployment packages to your Production environment prior to a deployment is to use a separate project to handle the package transfer.

Package transfer project

In this example, I’ve configured a separate project named OctoFX Package Transfer. This project is used only to transfer the packages used by the OctoFX project and does not configure the applications.

It follows the same lifecycle as the project that configures the app, but you could also limit it to just the environments that need the packages beforehand.

Package transfer process

The deployment process for the package transfer project contains the steps to transfer the same packages to the same targets as the main project.

You can add in any other checks or steps that you would also like to perform (compliance, verification, notifications, etc).

Acquisition logs from transfer project

We can see that the packages were uploaded to the targets when deploying the release in the transfer project.

Acquisition logs from main project

We can see that the packages were found in the cache and not uploaded when deploying the release in the main project.

Pros of this approach

This approach to transferring packages ahead of deployments has the following benefits:

Simplified deployment process management.
No extra environment or target configuration required.
Release creation for main application deployment project doesn’t require duplicate package selection.

Cons of this approach

This approach to transferring packages ahead of deployments has the following benefits:

Requires multiple projects with releases that have the same package versions.
Difficult to enforce transfer happens before application deployment.
Difficult to promote changes that have already been transferred.

Learn more

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback

Page updated on Wednesday, November 5, 2025

Edit on GitHub