Why offline support matters

Many networks that need monitoring the most (government, defense, financial, critical infrastructure) operate in air-gapped or tightly restricted environments. There’s no internet access, no SaaS and no cloud API, and nothing is allowed to call home to validate a license. A monitoring tool that needs the internet for anything after install simply can’t be used there.

SAMURAI was built to run offline. After install it needs no external connectivity at all: its dependencies, its database and its lookup tables all ship inside the image.

What runs inside the container

The full stack runs from a single docker run: MongoDB for data storage, the Go API server, and the web dashboard served as static files by the same binary. The entire deployment fits on a single mid-tier VM: no Kubernetes, no microservices, no distributed coordinator.

Configuration lives in a single .env file at the repository root. Key settings include MONGODB_URL (defaults to localhost:27017), APP_PORT (defaults to 5001), and SYNC_INTERVAL_SECONDS (defaults to 3600). Runtime-tunable settings (CORS origins, syslog forwarding, sync schedule, branding) live in app_settings in MongoDB and are hot-reloaded without restart.

Vendor lookups without the internet

Vendor identification for endpoint discovery relies on the IEEE OUI (Organizationally Unique Identifier) database. Most tools fetch this from the IEEE website at runtime. SAMURAI ships a 39,000-entry OUI database embedded in the binary. There’s no HTTP call and no DNS lookup; resolving a MAC prefix to a manufacturer is a local map access that takes microseconds.

Self-signed certificates and TLS

Air-gapped networks almost universally use self-signed certificates or internal CAs that are not in any public trust store. SAMURAI disables TLS verification on all connectors: APIC, FMC, NDO, Palo Alto, ISE, vCenter. This is a deliberate design choice for the target environment, not a security shortcut. In a network where every certificate is self-signed and there is no path to a public CA, strict TLS verification is not security; it is a deployment blocker.

Where every certificate is self-signed, strict TLS verification is not security. It is a deployment blocker.

Encryption at rest

Device credentials stored in MongoDB are encrypted with AES-256-GCM via the pkg/crypto package. The encryption key is a 64-character hex string set via the DEVICE_ENCRYPTION_KEY environment variable. Encrypted fields include device passwords, secrets, the default password, SMTP credentials, LDAP bind password, and the Telegram bot token. Decryption happens at the service layer: fetchers receive plaintext credentials from DeviceGetAll and DeviceGetByID; the crypto layer is never invoked inside a connector.

Nothing calls home

There’s no license server, no telemetry, no update check and no analytics beacon. JWT authentication runs locally with 30-minute access tokens and 7-day refresh tokens, validated against a secret in the .env file. Permissions are resolved per-request from the roles collection, not embedded in the JWT, not fetched from an external identity provider.

The monitoring dashboard, the sync engine, the change detection pipeline, the endpoint aggregation, the traffic simulation: everything runs on that one VM behind your firewall. The only network traffic SAMURAI generates is to the devices it monitors, on ports you explicitly configure.