Public IP address required for onprem deployment target?

Do listening tentacles need a public ip address if using Octopus Cloud?

We are looking to migrate our projects from onpremise/self-hosted to cloud Octopus. However we have some deployment targets that are physically in our premises and will remain that way. When I go to create a deployment target as a listening tentacle (which seems to be the recommended option) it asks me for an IP address or hostname. If I enter a private IP address I imagine it won’t be accessible from Octopus Cloud or am I missing something? These machines don’t have public ip addresses and I expect our IT Manager won’t be keen on giving them any. Is a polling tentacle my only option?

Hi Darren,

Thanks for getting in touch!

That’s correct, the listening tentacle would need to be accessible to the internet either via IP or DNS in order for the server to connect to them.

Polling Tentacles are likely the better option for your situation, as the connection is reversed. The Tentacle reaches out to the Cloud instance, so, the only required network configuration is outbound access on 443 and 10943 (assuming default port usage).



Thanks Paul

Is there any easy way to switch the existing deployment target tentacle mode or is it a case of having to uninstall and reinstall?

I’m assuming that there may be a period where you would want these targets to be able to communicate with both the On-Premise and Cloud instances?

if so, you can run multiple Tentacle instances on the same installation. So, the best option here would be to configure a second polling instance on these targets that communicate with the Cloud server.

This can be done using the Tentacle Manager UI

Or with a script similar to this: Automating Tentacle installation - Octopus Deploy

Once your migration to Cloud was complete and you are ready to remove the On-Prem Listening tentacles you would just need to run the delete-instance command across your deployment targets.

1 Like

Hmm it’s a good point. Thanks for the great advice. We aren’t planning any deployments to these particular targets until after migrating, so in this particular instance I could possibly get away with an immediate cut-over from listening to polling. I guess in this situation it would be a case of just deleting the existing tentacle first before adding the new one? i.e. the reverse of your guidance above. That would let me use the same name again.

If by “same name” you mean the name of the Tentacle instance within Tentacle Manager then yes, you would need to delete the current instance and then add the new one.

If you mean the deployment target name as it appear in the Octopus UI then as this would be two separate Octopus Server instances there is nothing stopping you having the deployment target named the same in both of them.

1 Like

Sweet! I didn’t realise the instance name is separate from the deployment target name
Thanks again.

1 Like

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