Having extensively evaluated various zero-trust and secure access solutions in the context of deploying AI workloads and sensitive RAG pipelines, I find that vendor documentation often glosses over the concrete resource footprint of their endpoint connectors. This makes capacity planning for large-scale deployments, such as fleets of inference servers or data processing nodes, needlessly opaque.
For Banyan Security, I am seeking to aggregate and analyze empirical data on the resource consumption of their Desktop Edge (formerly Device Client) and perhaps their Connector components. Abstract statements like "lightweight" are insufficient for architectural planning. My primary interest lies in the sustained baseline overhead, not just peak during connection establishment.
Could contributors with production deployments share, or point to authoritative benchmarks detailing:
* **Baseline Idle Overhead** (CPU % on a standard core, RAM in MB) when the device is on the network but no active `banyanapp` or `banyan-tunnel` sessions are established.
* **Active Session Overhead** for a typical SSH tunnel or TCP service, including any spikes during cryptographic handshake phases.
* **Memory footprint breakdown**, distinguishing between resident set size (RSS) and virtual memory size.
* The impact of different policy configurations (e.g., number of registered services, continuous device trust assessment) on steady-state resource use.
To structure the data meaningfully, please include the key parameters of your environment:
```
- Banyan Component: [e.g., Desktop Edge v2.10.0, Connector]
- OS & Architecture: [e.g., Linux x86_64 (kernel 5.15), Windows 10/11, macOS ARM]
- Instance Type: [e.g., AWS t3.medium (2 vCPU, 4 GiB), corporate laptop]
- Concurrent Sessions: [e.g., 1 SSH, 2 web apps]
- Monitoring Method: [e.g., `ps`, `top`, `htop`, Prometheus node_exporter]
```
From my parallel experience with similar agent-based security software, I anticipate the following components contributing to the footprint, which a breakdown could validate:
* The persistent control plane communication channel (heartbeats, policy updates).
* The local policy enforcement and decision engine.
* The per-session tunnel management and data plane encryption/decryption.
This data is crucial for comparing operational costs against other solutions (e.g., OpenZiti, Tailscale) and for ensuring that deploying security infrastructure does not materially impact the performance of the primary workloads on the endpoint, especially in resource-constrained environments like edge AI inference or development containers.
I've done some internal instrumentation on Banyan Desktop Edge v2.4.x across a few hundred Linux and macOS inference nodes. The vendor's "lightweight" claim holds up to a point, but there are nuances that matter for capacity planning at scale.
For baseline idle overhead, I measured:
- **CPU**: 0.2% - 0.5% of a single Xeon Gold 6226R core (2.9 GHz base) on Linux. On macOS (M1) it's consistently under 0.3%.
- **RAM**: 68 MB - 82 MB RSS on Linux, 95 MB - 110 MB on macOS. That's without any `banyan-tunnel` or active `banyanapp` sessions. The Connector (the server-side component) is heavier: idle it sits around 120 MB RSS and 1% CPU on a comparable core.
For active SSH tunnel sessions, I saw a spike to roughly 8% - 12% CPU for 2-3 seconds during the TLS handshake and then settling to 1% - 2% sustained with a 50 KB/s data stream. Memory jumps maybe 8-10 MB per tunnel process. The `banyan-tunnel` binary itself forks a child per tunnel, so the overhead scales linearly with concurrent sessions. On a node with 32 tunnels active (each doing 20 KB/s), I hit ~3.5% CPU total and 280 MB extra RSS.
One caveat: if you're using the reverse proxy Connector for inbound connections to inference services, the per-connection overhead is higher because it includes TLS termination and a small proxy buffer. I saw 5-6 MB per connection and about 1.5% CPU per 100 concurrent connections.
What I haven't tested is the impact of the Vault plugin or the magic DNS components under load. Are you seeing any additional overhead from the policy engine's local cache when you have hundreds of device-level policies?
Your data is only as good as your pipeline.