Deploying to more than one Tentacle (but not all servers)

I have a scenario where I’ve received a new AWS AMI (Amazon Machine Image) and must replace all machine in my environment. I can spin them up and their bootstrap scripts will register with an Octopus Environment as a particular Role. Their next task is to request the latest deploy for their Project/Environment via the Octopus REST API.

This works.

The problem is that they all have to stand in line and wait for their particular code deploy. A deploy to a single machine take about 7 minutes. For an entire system replace, this can take over an hour just to get code onto the new machines. This story is the same for an autoscaling event that adds more than one machine, only less severe.

Could you consider adding a parameter to the POST api/deployments that would allow queuing SpecificMachineIds deployments for a specified period of time and then kick off the deployment?

    'EnvironmentId': 'Environments-1',
    'ReleaseId': 'releases-1',
    'SpecificMachineIds' : [
    'QueueInstall': true

Hi Jonathan,

Thanks for getting in touch.

We are about to release a new feature called Elastic and Transient Environments as part of our 3.4 release that will cater for this very scenario :slight_smile:

You’ll be able to define a project trigger to help automate your deployments per project. Please see the Keeping deployment targets up to date section for more information on creating automatic deployment triggers. Basically, Octopus will be running a scheduler that will detect new machines that come online and will automatically deploy the expected release for you. Eg. the schedule runs every 15 seconds, so all machines that come online within that time will be deployed to automatically (and if multiple machines all share the one deployment, only one deployment operation will be queued for those specific machine ids).

Octopus 3.4 is currently in beta1, but we’re expecting to release by the end of August. If you wish to be notified when this feature is available, you may follow this GitHub issue.

Hope this helps.


Hey Mark,

I was just reading about the Keeping deployment targets up to date feature. I noticed that if an automatic deployment fails Octopus will stop automatically deploying that release. I think the assumption is that there’s something wrong with the Octopus Process steps, but what if the problem is with the machine? We’ve rendered autoscaling impossible until the next release. Not a big deal in DEV, but a deal breaker in PROD. Any chance the “how” to fail could be made configurable?

Deployment Target Trigger:


Individual Machine
x - Don’t try again
x - Try up to [ ] times

Triggers for this Release
x - Stop automatic deployments
x - DON’T stop automatic deployments

Hi Jonathan,

Thanks for the feedback.

If you’re finding that machines are failing or blocking your auto-deployments (because they are occasionally going offline), we added a setting in the project’s connectivity settings to “skip machines if they are or become unavailable” (see the Deploying to transient targets documentation. This will let you deploy your release, even if some of your Tentacles are currently offline (or go offline during a deployment). If you use this setting in conjunction with project triggers, then when these machines do eventually come online, Octopus will automatically deploy for you and make sure they have the latest current release (rather than just fail and then you’re stuck).

With that said, to help deal with scenarios where automatic deployments are blocked or failing (for more complex reasons), we are releasing a new feature called ‘Subscriptions’ in Octopus version 3.5 (planned to be released by the end of this month) that attempts to address this problem…

The idea being, you can subscribe to events that are happening within Octopus, then periodically receive an email (or webhook) regarding the selected events. In your case, you could setup a subscription and notify a project team (via email) every hour for all events related to their deployments succeeding or failing, providing your teams with greater visibility of what’s happening with their project deployments. Or you could setup a subscription that notifies a webhook URL (that you control) so you can be notified as soon as critical Octopus events occur (eg. maybe you write your own Slack notification webhook that notifies your dev team when a deployment fails for a specific project).

Hope this helps.

Mark Siedle