Octopus supports Terraform-Steps. It uses Terraform 0.11. Terraform 0.12 has been released and has a few breaking changes. Update the Terraform-Integration to be compatible with Terraform 0.11 and 0.12.

Helm 3 is around the corner. Right now rc2 is available. Would be nice to Octopus could integrate with 3rd version of helm. Eg. Repositories will be available as container registries also. Are you guys plan to integrate with third version ?

It would be nice if I could clone steps inside processes. For example if I want to deploy two nuget packages, I need to create one step to deploy a nuget and again create another step to deploy a nuget, instead of just cloning it. It's a waste of time!

We're working on a few Mac minis to be our iOS build servers. We use (among other things) Homebrew as our package manager. For a variety of reasons, we need the Octopus CLI tool installed on these Mac Minis. You guys support MacOs, but it doesn't look like you've added the CLI to Homebrew.

While I was tempted to add it myself, I figured I'd start with suggesting it here.

I would love to see built-in support for Terraform (https://www.terraform.io/). Deployment steps for each Terraform operation like "plan" and "apply" and also a Terraform backend plugin for storing state.

octo.exe is a great tool that wraps much of the Octopus Deploy API. It would be great if we could specify a parameter --output-format=json or --output-format=xml to have octo.exe generate its results in a machine-readable format for further scripting (e.g. in an environment where I have an older version of Powershell without access to modules such as Octoposh).

I know you are based in Australia, but if there is any way to have some limited support hours in the USA time zones, that would be extremely helpful. It's kind of rough only being able to get maybe one interaction per day with the time zones what they are.

To create the ultimate overview on your Visual Studio Team Services (VSTS) Dashboard it would be great if Octopus offers a widget where you can see the Octopus dashboard overview for your project.

More information on VSTS Dashboard widgets: https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/add-dashboard-widget

Currently it looks like Octopus uses the userPrincipalName when syncing/authenticating users from AD. Since the UPN may change (for instance when migrating users to Office365....), users will suddenly end up with a new account in Octopus when loggin in using Windows Auth.

Using the samAccountName (as is more common) should allow users to keep their Octopus account/profile in situations like this.

We have an environment where there are a mixture of employees / vendors who need different levels of access to different resources in Octopus. No problem. However, I've got a mixture, some who have just local accounts in our Gitlab & Octopus environment, and those who have AD accounts because they use Gitlab, Octopus & other resources in our environment. If it were possible select whether an Octopus user authenticates off of AD or local, that would be MOST EXCELLENT!

We currently are writing many powershell scripts to work with octopus deploy as part of our deployment and then having to keep a copy in our github repo to be used by the devteam. I'd like a way for octopus to have access to the repository and notice there are changes and allow for a manual update, as it currently works.

Today /api/projects (and other api endpoints) has a default limit of 30 item per page.
We would like a take parameter in order to get more than 30 items.

Provide some really good guidance to help people use AppVeyor and Octopus together.

In the Continuous Delivery book, Jez wrote that your deployment scripts should be in source control. After creating some pretty elaborate powershell scripts for Octopus, I have to agree. Losing those scripts or having them damaged would be pretty painful.
I understand Octopus has backups, but it would be better to be able to get back to a previous version or see where the script had changed. Since we use GIT, I would be completely satisfied if GIT integration was all that you supported. :) I hope this is helpful. Thanks.