fix(apps): build browser relay/control URLs from public origin (VAPP-41) #52

Merged

David merged 1 commit from fix/VAPP-41-split-internal-public-url into main

2026-06-29 01:25:49 +02:00

David commented

2026-06-29 01:23:47 +02:00

Owner

What

Terminal/files/desktop tabs open but never connect, with no agent-side error. Root cause: the SPA builds the browser-direct relay and control WebSocket URLs from VERVAIN_SERVER_URL, which is the internal apps-server-to-vervain-server address (http://vervain-server:8080). The browser cannot resolve the internal docker name, cannot reach :8080, and ws:// is mixed-content-blocked on the https page, so the relay socket fails at construction. vervain-server never sees the browser half; the agent dials and stashes correctly under the same id but waits forever for a peer.

This surfaced after the server port split (public browser origin is now https://api.vervain.a8n.systems:443, distinct from the internal :8080). One env var cannot serve both roles.

Changes

Split VERVAIN_SERVER_URL into two explicit vars:

VERVAIN_SERVER_INTERNAL_URL: every server-to-server hop (control connect, login/logout/setup/enroll proxies). server_base_url renamed internal_base_url.
VERVAIN_SERVER_PUBLIC_URL: the browser-reachable origin, used only by the two browser-direct builders browser_relay_url (mod.rs) and browser_control_url (control.rs). New public_base_url.

Only two of the ten call sites are browser-direct (open_relay_tunnel, get_control_token); the rest stay internal. Also: Settings shows both URLs read-only (so a misconfigured public origin is diagnosable at a glance), main.rs warns separately when each var is unset, and the deploy template + README document both. The shared control_url scheme-error is made var-agnostic since it serves both paths.

Breaking config change: deployments must set both VERVAIN_SERVER_INTERNAL_URL and VERVAIN_SERVER_PUBLIC_URL on the vervain-apps container.

Testing

just pre-commit green (fmt, clippy -D warnings, server + wasm check, bin tests). End-to-end relay pairing needs a deploy with both vars set; verify by opening a terminal tab and confirming vervain-server logs a browser-side relay stash/join for the same id.

Fixes VAPP-41. Relates to VA-77 (the agent side of the same relay path).

🤖 Generated with Claude Code

## What Terminal/files/desktop tabs open but never connect, with no agent-side error. Root cause: the SPA builds the browser-direct relay and control WebSocket URLs from `VERVAIN_SERVER_URL`, which is the internal apps-server-to-vervain-server address (`http://vervain-server:8080`). The browser cannot resolve the internal docker name, cannot reach `:8080`, and `ws://` is mixed-content-blocked on the https page, so the relay socket fails at construction. vervain-server never sees the browser half; the agent dials and stashes correctly under the same `id` but waits forever for a peer. This surfaced after the server port split (public browser origin is now `https://api.vervain.a8n.systems:443`, distinct from the internal `:8080`). One env var cannot serve both roles. ## Changes Split `VERVAIN_SERVER_URL` into two explicit vars: - `VERVAIN_SERVER_INTERNAL_URL`: every server-to-server hop (control connect, login/logout/setup/enroll proxies). `server_base_url` renamed `internal_base_url`. - `VERVAIN_SERVER_PUBLIC_URL`: the browser-reachable origin, used only by the two browser-direct builders `browser_relay_url` (`mod.rs`) and `browser_control_url` (`control.rs`). New `public_base_url`. Only two of the ten call sites are browser-direct (`open_relay_tunnel`, `get_control_token`); the rest stay internal. Also: Settings shows both URLs read-only (so a misconfigured public origin is diagnosable at a glance), `main.rs` warns separately when each var is unset, and the deploy template + README document both. The shared `control_url` scheme-error is made var-agnostic since it serves both paths. Breaking config change: deployments must set both `VERVAIN_SERVER_INTERNAL_URL` and `VERVAIN_SERVER_PUBLIC_URL` on the vervain-apps container. ## Testing `just pre-commit` green (fmt, clippy `-D warnings`, server + wasm check, bin tests). End-to-end relay pairing needs a deploy with both vars set; verify by opening a terminal tab and confirming vervain-server logs a browser-side relay stash/join for the same `id`. Fixes VAPP-41. Relates to VA-77 (the agent side of the same relay path). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

David added 1 commit

2026-06-29 01:23:47 +02:00

fix(apps): build browser relay/control URLs from public origin

Check / fmt + clippy + build + tests (pull_request) Successful in 48s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

e31a7a755b

The browser opens the relay and control WebSockets itself, but the SPA built those URLs from VERVAIN_SERVER_URL, which is the internal apps-server-to-vervain-server address (http://vervain-server:8080). The browser cannot resolve the internal docker name, cannot reach :8080, and ws:// is blocked as mixed content on the https page, so the relay socket failed at construction. vervain-server never saw the browser half, nothing stashed for it, and the agent (which dials and stashes correctly under the same id) waited forever for a peer. Terminal/files/desktop tabs opened but never connected, with no agent-side error.

Split the one overloaded knob into two explicit vars: VERVAIN_SERVER_INTERNAL_URL for every server-to-server hop (control connect, login/logout/setup/enroll proxies) and VERVAIN_SERVER_PUBLIC_URL for the two browser-direct WebSocket builders (browser_relay_url, browser_control_url). server_base_url is renamed internal_base_url; public_base_url is added. Settings now shows both URLs read-only, main.rs warns separately when each is unset, and the deploy template plus README document both. Breaking config change: deployments must set both vars.

#VAPP-41