Skip to content

Add-on services conflict in multi-project workspaces due to shared Traefik ports #116

@rfay

Description

@rfay

Problem

When multiple DDEV projects run in a single freeform workspace, DDEV add-on services that use shared Traefik entrypoint ports conflict with each other. The last project to run ddev coder-routes (the post-start hook) wins, and the other projects' routing for that service is overwritten.

How DDEV port routing works

DDEV's ddev-router uses name-based (Host header) routing internally. All projects share the same Traefik entrypoint ports (e.g. port 8143 for xhgui). Routing to the correct project depends on the Host header matching the DDEV-internal hostname (e.g. p4.ddev.site).

In the Coder context, coder-routes writes Traefik rules that map Coder subdomain proxy URLs to DDEV services. For known services, it emits Host() rules with per-project slugs. For unknown add-ons, it emits PathPrefix('/') rules — but two projects sharing the same entrypoint port with the same PathPrefix('/') rule is undefined behavior (last writer wins).

Known services already fixed

The following services are handled with per-project Host() slugs and have matching coder_app resources in the template:

  • web (primary) → slug {project}
  • mailpit → slug mailpit-{project}
  • xhgui → slug xhgui-{project}
  • adminer (when enabled) → slug adminer-{project}

Still broken

Any user-installed DDEV add-on (e.g. ddev get ddev/ddev-selenium, ddev get ddev/ddev-redis-commander, custom services) that exposes a port will:

  1. Get a PathPrefix('/') Traefik rule from coder-routes
  2. Share that Traefik entrypoint port with any other project that has the same add-on
  3. Have its routing silently overwritten when another project starts

Possible approaches

  1. Extend the known-service list in coder-routes: For each popular add-on, detect the service name and emit a per-project Host() slug. Requires a corresponding coder_app in the template.

  2. Dynamic coder_app registration: Explore whether Coder supports dynamically registering apps after workspace creation (it currently does not — coder_app resources are static Terraform).

  3. Document as a limitation: Single-project workspaces are not affected. Users needing add-ons beyond the known set should use one project per workspace.

Workaround

Use one DDEV project per workspace if you need add-ons beyond xhgui, mailpit, and adminer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions