Configuration System Overview & YAML Architecture
RUSEON Core utilizes a hybrid configuration model: static infrastructure parameters (networking, TLS, ports, authentication secrets, and storage paths) are defined in a clean YAML configuration file (config.yaml), while dynamic runtime entities (cameras, folders, user accounts, and archive metadata) are stored and managed inside the embedded BadgerDB v4 database.
1. Initial State Migration
When RUSEON Core boots for the very first time on an empty database:
- It reads the initial
cameras,folders, andglobal_tagssections fromconfig.yaml. - It automatically seeds these entities into the internal BadgerDB database.
- After initial seeding, dynamic entities should be managed via the Web UI, REST API, or CLI. Static server parameters (ports, JWT secrets, log levels) continue to be read from
config.yamlon every restart.
2. Environment Variable Overrides
Every YAML configuration property can be overridden using environment variables with the RUSEON_ prefix:
bash
# Override server host and port
export RUSEON_SERVER_HOST="0.0.0.0"
export RUSEON_SERVER_PORT="8080"
# Override JWT secret and log level
export RUSEON_AUTH_JWT_SECRET="production_random_secret_32_chars_long"
export RUSEON_LOGGING_LEVEL="info"
export RUSEON_RECORDING_STORAGE_PATH="/mnt/video/recordings"3. Configuration Subsections Directory
| Section | Description | Documentation |
|---|---|---|
| Server Settings | Host, ports, TLS certificates, CORS origins, and WebRTC ICE | Server Reference |
| Authentication | JWT token expiration, bcrypt work factors, and role definitions | Auth Reference |
| Camera Properties | RTSP timeouts, default transports, and stream profiles | Cameras Config |
| Recording & Retention | Segment durations, disk quotas, and retention schedules | Recording Config |
| Events & Webhooks | Webhook endpoints, MQTT broker settings, and Circuit Breakers | Events Config |
| Complete YAML Examples | Production-ready, development, and minimal YAML examples | YAML Examples |