Why two Grafana instances
A Viewer role alone does not constrain what a datasource credential can read. A separate public process, filesystem identity and restricted gateway make the public credential boundary explicit. The public process has no unrestricted Cloud token and cannot read the owner configuration. Loopback binding also prevents bypassing portal routing from the network.
Public projection tradeoffs
A native panel may depend on labels, transformations, variables, proprietary plugins or sensitive text. Publishing it verbatim would defeat sanitization. The public projection preserves supported metric visualization and layout while replacing private series labels and explaining unsupported content. Fixed query scope avoids treating arbitrary regular expressions as trusted dashboard parameters.
Failure and ownership
Both Grafana processes have independent resource limits. Alert evaluation remains in Cloud to avoid duplicate notifications and independent state machines. Qwen and Ollama services are not restarted by portal deployment. The existing before-and-after inference checks remain release gates. A local portal outage does not remove Cloud telemetry or the independently hosted wiki.
Visual hierarchy and uncertainty
The first screen answers whether current probes are passing and whether host resources need attention. Resource health cannot prove every application is healthy, and a passing endpoint cannot resolve a historical issue; the UI keeps live core checks and daily findings distinct. Neutral unverified states avoid claiming an offline telemetry source is either a confirmed outage or a healthy host. Text accompanies status colors, utilization bars supplement numeric values, and the native Apple system font falls back to platform sans-serif without downloading proprietary fonts. Responsive lists, keyboard focus states, and reduced-motion support preserve the same investigation paths on mobile.