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

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.

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.

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.

We have multiple projects being deployed to different servers in heterogeneous environments. Some are just test-production, others are dev-test-staging-production. The projects often have completely separate environments.

It would be beneficial to be able to either choose which environments a project can deploy to, or to be able to set up per-project environments to be able to keep the same names for config transforms. (ex. "Web.Test.cfg" instead of "Web.Test-Product1.cfg")

Currently the Dashboard is also very "cluttered" with empty boxes due to those environments not being in use for certain projects.

In "Run a Helm update" step we need: Enabled Features -> Substitute variables in files

Why?
For example we need to create configMap for our helm-chart. App config locate in this chart, so we need replase all #{values} by values from project scope

Step helm_install:
1. download chart
2. Substitute variables in files (choose location)
3. in custom script (deployment step) create configMap for our pods

If this feature doesn't exist: we need another step where we download app config and substitute variables and use this file to create configMap

We have "major deployments". At this time we have to deploy all our applications (~ 70) at once. So it would be nice to have a possibility to deploy all projects from environment-1 to environment-2