Workspaces
A workspace is the environment that a developer works in. Developers in a team each work from their own workspace and can use multiple IDEs.
A developer creates a workspace from a shared template. This lets an entire team work in environments that are identically configured and provisioned with the same resources.
Creating workspaces
You can create a workspace in the UI. Log in to your Coder instance, go to the Templates tab, find the template you need, and select Create Workspace.
When you create a workspace, you will be prompted to give it a name. You might also be prompted to set some parameters that the template provides.
You can manage your existing templates in the Workspaces tab.
You can also create a workspace from the command line:
Each Coder user has their own workspaces created from shared templates:
# create a workspace from the template; specify any variables
coder create --template="<templateName>" <workspaceName>
# show the resources behind the workspace and how to connect
coder show <workspace-name>
Workspace filtering
In the Coder UI, you can filter your workspaces using pre-defined filters or Coder's filter query. For example, you can find the workspaces that you own or that are currently running.
The following filters are supported:
owner
- Represents theusername
of the owner. You can also useme
as a convenient alias for the logged-in user.template
- Specifies the name of the template.status
- Indicates the status of the workspace. For a list of supported statuses, see WorkspaceStatus documentation.
Starting and stopping workspaces
By default, you manually start and stop workspaces as you need. You can also schedule a workspace to start and stop automatically.
To set a workspace's schedule, go to the workspace, then Settings > Schedule.
Coder might also stop a workspace automatically if there is a template update available.
Autostart and autostop
Use autostart to start a workspace at a specified time and which days of the week. Also, you can choose your preferred timezone.
Use autostop to stop a workspace after a number of hours. Autostop won't stop a workspace if you're still using it. It waits for another hour before checking again. Coder checks for active connections in the IDE, SSH, Port Forwarding, and coder_app.
Max lifetime Enterprise
Max lifetime is a template setting that determines the number of hours a workspace will run before Coder automatically stops it, regardless of any active connections. Use this setting to ensure that workspaces do not run in perpetuity when connections are left open inadvertently.
Automatic updates
Automatic updates is part of an experimental feature and the behavior is subject to change. Use GitHub issues to leave feedback. This experiment must be specifically enabled with the
--experiments="template_update_policies"
option on your coderd deployment.
It can be tedious to manually update a workspace everytime an update is pushed to a template. Users can choose to opt-in to automatic updates to update to the active template version whenever the workspace is started.
Note: If a template is updated such that new parameter inputs are required from the user, autostart will be disabled for the workspace until the user has manually updated the workspace.
Updating workspaces
After updating the default version of the template that a workspace was created from, you can update the workspace.
If the workspace is running, Coder stops it, updates it, then starts the workspace again.
On the command line:
coder update <workspace-name>
Workspace resources
Workspaces in Coder are started and stopped, often based on whether there was any activity or if there was a template update available.
Resources are often destroyed and re-created when a workspace is restarted, though the exact behavior depends on the template. For more information, see Resource Persistence.
⚠️ To avoid data loss, refer to your template documentation for information on where to store files, install software, etc., so that they persist. Default templates are documented in ../examples/templates.
You can use
coder show <workspace-name>
to see which resources are persistent and which are ephemeral.
Typically, when a workspace is deleted, all of the workspace's resources are
deleted along with it. Rarely, one may wish to delete a workspace without
deleting its resources, e.g. a workspace in a broken state. Users with the
Template Admin role have the option to do so both in the UI, and also in the CLI
by running the delete
command with the --orphan
flag. This option should be
considered cautiously as orphaning may lead to unaccounted cloud resources.
Repairing workspaces
Use the following command to re-enter template input variables in an existing workspace. This command is useful when a workspace fails to build because its state is out of sync with the template.
coder update <your workspace name> --always-prompt
First, try re-entering parameters from a workspace. In the Coder UI, you can filter your workspaces using pre-defined filters or employing the Coder's filter query. Take a look at the following examples to understand how to use the Coder's filter query:
- To find the workspaces that you own, use the filter
owner:me
. - To find workspaces that are currently running, use the filter
status:running
.
You can also do this in the CLI with the following command:
coder update <your workspace name> --always-prompt
If that does not work, a Coder admin can manually push and pull the Terraform state for a given workspace. This can lead to state corruption or deleted resources if you do not know what you are doing.
coder state pull <username>/<workspace name>
# Make changes
coder state push <username>/<workspace name>
Logging
Coder stores macOS and Linux logs at the following locations:
Service | Location |
---|---|
startup_script | /tmp/coder-startup-script.log |
shutdown_script | /tmp/coder-shutdown-script.log |
Agent | /tmp/coder-agent.log |
Note: Logs are truncated once they reach 5MB in size.