To properly answer this question, it is important to understand the basics about dynamic workers.
The TL;DR; of that article is dynamic workers are workers running on VMs which Octopus Cloud controls the lifecycle. The VMs are running in the same region as your Octopus Cloud instance.
One important item to note with dynamic workers is they are shared across all spaces on an Octopus Cloud instance. If you have multiple spaces doing multiple deployments at a time, and those deployments require a worker, then the same dynamic worker will be used.
Reasons to use dynamic workers
The infrastructure is already there and ready for you to use. You don’t have to manage anything. They are useful for the following tasks:
- Spinning up and down cloud infrastructure using AWS CLI, AWS CloudFormation, Azure ARM Templates, Azure CLI, or GCP CLI.
- Running PowerShell or Bash scripts containing business logic which set output variables.
- Sending notifications to third-party chat clients such as Slack, Teams, or Jabber.
Reasons to use (self-hosted) static workers
Dynamic workers are useful, however they do have limitations.
The main limitation is they are not running in your infrastructure. That means to do certain tasks, like upload to S3 or run SQL scripts against a database, then you’d have to open up some ports / settings. In that case, we recommend using a worker in your infrastructure. You’d have to open up port 10933 (inbound) OR port 10943 (outbound) instead of port 1433 or updating your IAM roles.
Another reason to use static workers is if you need specific versions of software installed on a worker. No matter what, dynamic workers will be destroyed after 72-hours. And if you don’t use a worker for an hour, it will be destroyed as well. You could spend quite a bit of time waiting for software to be pre-installed.
Finally, static workers can offer better performance. All dynamic workers are a 2 core / 4 GB VM. You can throw more resources at a worker (or workers) if you need the fastest possible performance.