So sensitive project variables will be referenced from Azure Key Vault instead of being stored in octopus.

https://azure.microsoft.com/en-us/services/key-vault

3357461 - 'Azure Resource Manager Key Vault support' was only about ARM template Key Vault support.
17973586 - 'Integrate Octopus deploy with secrets managment system Vault' is similar to this issue only for https://www.vaultproject.io

This idea is similar to
https://docs.microsoft.com/en-us/vsts/build-release/concepts/library/variable-groups?view=vsts#link-secrets-from-an-azure-key-vault-as-variables

Currently when deploying a project containing one or more Deploy Release steps (https://octopus.com/docs/deployment-process/coordinating-multiple-projects/deploy-release-step), there is no ability to preview the deployment steps that will be executed in the child deployment, nor the ability to exclude machines from the child deployment.

It would be nice to surface this information on the create-deployment page of the parent project.

I would like to create automatic release version based on the package version from TFS or JFrog repository,Basically i would like to schedule the release creation and deploy to some environment . I would like to use the version number from the package rather create on its own? Any thoughts if this is already supported?

When adding a binding to IIS in Octopus, you can only use seperate variable. Every binding needs a new variable. Some of our deployments have over 50 bindings. We create each binding separate. If we use a variable list only the last item of the list end up in de IIS binding. It would help us a lot if we could ad three generic bindings (Test, Acceptation, Production), en in the bindings use a variable list, containing all the IIS bindings.

Allow package deploy steps to select multiple packages that are deployed in the selected order (with the ability to change the order). We have a website where we deploy a clean copy of a vendors files (makes upgrades easier), then we overlay different 3rd party modules and our solution into the same folder. These packages together create a whole website.

I would like to see the "pipeline as code approach" applied to projects. The main idea is to be possible to define the process of a project using a yml file in a source code repository or package.

When deploying; If selecting "Include all applicable Tenants", and there is a issue with one of the included tenants you have to deselect all, and add them one by one.

I suggest that when "Include all applicable Tenants" is clicked, the possibility to deselect a specific under tenant under 'Preview and customize' tab would be much wiser.

Currently to change the order of environment inside a Phase you need to remove the environment from the Phase and then add it back in the right order.

It would be great to add a reorder button

We keep our deployment configurations in octopus variables and use json substitution the replace them on deploy time

This could be improved in a few ways:

- Use the json variables substitution feature on other step templates than deploy a package (for example: run a script)
- have to ability to substitute also yml files
- give a variable a null value, the only option now is tho give him empty string, which influence the code.

The 'Deploy to Service Fabric' process does not provide all the available security mode options available in Service Fabric, we are doing a POC around an on-premise SF cluster using a gMSA which the Fabric will run under the context of and Windows Identities to allow client-to-node communication. the option for using Windows Credentials (in this case it would be the Windows Service Account which Octopus is running under the context of) to connect to the cluster is not available! i.e.

Connect-ServiceFabricCluster -ConnectionEndpoint <cluster-domain-name | server hostname>:19000 -WindowsCredential

Add repository retention feature for external feeds. I'd like to be able to manage package retention on external feeds in the same way that they are managed for the internal feed automatically deleting unreleased packages after a number of days

Add a deployment feature to the Azure Web App step that maps Azure's AppSettings and Connection Strings to Octopus variables. It was suggested to use a script to do this on your blog post (https://octopus.com/blog/azure-functions), but this would be much more valuable as a built-in feature since it is such a common scenario.

I've uploaded an example image of what I imagine the UI would look like to: https://imgur.com/a/BwL4Tuh

Like many others, we use Terraform to manage our cloud infrastructure and it would be great if we could create and manage our octopus setup in it too.

This is a follow up to the question posted on the Octopus Help section: https://help.octopus.com/t/any-plans-for-an-octopus-terraform-provider/20853

Currently if you choose "Include only in tenanted deployments" when adding a new Certificate to your library you are required to:

A) Select all of the tenants to be associated with that Certificate
B) Select a Tenant Tag to associate with the cert

This is restrictive. Why can't all Tenants just have access to the Certificate? When you only do Tenanted deployments you have to remember to tag the newly created tenant or go back to the cert and add them to the list. Its cumbersome to maintain.

There should be a toggle for ALL tenants on the cert.