We use cookies to make your experience better.
Learn about the environments lifecycle.
Environments are designed to sustain scheduled shutdowns and rebuilds. An environment lifecycle resilient to stops and starts means you can save dollars on cloud compute and justify more powerful dev machines :).
Rebuilding an Environment allows you to update to the latest image, edit resource requests, or restart your environment 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 an Environment hasn't been accessed for the specified threshold, it is shutdown. You must rebuild a stopped environment before you can be access it again. Read more about auto-off here.
Coder exposes a few hooks during the build process. Once an Environment is available and running on an underlying host, the following steps are taken:
Injecting secrets into environment
Coder injects authentication for the
Coder CLI, allowing the latter scripts 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 the latter scripts to perform authenticated git
operations.
Execution of /coder/configure
Execution of this script allows
Images to perform startup operations consistent across
all of its Environments. If an image needs to perform modifications to the
/home
, it should do so in this script.
Execution of ~/personalize
Execution of this script allows you to customize
your personal development Environment on each rebuild. Read more on
personalization here.
Our docs are open source. See something wrong or unclear? Make an edit.