Skip to content

System & Hardware Requirements ​

Because RUSEON Core operates entirely on a zero-transcoding transmuxing architecture with in-memory ring buffers and direct kernel I/O, hardware requirements are exceptionally low compared to traditional video management systems.


1. Hardware Sizing Guide ​

The following sizing recommendations are derived from empirical load testing on bare-metal and container environments:

Deployment ScaleCamera StreamsCPU CoresRAM FootprintStorage ArchitectureNetwork Interface
Edge / Small1 – 50 Streams1 vCPU256 MB – 512 MBSingle SATA SSD / High-Endurance eMMC100 Mbps / 1 Gbps
Medium / Commercial50 – 200 Streams1 – 2 vCPU512 MB – 1 GBSATA / NVMe SSD for BadgerDB + HDD Array for Archive1 Gbps Ethernet
High-Density / Enterprise200 – 600+ Streams4 – 8 vCPU2 GB – 4 GBDedicated NVMe for BadgerDB + RAID / ZFS for fMP410 Gbps Ethernet

TIP

Empirical Stress Baseline: During standardized benchmark testing (bench-baseline.md), 600 concurrent 30 FPS cameras (1.34 Gbps total ingest) with 1,800 active HLS viewers and 240 WebRTC viewers consumed only 471 MB RSS memory and ~3.6 CPU cores on a 12-core Linux server.


2. Operating System & Platform Support ​

RUSEON Core compiles to a self-contained static binary without external Cgo dependencies:

Operating SystemArchitecturesOptimization Level
Linux (Ubuntu 22.04/24.04, Debian 12, Alpine, RHEL 9)amd64, arm64, armv7Tier 1: Direct I/O (sync_file_range + POSIX_FADV_DONTNEED) and adaptive UDP sendmmsg batching
Windows (Windows 10/11, Windows Server 2019/2022)amd64Standard buffered I/O with periodic sync
macOS (macOS 12+ Monterey, Ventura, Sonoma, Sequoia)arm64 (Apple Silicon), amd64Standard buffered I/O (development & testing)
Docker / Kuberneteslinux/amd64, linux/arm64Official minimal container images (ghcr.io/rusegal/ruseon-core)

3. Network Bandwidth Calculation ​

To estimate required network capacity:

  • Ingress Bandwidth (Mbps): Sum of all camera bitrates ($\sum \text{Bitrate}_{\text{cam}}$).
    • Example (50 Cameras @ 2.5 Mbps): $50 \times 2.5\text{ Mbps} = \mathbf{125\text{ Mbps}}$.
  • Egress Bandwidth (Mbps): Sum of all concurrent viewer streams ($\sum \text{Bitrate}_{\text{viewer}}$).
  • Disk Write Bandwidth (MB/s): $\text{Total Ingress (Mbps)} / 8$.
    • Example (50 Cameras @ 2.5 Mbps): $125\text{ Mbps} / 8 \approx \mathbf{15.6\text{ MB/s}}$ of sustained sequential disk writes.

4. Storage & Filesystem Recommendations ​

  • BadgerDB Directory (./data): Low-latency SSD or NVMe storage for ACID metadata transactions. Requires ~16 MB MemTable memory.
  • Recordings Directory (./recordings): Linux ext4 or XFS formatted filesystem mounted with noatime,nodiratime for high-throughput sequential fMP4 chunk streaming.

Released under the MIT License.