Deploying to one machine at a time in an envronment

Normally when deploying to a production environment we take a server out of set on the load-balancer, deploy to that server and then have it manually tested before moving onto the next server. This may not be how we continue to do things in the medium term, but it is for now.

The easiest way I can think of solving this would be to have a list of check boxes with the machines in the “deploy” overlay. So when you click deploy, rather than just getting a drop down with a list of environments you would also get a list of check boxes showing you the machines in that environment and allow you to select which ones to deploy to (much like the ones in the “Edit Deployment Step” overlay).

I guess this falls down a bit when showing an overview of the version deployed to an environment (like on the home page). This display would need to be a bit more complex - it would need to show deployments in process rather than just success/failure.

I think this is the only real issue from stopping us using Octopus in all environments.

As a workaround I guess we could create an environment for each server in production. That would work, but would become a bit difficult to manage for more than a few projects.

Looking forward to the auto-updating tentacles!


Hi Stephen,

What if one of the ‘deployment steps’ in Octopus was a manual pause?

Then you would set up your steps like this:

Package A -> Machine 1, 2
Package A -> Machine 3, 4

In the Pause step, you could enter instructions for what the person should check. During the deployment, Octopus would wait for someone to manually click a ‘Continue’ or ‘Abort’ button in the Octopus UI when a Pause step was encountered.

Would this help to solve your problem?

Paul Stovell
Deployment getting you down? Try Octopus, convention-based automated deployment for .NET
Web: | Blog: | Mob: +44 7 999 321 695 | Skype: paulstovell

Hi Paul,

Thanks for the quick reply. Yeah, that would absolutely solve the problem. Is that something that you would consider implementing?


Hi Stephen,

You can monitor the progression of this suggestion, and vote for it, on the Trello board:

It is titled “New deployment step: Manual”


Any updates on this? Is it part of the product at this point? Or are there existing workarounds? We are using the exact approach as mentioned in the original suggestion - load balancer, take one machine at a time and then do the upgrade… so in order to successfully use Octopus Deploy we’d need some sort of way to accomplish this.


I haven’t seen this functionality in the product yet. You could work around this by having multiple production environments, i.e. Prod A, Prod B. After deploying and testing a package in Prod A, promote that same package to the server in environment Prod B.

Hi Kevin,

As Nathan said, having two environments would be the way to go in the current release.


I’m ok with creating say, Production-Web1 and Production-Web2 as separate
environments and then promote between the two.

My only question would be - in terms of web config transforms, Octopus
expects there to be a web.environment.config file with the appropriate
transforms. So my concern would be instead of having a
web.production.config like I do now, I’d have to have
web.production-1.config and web.production-2.config with the same content?
Or some sort of pre-deploy script that makes two additional copies of

Hi Kevin,

That’s correct, you can use a PreDeploy.ps1 script to rename web.production.config to “web.” + $OctopusEnvironmentName + “.config”. That variable will hold the name of the environment so you can use it to base your logic on. The code that runs the config transforms runs after PreDeploy.ps1, so it will work.


Thanks Paul, this will do the trick for now. Really enjoying working with
Octopus so far, looking forward to using the retention policies in the next