Run multiple custom scripts after deploying a package


Version: 2018.6.14

I’m using Octopus Deploy to install an ASP.NET MVC application across multiple web servers. Here is my scenario:

  1. [All Servers in Parallel] Deploy a package. The Deploy.ps1 within the package is run to install prerequisites.
  2. [One Server Only] Custom script from the package for database updates.
  3. [All Servers, One at a Time] Custom script from the package for web site updates.
  4. [One Server Only] Custom script from the package for post-install wrap-up.

I can implement the above using Deploy.ps1 within the package for #1 and the ‘Run a Script’ step for #2-4. HOWEVER: The Run a Script step redundantly re-downloads the package each time, increasing deployment time by (in my case) 15 seconds per step. I’d really like to avoid this.

What options do I have? Is it possible to avoid the package re-download WITHOUT embedding the script in the step?


Hi Jason,

Thanks for the detail regarding your project scenario, this is a great help.

Regarding your question regarding the ‘Run a Script’ step, something doesn’t seem right to me: we do check to see if a package is already available on the target machines file system before attempting to unzip it for each step.

To try and replicate your issue, I have put together a project to mimic your requirements, I used two machine roles - one for web & one for database, and a package with 4 powershell scripts in it [called ‘app’]. The project has 4 steps - 1 Deploy a Package and 3 subsequent Run a Script steps that reach into the package and use the required script.

I couldn’t get to a place where the same package was downloaded twice on the same machine. What this did highlight to me though, was that each step would extract the contents of the package each time. If you have lots of files in the package then this might explain a 15 second delay.

If that is the case for you - I would recommend splitting the scripts off into a separate package and uploading that OD Server, from your Build Server at the same time as the original package.

I thought it would be helpful if I deployed my replication of your configuration to two machines I have here and so that I could get some examples of what you should expect to see in the logs.

During the package acquisition phase, you should see something like this for each machine:

No earlier versions of app were found on the target so we can't perform a delta upload. 
Uploading package app (534 B)... 
Beginning streaming transfer of 
Stream transfer complete 

Note that the package gets a unique ID per machine.
In the first step, you should see a log like this for a given machine:

Deploying package:    C:\Octopus\Files\ 

Later, in the Run a script step, on the same machine, you should see logs indicating that it is extracting from that same package:

Extracting package: C:\Octopus\Files\ 
Substituting variables in: C:\Octopus\Work\20180723013909-114-8\deploy-website-changes.ps1 

Hopefully this helps! If you don’t see a similar pattern of behaviour in your deployment logs, please let me know and we can arrange a secure drop of some of your server logs for me to analyze.

Kind regards


Thanks for the response, it was really helpful. I do think that the 15 seconds I’m seeing for each ‘Run a Script’ step is due to the cost of unzipping. The package has several thousand files.

I’m going to try splitting the scripts into their own package as suggested and will report back.

Thanks Jason,

No problem, I look forward to reading about how you went.

All the best


I tried using a separate package and it’s working well. The per-step cost isn’t zero but it’s down to a second or two which is just fine.

Thanks again for your help!

That’s great! It was a pleasure to be of assistance.

Happy deployments!

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