We use cookies to make your experience better.
Learn about the workspace lifecycle.
Workspaces are designed to sustain scheduled shutdowns and rebuilds. An workspace lifecycle resilient to stops and starts means you can save dollars on cloud compute and justify more powerful dev machines :).
Rebuilding a workspace allows you to update to the latest image, edit resource requests, or restart your workspace after a shutdown.
Only the /home/<username>
directory persists between rebuilds. Rebuilds do not
affect configurations and source code within the /home/<username>
subtree,
even if the underlying image or its dependencies change.
Note: username
is defined in the image. See
Docker's image documentation
Organizations can set an auto-off inactivity threshold. After a workspace hasn't been accessed for the specified threshold, it is shut down. A stopped workspace requires a rebuild before you can access it again.
Coder exposes a few hooks during the build process. Once a workspace is available and running on an underlying host, the following steps are taken:
Injection of secrets into the workspace: Coder injects authentication for
the Coder CLI, allowing the CLI to
perform authenticated CLI commands. If your Coder instance is configured with
a Git provider, your SSH key pair is injected during this step as well,
allowing it to perform authenticated git
operations.
Execution of /coder/configure
: Execution of this script allows
images to perform startup operations consistent across
all of the workspaces that use the image. If you need your image to include
modifications to /home
, include the instructions in this script.
Execution of ~/personalize`: Execution of this script allows you to customize your personal development workspace on each rebuild. Read more on personalization here.
See an opportunity to improve our docs? Make an edit.