demo: make remote/headless client-server setup work out of the box#188
Open
gioelecerati wants to merge 3 commits into
Open
demo: make remote/headless client-server setup work out of the box#188gioelecerati wants to merge 3 commits into
gioelecerati wants to merge 3 commits into
Conversation
Running the realtime demo with the UI and GPU server on different machines was a footgun. Three fixes: - run.py forced NEXT_PUBLIC_POD_BASE_URL to the local backend address (and maps 0.0.0.0 -> 127.0.0.1), so the obvious knob (.env.local) was silently overridden and the browser's WebSocket pointed at 127.0.0.1 (= the client, not the server). Add --client-host for the browser-facing address, respect an explicitly pre-set NEXT_PUBLIC_POD_BASE_URL, bind the dev server to all interfaces when remote, print the resolved base URL, and warn when it still points at localhost. The "Open ..." banner now shows the right host. - web/.env.local.example shipped :8765 (wrong port); the demo backend is :1318, so copying it produced /api/* 404s. Fixed + documented the remote case in the comment. - README: add a "Remote / headless server" section (bind 0.0.0.0, set --client-host, open both ports, restart after config changes). Symptom this fixes: /api/fixtures and /api/loras 404 from the dev server even though the engine serves them fine over curl — the Next.js rewrites were proxying to an unreachable/wrong base URL.
The UI's HTTP fetches (/api/*, /fixtures/*, /loras/*) went through next.config.ts rewrites, but the dev bundler doesn't reliably proxy them — so /api/* 404s even when the engine serves them fine and the base URL is reachable. The backend already sends Access-Control-Allow-Origin: *, so point the engine URL builder straight at NEXT_PUBLIC_POD_BASE_URL (the same host the WebSocket uses) and skip the rewrite entirely. Falls back to the old same-origin relative path when the base URL is unset. This is the piece that actually unblocks the remote client/server setup; the run.py/--client-host/.env changes just make sure the base URL is set.
Putting --client-host (or --web-port/--no-install) after `--` forwards them to the backend instead of the launcher, so they silently no-op and the browser base URL falls back to 127.0.0.1 — a remote client then hits its own loopback. Detect misplaced launcher flags and warn with the correct order. Also clarify the README remote example (flags before `--`, backend args after) and that the printed base URL must be the server's address.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Running the realtime demo with the UI on one machine and the GPU server on another doesn't work out of the box, and the failure is opaque: the dev server returns 404 on
/api/fixtures//api/loraseven though the engine serves them fine (curl http://<server>:1318/api/fixturesworks). That's the Next.js rewrites proxying to a wrong/unreachable base URL — not an engine bug. (repro from a user trying exactly this — headless GPU box + separate client.)Two root causes:
run.pyforcesNEXT_PUBLIC_POD_BASE_URLto the local backend (and maps--host 0.0.0.0→127.0.0.1). That env var is read at startup bynext.config.tsfor the rewrites and used client-side by the browser for the WebSocket. So the obvious knob (.env.local) is silently overridden, and the browser's WS points at127.0.0.1(= the client, not the server).web/.env.local.exampleshipped:8765— the demo backend is:1318, so anyone who copies it gets/api/*404s.Changes
run.py: add--client-hostfor the browser-facing address; respect an explicitly pre-setNEXT_PUBLIC_POD_BASE_URL; bind the dev server to all interfaces when remote (-H 0.0.0.0); print the resolved base URL and warn when it still points at localhost; fix the "Open …" banner to show the right host.web/.env.local.example: correct the port to:1318and document the remote case in the comment.README.md: add a short "Remote / headless server" section (bind0.0.0.0, set--client-host, open both ports, restart after config changes).Usage after this
Same-machine usage is unchanged.
🤖 Generated with Claude Code