# From six browser tabs to one dashboard

> The operational pain that started SAMURAI, and the design decisions that let a single read-only surface replace APIC, Panorama, FMC, ISE, and a stack of SSH terminals.

**Product** · 2026-03-25 · 4 min read · By Beyrak A., Founder & Security/System Engineer at SAMURAI

**Key takeaways**

- The context-switching tax is real: six logins, six search syntaxes, six ideas of what an endpoint is.
- Cache-first serving is why one tab can front nine device types: milliseconds from the cache, live queries only when asked.
- One search language across every panel beats memorizing each vendor filter syntax.

## The six-tab workflow

Before SAMURAI, answering a simple question like "which switch port is 10.1.50.23 on, and has its ACL changed recently?" required opening six browser tabs: APIC for the fabric view, FMC for firewall policies, Panorama for Palo Alto rules, an SSH terminal for the switch, ISE for authentication state, and maybe NDO if the endpoint spans sites. Each tool has its own login, its own session timeout, its own search syntax, and its own idea of what an "endpoint" looks like.

SAMURAI started as a personal tool to eliminate this context-switching tax. The goal was not to replace any of these platforms (they are good at what they do) but to provide [a single read-only pane of glass](https://nometa.az/en/platform/) where you can query, trace, and monitor without leaving one browser tab.

> The goal was never to replace the controllers. It was to stop paying the context-switching tax.

## Cache-first architecture

The key design decision that makes this work is cache-first data serving. SAMURAI does not proxy requests to upstream devices in real time. Instead, background sync workers fetch data from every device on a configurable interval (default: 3600 seconds) and store the results. The API serves from the cache. This means the UI loads in milliseconds, not seconds, regardless of how many devices you have or how slow their APIs are.

When you need live data, the `?live=true` query parameter bypasses the cache and fetches directly from the device. For historical comparison, `?snapshot=2026-05-20T14:30:00Z` queries a specific point in time. But 95% of daily operations (searching endpoints, reviewing policies, checking routes) are served from cache with sub-400ms latency.

## One sidebar, one search

The sidebar presents every device type as a panel: APIC, FMC, Palo Alto, FortiGate, Routers, Switches, ISE, NDO, vCenter. Each panel shows the same primitives (devices, their collected data, and a changes tab) with device-specific views where needed (tenant hierarchy for APIC, security policies for Palo Alto, TrustSec matrix for ISE).

The search bar is global. Advanced search syntax supports field-scoped queries (`vendor:cisco`), CIDR matching (`ip:10.0.0.0/8`), boolean operators (AND/OR/NOT), quoted phrases, and negation. The same syntax works across every panel: [endpoints](https://nometa.az/en/blog/endpoint-correlation-without-cmdb/), routes, policies, audit logs. One search language for the entire network.

## Push-based live updates

When a background sync completes, the server pushes an event to the frontend, which invalidates exactly the queries for the device that finished syncing; any open panel refreshes automatically. No polling. No manual refresh button. The data appears when it is ready.

Sync status is pushed the same way. The sync button in the UI reflects the real-time state: idle, queued, syncing, success, or failed, hydrated from the server on mount, so opening the dashboard mid-sync shows the correct status immediately.

## Changes timeline

The changes page aggregates diffs from every device type into a single timeline. Instead of checking six dashboards for "what changed overnight," you open one page, filter by time range or device type, and see every meaningful change with admin attribution where available. The timeline reads from a pre-computed change log (about 5 ms per query), not from live diffs; the engineering behind it is in [our change-detection write-up](https://nometa.az/en/blog/change-detection-without-audit-logs/). [The demo page walks through it with real screenshots](https://nometa.az/en/demo/).

---

Canonical page: https://nometa.az/en/blog/six-tabs-to-one-dashboard/
Part of SAMURAI, a self-hosted, multi-vendor network monitoring & security platform. Overview: https://nometa.az/llms.txt
Contact: info@nometa.az · Docker Hub: https://hub.docker.com/r/beyrak44/samurai