Skip to content

fix(dashboard): resolve API origin correctly in docker-compose#7

Merged
Hydralerne merged 1 commit into
oblien:mainfrom
shiv19:fix/dashboard-docker-api-origin
Jul 18, 2026
Merged

fix(dashboard): resolve API origin correctly in docker-compose#7
Hydralerne merged 1 commit into
oblien:mainfrom
shiv19:fix/dashboard-docker-api-origin

Conversation

@shiv19

@shiv19 shiv19 commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Dashboard SSR fetches (e.g. GET /health/env) always resolved the API origin from a static runtime-target table, which defaults to http://localhost:4000. Inside the dashboard container that never reaches the api container, so every docker compose up fails with Cannot resolve deployment info: GET /health/env is unreachable ... ECONNREFUSED.
  • INTERNAL_API_URL already existed as an override in apps/dashboard/src/lib/server/api.ts, but was only honored when NEXT_PUBLIC_API_PROXY=true — a NEXT_PUBLIC_* build-time flag the dashboard Dockerfile never sets, so the override was effectively dead code in this deployment path.
  • Loosened getServerApiBaseUrl to honor INTERNAL_API_URL unconditionally for server-side requests (browser-side resolution is untouched), and set it in docker-compose.yml to the in-cluster DNS name (http://api:4000) for the dashboard service — matching the same pattern already used for api's own DATABASE_URL/REDIS_URL overrides.

Test plan

  • docker compose up -d --build dashboard — dashboard boots clean, no ECONNREFUSED / health/env error in logs
  • curl http://localhost:3001 returns a normal redirect instead of the fatal error page
  • Maintainers verify no regression for non-docker (bare-metal/desktop) OPENSHIP_LOCAL_API_URL and proxy-mode (NEXT_PUBLIC_API_PROXY=true) paths, which are unaffected in code review but worth a sanity check

Dashboard SSR fetches (e.g. GET /health/env) resolved the API origin
from a static runtime-target table defaulting to http://localhost:4000.
Inside the dashboard container that never reaches the api container,
causing "Cannot resolve deployment info ... ECONNREFUSED" on every
docker compose up.

INTERNAL_API_URL already existed as an override but was gated behind
NEXT_PUBLIC_API_PROXY=true, a NEXT_PUBLIC_* build-time flag the
Dockerfile never sets. Loosen getServerApiBaseUrl to honor
INTERNAL_API_URL unconditionally for server-side requests, and set it
in docker-compose.yml to the in-cluster DNS name (http://api:4000),
matching the pattern already used for api's own DATABASE_URL/REDIS_URL
overrides.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@shiv19

shiv19 commented Jul 18, 2026

Copy link
Copy Markdown
Contributor Author

The dashboard wasn't really loading for me after docker compose up without this fix.

@Hydralerne

Copy link
Copy Markdown
Member

Reviewed it - fix looks right, http://api:4000 matches the compose service and the SSR-direct routing makes sense. Two things first:

  1. The JSDoc on getServerApiBaseUrl() still says the INTERNAL_API_URL short-circuit only kicks in when NEXT_PUBLIC_API_PROXY=true — not true anymore after this, so update it.
  2. This makes INTERNAL_API_URL work regardless of the proxy flag. Can you check the SaaS build doesn't set it somewhere that relies on per-request origin? Would bypass it for SSR. Self-host path is fine.

@Hydralerne
Hydralerne merged commit a118655 into oblien:main Jul 18, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants