Consistent Project Variables across all environemnts

I have a project with QA and Production environments, this project having some variables which being set using Jenkins step or by Octo cli.
The deployment is executed successfully when deploying to QA as the variables already have values but when deploying the same release manfully the variables are empty and I have to set them manually.
Is there a way to force the variable to have the same initial values?
Thank you

Hi farouk,

Thank you for contacting us with your query.

You can set a default value for each variable by adding an entry with no scope specified. Octopus will try to select variable values based on scope and will fall back to the variable with no scope specified if it doesn’t find a better match first.

You can find out more about scoping variables (and see an example of how to set a variable with no scope specified) on the following page:

I hope this is helpful. Please let me know if you have any questions.

Best Regards,


Hi charles,
Thanks for your reply, just want to inform you that the variables doesn’t have a default values, they are set to a different value for every deployment.
In more details: for a specific deployment, the variables has the same value across all environments, this value is passed during the initial deployment to QA using Jenkins and it works fine but when I click deploy to production from Octopus UI, the variables shows empty.

My workaround: In the initial deployment I get the variables values and store it in a separate text file on a specific folder with release number as part of file name, and when deploying to production I’m reading these values again from this text file and use them.
I raised my question just to make sure is there built in functionality to achieve it or not .

Hi Farouk,

Thanks for following up and sharing your solution! Unfortunately persisting prompted variable values through promotions between your environments is actually not currently a built-in function with Octopus. A couple users have requested this in the past, and heard them do essentially the same thing (i.e. store variables in a text file, and read them again during subsequent deployments) which works but doesn’t feel super nice.

We’ve had some discussion internally around the concept release-prompted variables as opposed to deployment-prompted variables, but I think the only thing public is this UserVoice suggestion.

Sorry it’s not better news, but glad you have a workaround to this limitation for now. :slight_smile:

Let us know if you have any questions or concerns in the future.

Best regards,


Hi Kenneth,
Thanks for your reply, hope to hear good news and have this feature to be implemented soon

HI Farouk,

Thanks for the followup! Unfortunately I don’t think we’ve committed to it, so I couldn’t provide anything like a guarantee or ETA, but I’m also hoping it can be seriously considered and prioritized at some point. :slight_smile:

Please let us know if we can try to help with anything else moving forward!

Best regards,


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.