One question used to take six tabs
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 stop paying that context-switching tax. It was never meant to replace those platforms, which are good at what they do. It gives you one read-only view where you can search, trace and watch for changes without leaving the tab.
The goal was never to replace the controllers. It was to stop paying the context-switching tax.
Why it serves from a cache
What makes this work is serving from a cache. SAMURAI doesn’t 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 in MongoDB. 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 search syntax for the whole network
The sidebar presents every device type as a panel: APIC, FMC, Palo Alto, Routers, Switches, ISE, NDO, vCenter. Each panel shows the same basics (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, routes, policies and audit logs.
Panels refresh when a sync finishes
When a background sync completes, the server pushes an event over WebSocket. The frontend uses TanStack Query with cache invalidation tied to these events: when device X finishes syncing, the query cache for device X is invalidated, and any open panel refreshes on its own. Nothing polls and there’s no refresh button to click; the data shows up when it’s ready.
Sync status is also pushed over WebSocket. The sync button in the UI reflects the real-time state: idle, queued, syncing, success, or failed. This is hydrated from the server on mount (not from empty client state), so opening the dashboard mid-sync shows the correct status immediately.
One timeline for every device’s changes
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 collection (~5ms per query), not from live diffs; the engineering behind it is in our change-detection write-up. The demo page walks through it with real screenshots.