Templates are written in standard Terraform and describe the infrastructure for

workspaces (e.g., aws_instance, kubernetes_pod, or both).

In most cases, a small group of users (Coder admins) manage templates. Then,

other users provision their development workspaces from templates.

Example templates are not designed to support every use (e.g [examples/aws-linux](https://github.com/coder/coder/tree/main/examples/templates/aws-linux) does

not support custom VPCs). You can add these features by editing the Terraform

code once you run `coder templates init` (new) or `coder templates pull`

(existing).

- Terraform: [Documentation](https://developer.hashicorp.com/terraform/docs) and [Registry](https://registry.terraform.io)

- Common [concepts in templates](#concepts-in-templates) and [Coder Terraform provider](https://registry.terraform.io/providers/coder/coder/latest/docs)

- [Coder example templates](https://github.com/coder/coder/tree/main/examples/templates) code

While templates are written with standard Terraform, the

[Coder Terraform Provider](https://registry.terraform.io/providers/coder/coder/latest/docs) is

template options, reference [Coder Terraform provider docs](https://registry.terraform.io/providers/coder/coder/latest/docs).

Resources in Coder are simply [Terraform resources](https://www.terraform.io/language/resources).

If a Coder agent is attached to a resource, users can connect directly to the resource over

SSH or web apps.

The `coder_agent` resource can be configured as described in the

[documentation for the `coder` Terraform provider.](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)

For example, you can use the `env` property to set environment variables that will be

inherited by all child processes of the agent, including SSH sessions.

installing IDEs, [cloning dotfiles](./dotfiles.md#templates), and cloning project repos.

- **Admin/template-wide parameters** are set when a template is created/updated. These values

are often cloud configuration, such as a `VPC`, and are annotated

values are often personalization settings such as "preferred region"

or "workspace image".

The template sample below uses _admin and user parameters_ to allow developers to

create workspaces from any image as long as it is in the proper registry:

Coder workspaces can be started/stopped. This is often used to save on cloud costs or enforce

ephemeral workflows. When a workspace is started or stopped, the Coder server

runs an additional

[terraform apply](https://www.terraform.io/cli/commands/apply), informing the

Coder provider that the workspace has a new transition state.

This template sample has one persistent resource (docker volume) and one ephemeral resource

(docker image).

You can edit a template using the coder CLI. Only

[template admins and owners](./admin/users.md) can edit a template.

Using the CLI, login to Coder and run the following command to edit a single template:

Alternatively, you can pull down the template as a tape archive (`.tar`) to your current directory:

Make the changes to your template then run this command from the root of the template folder:

Your updated template will now be available. Outdated workspaces will have a prompt in the dashboard to update.

You can delete a template using both the coder CLI and UI. Only

[template admins and owners](./admin/users.md) can delete a template, and the template

must not have any running workspaces associated to it.

Using the CLI, login to Coder and run the following command to delete a template:

In the UI, navigate to the template you want to delete, and select the dropdown in

the right-hand corner of the page to delete the template.

When a workspace is deleted, the Coder server essentially runs a

[terraform destroy](https://www.terraform.io/cli/commands/destroy) to remove all

resources associated with the workspace.

terminal. See [Configuring Web IDEs](./ides/web-ides.md) to

learn how to give users access to additional web applications.

When a workspace is being started or stopped, the `coder_workspace` data source provides

some useful parameters. See the [documentation for the `coder` Terraform provider](https://registry.terraform.io/providers/coder/coder/latest/docs/data-sources/workspace)

For example, the [Docker quick-start template](https://github.com/coder/coder/tree/main/examples/templates/docker)

sets a few environment variables based on the username and email address of the workspace's owner, so

that you can make Git commits immediately without any manual configuration:

You can add these environment variable definitions to your own templates, or customize them however

you like.

Occasionally, you may run into scenarios where a workspace is created, but the agent is not connected. This means the agent or [init script](https://github.com/coder/coder/tree/main/provisionersdk/scripts) has failed on the resource.

- Ensure the resource can `curl` your Coder [access URL](./admin/configure.md#access-url)

- Manually connect to the resource and check the agent logs (e.g., `docker exec` or AWS console)

- The Coder agent startup script logs are typically stored in `/var/log/coder-startup-script.log`

Template permissions can be used to give users and groups access to specific templates. [Learn more about RBAC](./admin/rbac.md).

You can see a list of community templates by our users [here](https://github.com/coder/coder/blob/main/examples/templates/community-templates.md).