Hi, The initial purpose of the Console is to target a single Polaris server rather than multiple ones.
I don't see a problem with the SPA architecture; this was discussed extensively with the initial contributors of the console. I agree that the README and deployment documentation should be clarified to avoid this confusion. I will take care of updating those. Regards, JB On Tue, Jun 2, 2026 at 6:09 AM Yong Zheng <[email protected]> wrote: > Hi everyone, > > While poking around polaris console during the weekend, I have both the > Polaris server and Polaris console deployed in the same k8s namespace (in > this case, polaris). The console nginx serves the SPA to the browser, and > VITE_POLARIS_API_URL is set to http://polaris:8181 (the in-cluster > service DNS name). > > When accessing via kubectl port-forward svc/polaris-console 8080:80: > > 1. Browser loads the SPA from localhost:8080 (port-forward to console pod) > 2. JS executes in the browser and calls VITE_POLARIS_API_URL (defaults to > http://polaris:8181) > 3. Browser resolves polaris using the client machine's DNS, not in-cluster > DNS (fails with net::ERR_NAME_NOT_RESOLVED when debugging from browser as I > am not seeing any logs on the console and no incoming requests to the > polaris pod) > 4. The error surfaces as "Network Error" in the UI with no server-side logs > > The port-forward tunnel only covers traffic to its own port (8080). The > API requests are independent HTTP calls from the browser that bypass the > tunnel entirely. The console nginx is just a static file server and never > sees these requests, thus no logs from the console pod. > > Not sure if this is just me, but this UX feels odd. Wondering if the > community thinks a pure SPA is the right call here, or if there's a better > approach. > > Thanks, > Yong Zheng >
