Problem
The Drupal workspace templates currently expose two Coder app buttons for the same underlying DDEV web service:
Both apps proxy to the same internal DDEV web port:
drupal-core: http://localhost:80drupal-contrib: http://localhost:8080
Because both apps set subdomain = true, Coder gives each app its own generated hostname:
ddev-web--...drupal-site--...
This makes the UI look like there are two distinct site entry points, auth contexts, environments, or service states. In practice, both hostnames route to the same DDEV web service. The different app names/subdomains caused user confusion, and the Slack discussion concluded that the duplicate Drupal Site button does not provide enough value.
Findings
Git history shows that the duplicate app was intentional, but its purpose was health/status signaling rather than routing.
PR #41 added Drupal Site as a second coder_app with the same backend URL as DDEV Web, but with a stricter healthcheck:
DDEV Web checks general webserver health at /, indicating DDEV/nginx is responding.Drupal Site checks application heath at /user/login, indicating Drupal has installed far enough to return a non-5xx response.
That intent is reasonable, but exposing it as a second app creates a misleading UX. Users see two launchers and two subdomains for one underlying service.
PR #122 later copied the pattern into drupal-contrib, and CI now also assumes the drupal-site--... hostname as the canonical external site URL.
Coder app health display
Coder already has native health-state presentation for app buttons.
For a coder_app with a healthcheck, Coder treats the app as healthy when the healthcheck URL returns an HTTP status below 500. The original Drupal Site implementation relied on this behavior: the app icon is dimmed/unhealthy while Drupal is not ready, then appears normal/bright once /user/login returns a non-5xx response.
This means the readiness signal does not require a second launcher, a second subdomain, or modified icon artwork. The single DDEV Web app can carry the Drupal readiness check, and Coder can continue to represent readiness through its native unhealthy/healthy visual treatment.
Proposed resolution
Remove the duplicate Drupal Site app and standardize on a single DDEV Web launcher.
Move the Drupal readiness healthcheck from Drupal Site onto the existing DDEV Web app for Drupal-specific templates:
- in
drupal-core, check http://localhost:80/user/login
- in
drupal-contrib, check http://localhost:8080/user/login
Keep the DDEV logo unchanged as the app icon. Do not recolor, overlay, badge, dim manually, or otherwise modify the DDEV mark. Let Coder’s native app health UI communicate readiness.
Add a tooltip to clarify the healthcheck semantics, for example:
tooltip = "Opens the DDEV web service. Health indicates Drupal is installed and /user/login is returning a non-5xx response."
This preserves the useful readiness signal while avoiding a second launcher/subdomain.
Why not dynamically use the site favicon?
I considered whether DDEV Web could dynamically use the served site’s favicon, falling back to the DDEV logo.
That does not appear to fit Coder’s app model well. coder_app.icon is a static URL in the Terraform resource, while the served favicon is only knowable after the workspace starts and the site responds. Trying to mutate the app icon at runtime would be fragile and would fight the Terraform/Coder app model.
Keeping the canonical DDEV logo is simpler, more reliable, and avoids any possible DDEV brand-mark concerns. Readiness should be conveyed through Coder’s native app health state and tooltip text instead.
Scope
Update:
drupal-core/template.tfdrupal-contrib/template.tf- CI checks that currently reference
drupal-site--...
- generated welcome text or
ddev describe/post-start output that references drupal-site--...
- docs or screenshots that show both buttons
Do not change unrelated apps such as VS Code or Mailpit.
Do not apply this stricter /user/login healthcheck to generic/freeform templates, where DDEV Web should continue to mean “the DDEV web service is responding.”
Acceptance criteria
- Drupal workspaces expose only one primary site launcher:
DDEV Web.
- Users no longer see both
ddev-web--... and drupal-site--... for the same service.
- The
DDEV Web app still uses the canonical DDEV logo.
- Drupal readiness is still reflected by the app health state.
- The unhealthy state is represented by Coder’s native app UI, not by modified DDEV icon artwork.
- CI and generated output use
ddev-web--... as the canonical site hostname.
- Existing VS Code, Mailpit, and non-Drupal/freeform behavior is unchanged.
Reference notes
Credit: Assisted by GPT-5.5 Thinking for repo-history review and issue framing.
Problem
The Drupal workspace templates currently expose two Coder app buttons for the same underlying DDEV web service:
DDEV WebDrupal SiteBoth apps proxy to the same internal DDEV web port:
drupal-core:http://localhost:80drupal-contrib:http://localhost:8080Because both apps set
subdomain = true, Coder gives each app its own generated hostname:ddev-web--...drupal-site--...This makes the UI look like there are two distinct site entry points, auth contexts, environments, or service states. In practice, both hostnames route to the same DDEV web service. The different app names/subdomains caused user confusion, and the Slack discussion concluded that the duplicate
Drupal Sitebutton does not provide enough value.Findings
Git history shows that the duplicate app was intentional, but its purpose was health/status signaling rather than routing.
PR #41 added
Drupal Siteas a secondcoder_appwith the same backend URL asDDEV Web, but with a stricter healthcheck:DDEV Webchecks general webserver health at/, indicating DDEV/nginx is responding.Drupal Sitechecks application heath at/user/login, indicating Drupal has installed far enough to return a non-5xx response.That intent is reasonable, but exposing it as a second app creates a misleading UX. Users see two launchers and two subdomains for one underlying service.
PR #122 later copied the pattern into
drupal-contrib, and CI now also assumes thedrupal-site--...hostname as the canonical external site URL.Coder app health display
Coder already has native health-state presentation for app buttons.
For a
coder_appwith ahealthcheck, Coder treats the app as healthy when the healthcheck URL returns an HTTP status below500. The originalDrupal Siteimplementation relied on this behavior: the app icon is dimmed/unhealthy while Drupal is not ready, then appears normal/bright once/user/loginreturns a non-5xx response.This means the readiness signal does not require a second launcher, a second subdomain, or modified icon artwork. The single
DDEV Webapp can carry the Drupal readiness check, and Coder can continue to represent readiness through its native unhealthy/healthy visual treatment.Proposed resolution
Remove the duplicate
Drupal Siteapp and standardize on a singleDDEV Weblauncher.Move the Drupal readiness healthcheck from
Drupal Siteonto the existingDDEV Webapp for Drupal-specific templates:drupal-core, checkhttp://localhost:80/user/logindrupal-contrib, checkhttp://localhost:8080/user/loginKeep the DDEV logo unchanged as the app icon. Do not recolor, overlay, badge, dim manually, or otherwise modify the DDEV mark. Let Coder’s native app health UI communicate readiness.
Add a tooltip to clarify the healthcheck semantics, for example:
This preserves the useful readiness signal while avoiding a second launcher/subdomain.
Why not dynamically use the site favicon?
I considered whether
DDEV Webcould dynamically use the served site’s favicon, falling back to the DDEV logo.That does not appear to fit Coder’s app model well.
coder_app.iconis a static URL in the Terraform resource, while the served favicon is only knowable after the workspace starts and the site responds. Trying to mutate the app icon at runtime would be fragile and would fight the Terraform/Coder app model.Keeping the canonical DDEV logo is simpler, more reliable, and avoids any possible DDEV brand-mark concerns. Readiness should be conveyed through Coder’s native app health state and tooltip text instead.
Scope
Update:
drupal-core/template.tfdrupal-contrib/template.tfdrupal-site--...ddev describe/post-start output that referencesdrupal-site--...Do not change unrelated apps such as VS Code or Mailpit.
Do not apply this stricter
/user/loginhealthcheck to generic/freeform templates, whereDDEV Webshould continue to mean “the DDEV web service is responding.”Acceptance criteria
DDEV Web.ddev-web--...anddrupal-site--...for the same service.DDEV Webapp still uses the canonical DDEV logo.ddev-web--...as the canonical site hostname.Reference notes
drupal-coreduplicate app definitions and healthcheck split:drupal-core/template.tfdrupal-contribduplicate app definitions:drupal-contrib/template.tffeat: add Drupal Site app with second healthcheck indicatorfeat: add drupal-contrib template with beta unified issue picker<500is treated as healthyddev/ddevdocs/content/developers/logos/SVG/Logo.svgCredit: Assisted by GPT-5.5 Thinking for repo-history review and issue framing.