Create a referenced package with a changing number of packages


With my project I want to create a deployment process where it changes how many packages there will be deployed.
We have a product with different namespaces, I want to be able to deploy number of packages that are changed and to be able to deploy a new package if there is a new namespace.
I can create different referenced packages in my “run a script” step, but I want to only acquire the packages I need in that release.

For example:
Today I want to release package A, so I want a referenced package in my step for package A.
Next week I want to release package A and B, so I want a referenced package in my step for both packages.

I want it in one project and without adjusting the process or the steps, because the only thing that changes are the packages.

Can I use a variable with a list of packages I want to deploy?

Hi @dominiquevanzaanen,

Thank you for reaching out, and welcome to the Octopus Deploy community!

As an initial step, I wanted to link a nice article we have that discusses this functionality from both a conceptual and pragmatic point of view:

Octopus Deploy: Dynamically Selecting Packages at Deployment Time

I’d recommend reviewing the above article to see if these concepts will meet your use case, and then you can explore implementing this within your own process (if applicable).

Octopus Deploy also has the ability to determine the packages needed for a release by tenant or environment, and many times this can be a better way to distinguish this in your process (rather than dynamically determining the package name within your process). This section of the previous documentation I linked speaks to this, but let me know if you have any other questions.

I hope this initial information helps, but feel free to reach back out if I can be of any more assistance.

Best regards,


Hi @dominiquevanzaanen,

Apologies, I was rereading your post and realized my answer was related to your question, but not as precise as it could have been.

The information I linked previously would be for dynamically determining a package name within a deployment process, but in your case, it sounds like you’d be dealing with a variable number of packages (rather than changing package names) - sorry for the initial confusion! (and also let me know if I’m missing anything).

I’d imagine there are a few ways you could do this, but here is what I was thinking initially:

Option 1:

Use channel version rules and pre-release tags to dynamically determine the packages required for a release. In this scenario, your pre-release tags could line up with your namespaces, which would keep things organized in Octopus Deploy, and this would determine the packages pulled in during each deployment. This approach would allow your process to exist mostly as it does today, and the package filtering would happen at the channel level.

Option 2:

If possible, change your process to allow for the same process to occur in each namespace, and programmatically pull things from each package as needed based on some additional logic in your process (essentially pulling every potentially applicable package and referencing things as needed). This approach would have the benefit of standardizing your process while also allowing you to handle custom execution behavior on a per-namespace basis (i.e via prompted/tenant variables).

Option 3:

You could have a prompted variable in your process that determines what should be deployed. This value could then be used to determine the actions taken in future steps by scripting out the required actions based on the input variable. This approach might end up circumventing the built-in package functions to pull these packages programmatically, depending on how it needs to be implemented in your process.

Option 4:

Create tenants for each namespace and associate the package differences as tenant variables (i.e. you could have a numPackages variable, as a basic example), which you could then key off of in your process in order to determine the required packages. This may also result in circumventing the built-in package reference functionality depending on what things look like in your process (so you would essentially be recreating the package acquisition functionality on your side in order to handle a variable number of packages in your process).

I hope this additional information helps, but let me know if I can be of any more assistance.



Hi Britton,

Thanks for your repsonse! I have tried option 4 and it seems to work. I will test with it further and keep the other options in mind. Thank you.

Best regards,


Hi Dominique,

You’re welcome, I’m happy I could help, and I’m glad you were able to get something set up for this!

I hope your testing goes smoothly, but feel free to reach back out if you run into any trouble.