WebSocket Connectivity Changes

Glass UI receives live data from NATS over a browser WebSocket connection. Starting with this release, that connection runs through the same origin as the UI itself, at the /ws path. This article explains what changed and what to update when upgrading a 1.0.0 deployment.

What changed

In 1.0.0, the browser connected to a dedicated NATS WebSocket endpoint on a separate port. The UI fetched the endpoint URL from a generated /config/nats.json file, and the URL had to match whatever hostname your browser used to reach the UI. In practice this meant:

• a second exposed port (NodePort 31222 by default) with its own firewall rule,
• a ui.config.nats.serverUrl override for every non-ingress access method,
• a hard-to-debug failure mode where the UI loaded but showed no data whenever the configured URL did not match the browser's address bar.

Now, the nginx server inside the glass-ui pod proxies WebSocket connections: the browser connects to ws(s)://<ui-host>/ws, nginx rewrites the path and forwards the connection to the NATS ClusterIP service inside the cluster. The WebSocket URL is derived from window.location — whatever address works for the UI automatically works for the data connection.

1.0.0:    Browser ──► <host>:31222 (dedicated NodePort) ──► NATS
Current:  Browser ──► <ui-host>/ws ──► nginx (glass-ui pod) ──► NATS ClusterIP

As a consequence:

• The glass-nats-websocket NodePort/LoadBalancer service no longer exists, and the nats.websocket Helm values are rejected by the chart schema.
• The /config/nats.json file and the ui.config.nats.serverUrl value are gone; setting them has no effect.
• Only the UI port needs to be reachable from browsers.

Migrating your deployment

How do you access Glass UI?

Ingress recommended Ingress controller routes a hostname to the UI Port Forward kubectl port-forward to localhost NodePort Direct node IP access · LoadBalancer works similarly

No values changes are required: /ws is served by the same ingress host that already routes to the UI.

If you previously set ui.config.nats.serverUrl (or relied on the chart computing a wss://<host>:<port> URL from your ingress hostname), simply remove the override. TLS for the WebSocket is terminated by your ingress controller together with the rest of the UI traffic.

Remove the --set "ui.config.nats.serverUrl=ws://localhost:8222" override from your install command, and drop the second port-forward to glass-nats. A single forward now carries both the UI and the WebSocket:

kubectl port-forward svc/glass-ui 8080:80 -n controlplane

The updated port-forward overlay looks like this:

# Port Forward Overlay for Quickstart
#
# Use this with the quickstart base values when you don't have an ingress controller.
# Access Glass UI via kubectl port-forward.
#
# Usage:
#   helm install glass-ui ... \
#     -f quickstart.yaml \
#     -f quickstart-port-forward.yaml
#
# After deployment:
#   kubectl port-forward svc/glass-ui 8080:80 -n controlplane
#   Open http://localhost:8080

# Disable ingress - we'll use port-forward instead
globalIngress:
  enabled: false
  host: ""

Remove the --set "ui.config.nats.serverUrl=ws://${NODE_IP}:31222" override from your install command, and close any firewall rule for the old WebSocket NodePort (31222 by default). The browser reaches the WebSocket through the same NodePort as the UI.

The updated NodePort overlay looks like this:

# NodePort Overlay for Quickstart
#
# Use this with the quickstart base values when you don't have an ingress controller
# but want to access Glass UI via the node IP.
#
# Usage:
#   export NODE_IP=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}')
#   helm install glass-ui ... \
#     -f quickstart.yaml \
#     -f quickstart-nodeport.yaml
#
# After deployment:
#   Open http://<node-ip>:31080

# Disable ingress - we'll use NodePort instead
globalIngress:
  enabled: false
  host: ""

# Expose UI as NodePort
ui:
  service:
    type: NodePort
    nodePort: 31080

No dedicated WebSocket endpoint

There is no option to re-enable the old dedicated WebSocket NodePort. Anything that connected to NATS through that port directly must connect via /ws on the UI origin instead, or port-forward the glass-nats service for ad-hoc access.

TLS without an ingress controller

The nginx proxy also closes a gap for NodePort and LoadBalancer deployments: it can terminate TLS itself, which previously required an ingress controller.

When globalIngress.enabled: false and TLS is enabled (globalTls.enabled: true or ui.ingress.tls.enabled: true), nginx serves HTTPS on port 8443 using the certificate from globalTls.secretName and redirects plain HTTP to HTTPS. For NodePort deployments, expose the HTTPS port via ui.service.httpsNodePort. The WebSocket at /ws is covered by the same certificate — no separate TLS configuration exists for NATS WebSocket traffic anymore.

See HTTPS with and without an ingress controller for the full reference.

Troubleshooting

If the UI loads but no clusters appear, the /ws connection is failing:

1. Open the browser developer tools, Network tab, filter by WS, and reload. The request to /ws should upgrade to a WebSocket connection (HTTP 101).
2. If the upgrade fails, check the nginx upstream: the nats.proxyUpstream value (default glass-nats:8080) must match the NATS service name and WebSocket port in the Glass UI namespace.
3. Check the glass-ui pod logs for proxy errors: kubectl logs deployment/glass-ui -n controlplane.