Creation of a workspace with the same name discovers previous content.

[rfay]

Our deployment of Coder at coder.ddev.com currently stores workspace home directories on the host at:

/home/coder/workspaces/${owner}-${workspace}

Deleting a workspace does not delete its corresponding directory, which can cause confusing behavior if a workspace is recreated with the same name.

Why deleted workspaces leave data behind

The template currently uses a host bind mount rather than a Docker-managed volume.

Deleting a Coder workspace removes the container and Terraform-managed resources, but does not remove arbitrary directories on the host filesystem. As a result:

/home/coder/workspaces/${owner}-${workspace}

remains on disk after workspace deletion.

The template even notes that destroy-time cleanup was intentionally disabled.

Because the directory name is derived from owner + workspace name, recreating a workspace with the same name will mount the same directory again. This makes it appear as if the old workspace state has “come back from the dead”.

Why this is fragile

The storage path is currently derived from mutable identifiers:

${data.coder_workspace_owner.me.name}-${data.coder_workspace.me.name}

Workspace names are not immutable, so:

• deleting and recreating a workspace with the same name reuses old storage
• renaming workspaces would also create confusing persistence behavior

Coder’s own Docker template examples recommend using an immutable identifier for persistent resources:

coder-${data.coder_workspace.me.id}-home

Using the workspace ID avoids all of the name reuse issues.

Recommended improvements

1. Use workspace IDs for persistent storage paths

Instead of naming directories using workspace names:

/home/coder/workspaces/${owner}-${workspace}

use the immutable workspace ID:

/home/coder/workspaces/${data.coder_workspace.me.id}

This prevents accidental reuse when workspaces are recreated with the same name.

Metadata or labels can still include the human-readable workspace name.

2. Consider Docker-managed volumes

Coder’s official examples persist /home/coder using Docker volumes instead of host directories.

Example pattern:

coder-${data.coder_workspace.me.id}-home

Advantages:

• lifecycle managed by Docker
• avoids host path collisions
• easier cleanup
• clearer persistence semantics

3. Add cleanup tooling for orphaned directories

Since bind mounts leave directories behind, an admin tool should detect directories that no longer correspond to active workspaces.

Example approach:

1. list workspaces via Coder API or CLI
2. compare to directories on disk
3. flag or delete orphaned paths

Recommended path forward

Minimal disruption approach:

1. Move /home/coder/workspaces onto a larger filesystem
2. Update template to use workspace IDs for new workspaces
3. Leave existing workspaces unchanged initially
4. Add tooling to identify and clean orphaned directories

This resolves:

• root filesystem exhaustion
• confusing workspace resurrection
• fragile name-based persistence

If desired, I can also add:

• a migration script to convert existing directories
• the exact Terraform template change
• a cleanup script to find orphaned workspace directories
  """
  path = "/mnt/data/coder-workspace-storage-issue.md"
  with open(path, "w", encoding="utf-8") as f:
  f.write(content)
  print(path)