Management approval on "Promote"?

As I’ve explained in this ticket, we want deploys from our non-PCI compliant development environment to a PCI compliant environment. This both requires network segregation and management approval.

While I don’t think we’ll get anything more optimal than duplicate Octopus Deploy instances for the network segregation problem, we would love to be able to do the management approval by just restricting who can promote a release to stage and production.

Our current implementation is a custom intervention step in the stage and production environments that needs to be handled by people in a specific group. While this sort of works, there’s as far as I understand nothing that can restrict developers from changing this behaviour by disabling the step or not adding it in the first place. Therefore, it would be nice if we could just restrict who can push the “Promote” button for a given release to the stage and production environments.

We can move the management approval to the Octopus Deploy instance in the PCI environment, but we would like to do it earlier, since what’s deployed in the non-PCI production environment may have dependencies on what’s deployed to the PCI environment, so they should preferably be done at the same time.

We also can’t restrict who can create a release, since every environment up to stage should be within developer’s full control. Developers also need to be able to administer the projects, environments, etc.

Can you please guide us in figuring out how this management approval can be implemented as securely and smoothly as possible?



Thanks for getting in touch! We are currently in the stages of writing an RFC blog post for a new Promotions feature that is outlined here:
Please keep an eye on the blog post to read about the feature and add any comments for your needs as it should address the PCI compliance and multiple instances scenario very nicely. We are hoping to have this published by the end of the month.

In the mean time you can restrict what users can deploy to different environments using our permissions. You can have users in multiple teams with different permissions for each environment. So your developers could have promote and deploy for every environment up to staging, but not deploy for production. We have a documentation page explaining how mixed environment privileges can be attained:

Please let me know if you would like anything explained in more detail or if I can help with anything else :slight_smile:



I just wanted to give you an update that the Remote Release Promotions RFC is up on the blog if you haven’t seen it yet:

We would really appreciate any comments that you have regarding the design and concept.