By default, the Coder server runs

[built-in provisioner daemons](../reference/cli/server.md#provisioner-daemons),

which execute`terraform` during workspace and template builds. However, there

aresometimes benefits to running external provisioner daemons:

areoften benefits to running external provisioner daemons:

-**Secure build environments:** Run build jobs in isolated containers,

preventing malicious templates from gainingshell access to the Coder host.

preventing malicious templates from gainingsh access to the Coder host.

-**Isolate APIs:** Deploy provisioners in isolated environments (on-prem, AWS,

Azure) instead of exposing APIs (Docker, Kubernetes, VMware) to the Coder

times from the Coder server. See

[Scaling Coder](scaling/scale-utility.md#recent-scale-tests) for more details.

Each provisionercan run a single

Each provisionerruns a single

[concurrent workspace build](scaling/scale-testing.md#control-plane-provisionerd).

For example, running 30 provisioner containers will allow 30 users to start

workspaces at the same time.

Provisioners are started with the

[coder provisionerd start](../reference/cli/provisionerd_start.md) command.

[`coder provisionerd start`](../reference/cli/provisionerd_start.md) command in

the[full Coder binary](https://github.com/coder/coder/releases). Keep reading

to learn how to start provisioners via Docker, Kubernetes, Systemd, etc.

The provisioner daemon must authenticate with your Coder deployment.

The provisioner daemon must authenticate with your Coder deployment. If you have

multiple[organizations](./organizations.md), you'll need at least 1 provisioner

running for each organization.

Set a

[provisioner daemon pre-shared key (PSK)](../reference/cli/server.md#--provisioner-daemon-psk)

on the Coder server and start the provisioner with

`coder provisionerd start --psk <your-psk>`. If you are

[installing with Helm](../install/kubernetes.md#install-coder-with-helm), see

the[Helm example](#example-running-an-external-provisioner-with-helm) below.

<divclass="tabs">

We recommend creating finely-scoped keys for provisioners. Keys are scoped to an

organization.

Provisioners can broadly be categorized by scope:`organization` or`user`. The

scope of a provisioner can be specified with

[`-tag=scope=<scope>`](../reference/cli/provisionerd_start.md#t---tag) when

starting the provisioner daemon. Only users with at least the

[Template Admin](../admin/users.md#roles) role or higher may create

organization-scoped provisioner daemons.

coder provisioner keys create my-key \

--org default

-[Built-in provisioners](../reference/cli/server.md#provisioner-daemons) are

always organization-scoped.

- External provisioners started using a

[pre-shared key (PSK)](../reference/cli/provisionerd_start.md#psk) are always

organization-scoped.

<key omitted>

**Organization-scoped Provisioners** can pick up build jobs created by any user.

These provisioners always have the implicit tags`scope=organization owner=""`.

coder provisioner keys create kubernetes-key \

--org default \

--tag environment=kubernetes

coder provisionerd start --org<organization_name>

Successfully created provisioner key kubernetes-key! Save this authentication token, it will not be shown again.

<key omitted>

If you omit the`--org` argument, the provisioner will be assigned to the

default organization.

To start the provisioner:

export CODER_URL=https://<your-coder-url>

export CODER_PROVISIONER_DAEMON_KEY=<key>

coder provisionerd start

Keep reading to see instructions for running provisioners on

Kubernetes/Docker/etc.

**User-scoped Provisioners** can only pick up build jobs created from

user-tagged templates. Unlike the other provisioner types, any Coder user can

run user provisioners, but they have no impact unless there exists at least one

template with the`scope=user` provisioner tag.

A user account with the role`Template Admin` or`Owner` can start provisioners

using their user account. This may be beneficial if you are running provisioners

via[automation](./automation.md).

coder login https://<your-coder-url>

coder provisionerd start

To start a provisioner with specific tags:

coder login https://<your-coder-url>

coder provisionerd start \

--tag scope=user

--tag environment=kubernetes

coder templates push on-prem \

--provisioner-tag scope=user

Note: Any user can start[user-scoped provisioners](#User-scoped-Provisioners),

but this will also require a template on your deployment with the corresponding

tags.

A deployment-wide PSK can be used to authenticate any provisioner. We do not

recommend this approach anymore, as it makes key rotation or isolating

provisioners far more difficult. To use a global PSK, set a

[provisioner daemon pre-shared key (PSK)](../reference/cli/server.md#--provisioner-daemon-psk)

on the Coder server.

Next, start the provisioner:

coder provisionerd start --psk<your-psk>

</div>

You can use**provisioner tags** to control which provisioners can pick up build

jobs from templates (and corresponding workspaces) with matching explicit tags.

For example:

coder provisionerd start \

--provisioner-tag datacenter=chicago

Alternatively, a template can target a provisioner via

[workspace tags](https://github.com/coder/coder/tree/main/examples/workspace-tags)

inside the Terraform.

A provisioner can run a given build job if one of the below is true:

1. A job with no explicit tags can only be run on a provisioner with no explicit

If you omit the`--org` argument, the provisioner will be assigned to the

default organization.

coder provisionerd start

**User-scoped Provisioners** can only pick up build jobs created from

user-tagged templates. Unlike the other provisioner types, any Coder user can

run user provisioners, but they have no impact unless there exists at least one

template with the`scope=user` provisioner tag.

coder provisionerd start \

--tag scope=user

coder templates push on-prem \

--provisioner-tag scope=user

Coder provides a Helm chart for running external provisioner daemons, which you

1. Create a long, random pre-shared key (PSK) and store it in a Kubernetes

secret

kubectl create secret generic coder-provisioner-psk --from-literal=psk=`head /dev/urandom| base64| tr -dc A-Za-z0-9| head -c 26`