Due to the API limits limiting in-call CloudFormation template length to 51200 bytes, consider enabling the option to load a CF template from an S3 bucket. This functionality already exists in the CLI, and can be done via a script step, but having it be baked in would be an enhancement.

Runbook need support for prompted variables

We need support for prompted variables when using runbooks hope this is added in a future version

Currently there are several AWS deployment templates like one for uploading file to S3 bucket and few for deploying CloudFormation stacks.
The problem with them is that they have a short support of different features we have for traditional IIS or Azure templates. So the suggestion is to add some of these features to AWS templates too e.g

• JSON Configuration Variables,
• Custom Deployment Scripts,
• Configuration Variables,
• Configuration Transforms

Allow kubernetes ingress to specify TLS configuration.

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.

Terraform step templates for Azure deploys. Currently only AWS is supported in Octopus included step templates. It seems like an easy addition to the existing functionality

The new Docker features debuting in recent versions of Octopus are really promising, and I'm excited by the Docker Compose RFC published late last year.

Kubernetes is becoming increasingly popular as the production deployment environment of choice for containerised applications. It offers functionality very similar to Azure Service Fabric, in terms of auto-scaling and self-healing of services and applications, but is based around container images rather than zip files.

It should be possible to clone a tenant including it's current configuration in a similar way to that you can clone whole projects.
Tenants tend to be similarly configured with only minor changes to each one so it would save time rather than having to configure each one from scratch.

Often times with our release we are deploying multiple configurations. With the way octopus stands now you would have to manually go and deploy each project. What we did was created our own tool that uses the API that allows us to deploy multiple projects at once to a particular environment. Something like this might be nice to build into Octopus Deploy itself.

We need to use C# code as script in the script modules

When working with the deployment process I sometimes find that I have to do something in a step that might not be standard, for example setting a temporary user on the "create app pool" step. It would then be great to be able to ad a note to the step describing what is done and why.

When working with library variable sets used in many projects with many steps it is cumbersome to figure out where a given variable is used.

When updating a deployment process, certain tasks become very difficult, such as:
-Renaming or deleting a variable
-Checking validity of a newly-updated variable value across all usages

With a "find all" feature these tasks would be much simpler (plus I'm sure there would be wider-reaching benefits).

It would be great to see Python listed as a script step. Python is heavily utilized in the infrastructure space, AWS, F5, Citrix, VMware and will help to drive full automation further up the stack.

It could be great to have a place where we can use the tentacles to do some tasks without creating a release.
For example, in my release process I have the backup files and backup DB steps. I would like to be able to launch it without creating a release.
I see it as a new tab "tasks" where you can configure some task as you do for the process and it will appear as a button on the different environment where this task is available.

Via @DotNetWise (https://github.com/OctopusDeploy/Issues/issues/1157)

Retention policy helps you to cleanup the mess, but it could possible destroy your live releases.

You DO want to apply retention policy on live servers, but not for those releases you know there are being used / live etc.

Hence, add the ability to lock a release, so it won't be deleted by the retention policies.
Later on, I could unlock it and it will go away on when the next retention policy is being applied.