Deployment start/end scripts & databases

In our current TeamCity+MSDeploy world our deployment script takes the target website and services offline (App_Offline.htm), MSDeploy-s each website and each service to appropriate machines, then runs the database migration scripts, starts the services, and then removes the App_Offline.htm.

What’s the best way to approach this with Octopus? The website, services and database each go to different servers so I’m assuming these need to be seperate NuGet packages.

Would we need a seperate NuGet package for the initial ‘turn off XYZ’? And for our database scripts, would this be a separate NuGet package too? Any tips on the easiest way to create these NuGet packages if they don’t have a Visual Studio project associated with them?



Hi James,

You could do them as PreDeploy.ps1 and PostDeploy.ps1 files in your normal package, however they may not all run at the same time on all machines.

Otherwise yes, they’d need to go into their own packages which would become the first and last steps of the project.

The easiest way to create them is to put them in a folder under source control, and call NuGet.exe pack from the command line.

If you are using TeamCity 7 or above there is a NuGet Pack build step you can use to create the package, otherwise you can download the NuGet command line from here:


Thanks Paul. I think for now we’ll go the seperate nugets for pre/post. Would be cool to have some nicer way though when you might not want to re-enable a website until some dependent services have been deployed in other steps.

Some kind of global pre/post deploy ps in each package that gets called after all the packages have been pushed to the server but before they deploy? Maybe too confusing though!!

Sent from my mobile

It will probably be solved by this:

You could wrap the app_offline.html in a PowerShell script, then have it run on a single machine or many machines. It can accept variables and everything just like normal, only it doesn’t have to be bundled in a NuGet package.


Hi Paul,

I’m just coming around to looking at this again. We ended up just using Pre/PostDeploy.ps1 to put an App_Offline.htm file in place during deployments for our websites, but the problem with this is we really need them offline for the entire deployment process, not just their individual deployment step.

Now there’s support for PowerShell steps directly the plan was to create a step at the start and end of the deployment. However, because there are multiple websites to turn off, I’m not sure how to best to work out the correct paths to the web directories?

For instance, if we need to change files in


The problem is that the version numbers are obviously specific to the package, but $OctopusPackageVersion is not available (because there are multiple packages). And $OctopusReleaseNumber is not necessarily going to match (for instance we use

There also seems to be no way to get the “C:\Octopus\Applications” path though we could just hard code that. Any suggestions on how to achieve this?


I’m interested in doing this as well. It would have to be separate steps in order to surround website and database deployments across multiple targets. My complication is also that the target is an Azure web app. Presumably this makes it harder to work with at the powershell level rather than just using a package as it needs to hook into the OD Azure account management as well.

Hi Rory,

Thanks for sending this through our forums and off twitter. I think one of the key aspects here really is Azure and the limitations attached to it.
We were thinking about a workaround like follows:

  1. Make a special package that just has the app_offline.htm file in it, and deploy that to the Web App, making sure to preserve files at the target (That would take all of the web apps offline)
  2. Do the database upgrades
  3. Deploy the web app, which should do a sync, and realising the app_offline.htm file shouldn’t be at the target, remove it.


Thanks Vanessa, that was my thinking as well. I’ll give that a go with the team in the next week.