This article describes considerations for deciding how to set up your Coder workspaces.
In general, the fewer workspaces per developer, the easier it is for the individual developer to manage. However, the complexity of the underlying images increases as the images need to support multiple projects, each potentially with its own language, set of tooling, and dependencies.
Nevertheless, for teams that do not have a complex development workflow, we recommend starting with one workspace per developer, since it is the fastest, most straightforward model to adopt.
With one workspace per developer, you can think of the Coder workspace the way you would a laptop: the workspace is where you have all of your languages, dependencies, and tooling installed, and it is the one place you'd go to work on your projects.
Each developer has multiple workspaces, with each workspace devoted to one project. If a developer is currently working on three projects, they'd have three workspaces.
A subset of this category is one workspace per major version of a project (e.g., making major, breaking changes to something). Furthermore, Coder allows you to change the underlying image, so you can update the image (changing out the language and any dependencies) if needed.
The benefits and potential caveats of this option are similar to those involved with setting up one workspace per project per developer.
Setting up one workspace per feature (or branch) allows your developers to focus only on that feature.
With dev URLs, allowing access to the work in progress, the workspace could also replace the need for any preview builds, while also providing access to some of the logs. Reviewers or other developers could push changes to the branch/pull request from their own workspaces without needing access to the primary developers' workspaces.
We do not recommend creating workspaces on a per-commit basis due to the high cost of resources in these situations.