We have a little-known feature that allows someone to run external provisioners outside of the coder server. However, there are some cases where a workspace owner wants to guarantee which "external provisioner/runner" their workspace is built on.

• Runners in specific clouds/datacenters
• Runners on a developer's local machine

Templates can tag which runners they are compatible with, but this isn't done done per-workspace (a workspace may be re-built on a different runner with the same tag, leading to data loss or a failed build).

With an immutable, dynamic, runner parameter on the “create workspace” page, we can do both! Instead of hardcoded values, Coder pulls the list of available runners and perhaps shows latency.

We could also consider this for our dogfood template, removing provisioning load from the Coder server and relying on runners on each bare metal instance to provision containers with their respective local docker sockets. This has an added advantage of builds not failing when we redeploy Coder (we constantly update our dogfood environment when a new commit is merged intomain)

Note
In most (to all) cases, this parameter should beimmutable. I'd actually argue we should not support it being mutable. Migrating a workspace to another datacenter / runtime is risky