How to assign permissions for a self-sufficient DevOps team?


We have multiple teams and multiple projects. Each team is reponsible for one or more projects. Each project has one or more production environments and many non-production environments. Production environments are stable. Non-production environments are created and destroyed all the time. The deployment process must be exactly the same for production and non-production environments.

I’d like to have self-sufficient teams, i.e. they should be able to manage everything for their projects without requiring intervention from an “admin” in an ongoing basis.

Members of the team should be able to:

  • Create non-production environments and associate them to a designated Project Group (so that the project can be deployed to those environments).
  • Add/delete machines only to/from those environments.
  • Promote releases to all those environments.
  • NOT create releases (only the Continuous Build Server can create releases).
  • NOT upload, delete, edit, etc. NuGet packages in the Octopus NuGet server (only the Continuous Build Server can create those packages).
  • NOT have access to any other projects or environments.
  • NOT be able to change permissions or access any system-wide settings (not be an admin).

This is the closer I’ve gotten to it without resorting to making everyone an admin:

  • Admin creates a Project Group for the project.
  • Admin creates the Project for the project.
  • Admin creates Team-Production for the people authorized to deploy to production environments.
  • Admin creates the production environments with its machines and associates them with the project.
  • Admin assigns “Project Deployer” and “Environment Manager” roles to the Team-Production restricted to the Project and the production environments.

Here ends the production configuration, which is working as we want.


  • Admin creates Team for the team.
  • Admin assigns “Environment manager”, “Project deployer”, “Project lead”, “Environment creator” to the project Team restricted to the Project and to the non-production environments.

However, with this solution members of the team cannot create new environments or associate them with the Project Group (despite the ‘Environment Creator’ role) which implies that the admin must create new non-production environments, associate them to the Project Group and add them to the list of restricted environments in the Team permissions. This is not scalable because as I said, non-production environments are created and destroyed all the time.

How can I allow teams to do whatever they want with their project, except for the production environments?

Thanks for any help.

Hi Rodolfo,

Thanks for the detailed description. I don’t think the current permissions system can adapt precisely to these requirements - some modifications to support it would be possible but I suspect they’d be some way off, since the “create environment + extend team permissions” requirement is tricky to envisage as a feature.

Given the problem is mostly creating/deleting non-production environments, would it work for you to create a small self-service portal to do this? The Octopus API (exposed also as Octopus.Client for use in C#) would make this fairly simple to implement, and we can provide instructions if needed.

What do you think?

Best Regards,

Hi Nick. Thanks for your response.

I believe this scenario is reasonable and common enough so I’d love to see Octopus supporting it natively. I agree “create environment + extend team permissions” is not a nice thing to implement as a permission but what about:

  • Create the concept of Environments Group (consistent with other areas of Octopus)
  • The “Deploy to”, “Add Environment”, “Edit environment”, “Edit machine”, etc. permissions can then be restricted to "Environment Group"s.

This would allow me to create 2 environment groups: Production & Non-production and it would be trivial to solve the problem.

That sounds as a reasonable feature to me. Consistent with other Octopus features which could solve other problems and inconveniences with environment management in Octopus, and will remove the only blocker I’ve found to having self-sufficient teams :slight_smile:

It’s even more consistent with the rest of Octopus: user groups (Teams), Project Groups, but no Environment Groups.

Would you consider something like this?

Can you also please send me the instructions to proceed as you suggest?


Hi Rodolfo,

Yes, I believe you’re on the mark RE environment groups; we’ll have an opportunity to revisit this in the future and will definitely give it consideration.

To implement a self-service portal/script for this, you’ll need to create e.g. an intranet website using something like ASP.NET.

Instructions for getting started with Octopus.Client are at:

Ideally you’d create a Service Account with admin privileges in Octopus, and use its API key to configure Octopus.Client as the code sample at the linked documentation shows.

Then, to create a new Environment the (pseudo-)code looks like:

var newEnv = new DeploymentEnvironment { Name = "Some environment", ... };
var asCreated = repository.Environments.Create(newEnv);

To add this to the set of environments available to a team:

var team = repository.Teams.Get("teams-1234");

Let me know how that fits with what you’re thinking.


Hi Folks,

Just to jump in here, there is a UserVoice for creating environment groups, but as you can see so far it doesn’t have much support from the community, so if anyone reads this thread looking for a similar solution go here:

And vote! or comment! or both!

As in life, features in Octopus are definitely built based on popularity.


Thanks. I’ll give this a try.