Aws cli

This seems like a noobish problem, so I apologize if the answer is really obvious.

I’m trying to run an AWS CLI step in a deployment, using a Default Worker and Powershell, and in the script window I tried running ‘aws lambda…’ but got the error “ObjectNotFound: The term ‘aws’ is not recognized as the name of a cmdlet…”

So then I tried using the cmdlet Update-LMFunctionCode and got a similar error of “ObjectNotFound: The term ‘Update-LMFunctionCode’ is not recognized as the name of a cmdlet”

Can someone help me what I’m doing wrong? Thank you!

Hey @pjohnson,

Thanks for reaching out.

Depending on the version of Dynamic Worker the Default Worker Pool is set to use, they come with different tools: Dynamic Worker pools - Octopus Deploy

Unfortunately, no matter which one you choose, they wont have AWS CLI. However, we do have a feature to help with this, Execution containers.

When choosing which version of worker tools you want to use, there is a tradeoff.

You can choose to use the latest version (untagged), which will typically have the quickest download time to your worker because we bundle a version of the docker image close to the latest, but the downside here is that your tool versions will get updated regularly which may cause instability if you are depending on a AWS CLI cmdlet that gets deprecated, or if Amazon introduces a bug into their tool.

The alternative is to pick a version and stick with that version. The downside here is that as the worker tools that get bundled with the dynamic worker get updated over time, this will cause more drift with the static version you chose, which means the download time will increase over time and this will cause some initial delay when you are leased a new worker.

Please let me know if that helps or if you have any other questions.


Right on, thank you. I’ll give it a go and see what I can come up with.

Quick followup: it sounds like maybe that image is in a registry that Octopus makes available…? Or do I have to host the image in my own container repository?

Hey @pjohnson,

We host them on dockerhub under octopusdeploy/worker-tools.

You can set up your feed like this to use in the step:

If you want to make your own execution container with your own custom set of tools, you would just need to find hosting and set up a docker registry in your Octopus feeds and use that.

Please let me know how it goes!


Well isn’t that obvious and embarrassing for me! However, thank you for being patient and I am grateful for your time helping me out!

Hey @pjohnson,

You’re very welcome and no reason to be embarrassed! That’s what we’re here for.

Please let us know if you have any other questions or run into any other snags.

I hope you have a great rest of your week.


Thanks Jeremy! The current hurdle is “Unable to connect to docker service” regardless of which container I try to get from Docker Hub. I tested it through the external feeds and am able to search for images in the repo there, and I’m using a free login to auth against Docker. Any thoughts what I might be up against?

OMG never mind, I see what I’m doing wrong, running the job in a container instead of on the worker. sigh … wait, is that really the problem? (This is a “run an AWS CLI script” step type)

Hey @pjohnson,

Are you using our Dynamic workers? If so, can you go to Infrastructure and check which type of workers are being used in that worker pool? Windows Server 2019 workers should have docker installed on them by default. If you have a 2019 worker, it’s possible that you got a bad worker.

If you aren’t using our Dynamic workers, can you please try remoting into those workers and running docker version on them in PowerShell? It’s best to run this logged in as the Service Account that runs the Octopus Tentacle service to make sure there’s not a PATH issue.

Please let me know what you find.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.