Use file as content of variable

Hi there,

Sometimes we need to provision our applications with some additional files, such as configs, server/client certificates (rsa, pfx) or other files in binary format.

Currently, we converting binaries to hex, store hex value as variable in octopus, then within custom script converting back to binary.

So, my question is, do you have any plans to implement something like variable type File (like an attachment) - which will be copied to deployment target as is (for ex, inside custom script)?

Like this:

Or may be there is already implemented such feature, and we do not know about.
Thanks in advance!


1 Like

Hi Maxim,

Thanks for getting in touch!

There are currently some ways that you could achieve this with the current Library options.

Certificates can be added directly to Octopus (Library > Certificates) and then added a variable type and used in deployment scripts using the variables mentioned here:

Other file types would be best added as packages (simple .zips are fine), where they can then be version controlled. You could then deploy them using the standard deploy a package step, or using the referenced package feature within Powershell script steps. I believe the referenced package feature was added within the last year or so, an upgrade may be required if you don’t see it listed in the step currently.

As you mentioned that these files won’t always be needed for every deployment. You could then make use of Run Conditions within the relevant steps and tie that to a variable. It would then be easier for you to control whether the step runs or not based on this variable. Depending on how often you need the step, you could enable the Prompt option on the variable so that it is decided at deployment time whether to run the step or not.


Hi Paul,

Thanks for the quick response!

We are using Certificate feature from library, but its fit only to pfx, der and dem files (and steps that supports certificate variable, ex: IIS Deployments).

Also, we tried to store our files inside Octopus internal feed, but these files need to be changed relative frequently and it’s not convenient to build & upload packages manually to octopus library (we cannot do that in our CI, for different reasons).

Certificate stored within Octopus can be retrieved with any step that allows Powershell or similar scripts to be run using the variables in the link I added. The step doesn’t need to have a specific Certificate variable field.
There has been some recent internal discussions on improving how we handle certificates, so, if you’re able to expand a little on the types of certificates that you’re using, and how you need to be able to handle them during the deployment I can add this to the discussion.

If the additional files are changing regularly, it doesn’t feel like uploading these into variables would be a great fit. The manual work of having to upload the files to numerous different variables seems like it would be about the same as adding them to a .zip file and uploading the package repository.

Would a shared storage location for these files, S3 or similar for example, be easier to update with the new files and access using scripts during the deployments?

Thank you, Paul!

So, variables of this type will not appear in the near future?

We tried many approaches to achieve such result, and for the moment the best solution we found is base64 data inside variable.

But it would be much more comfortable to fave binary inside variavle (to avoid base64 encoding/decoding).

PS: The screenshot from the first post, was an simple example (with certificate file), but I mean that file can be everything we need (image, pdf, archive, dll, whatever).

Best Regards

It isn’t currently something that is on our roadmap, and it isn’t a suggestion that I have come across previously.

I’ve raised this with our products team for them to review further.

Thank you,

Hope this feature will be implemented in next releases.

Wish you a great day!



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