System requirements
EverNVR runs one recorder per site, on the same reachable network as the cameras. The appliance installer accepts the following host configuration:
| Component | Requirement |
|---|---|
| Operating system | Ubuntu Server 24.04 LTS or 26.04 LTS, x86-64 |
| Node.js | None: each release brings its own Node 22 |
| Python | System Python 3.12, 3.13, or 3.14; pinned detector wheels were built for 3.12 |
| Media tools | FFmpeg and ffprobe; the installer offers to install these, Python's venv support and smartmontools from Ubuntu's archive |
| Host services | systemd, including systemd-notify (the recorder's unit arms a watchdog and answers it through that tool; the installer refuses a host without it), and flock |
| Optional | smartmontools for disk hardware health; without it every configured disk reads SMART data is not available and the host check says so |
| Network | Stable LAN address (static or DHCP-reserved) and connectivity to cameras and clients; where that is impossible, the recorder can follow one interface's address |
| Storage | Persistent writable media storage sized for the actual camera bitrates |
| Installation access | The Python package index for the detector wheels; updates.harnessautomation.com for updates from Settings and for renewing the license (a site without it is licensed from a license file; see license) |
A Node.js installed on the host, or a user's Node version manager, is not used by
the installed service. The installer checks the actual host and dependencies before installing, then
asks which of the host's own addresses the recorder should answer on. Run its
host preflight first (./evernvr-VERSION-linux-x64.run -- --check, adding
-- --bind ADDRESS to test one address and its port, or -- --interface NAME
to test the address an interface has now); OS acceptance alone does
not establish hardware qualification. The .run bundles the application, the
models and the Node dependencies, but still requires the system prerequisites
and internet access for the detector's Python wheels, which include Piper for
spoken messages. A site with no access to
the release server can still update, from a release file. Makeself is only
needed on the build machine. Typing a spoken message in a voice the recorder
does not have yet downloads that voice, about 60 MB, from the Piper voices
repository on Hugging Face; recorded messages need no download.
Cameras
Cameras need ONVIF and a usable video stream, or a known RTSP stream address. ONVIF cameras can be discovered or added by address, including a non-standard ONVIF port. RTSP-only cameras can record and detect but have no ONVIF clock or PTZ controls.
EverNVR uses one connection per camera by default. A camera that already serves an existing recorder needs at least one connection free for EverNVR. If the manufacturer gives a higher simultaneous connection limit, entering it lets EverNVR use the camera's second stream, which costs the recorder less processor. EverNVR does not probe a live customer camera to exhaustion to discover that limit.
Detection and browsers
Detection runs on the processor unless a Hailo-8 accelerator is fitted. The recorder can set up a Hailo-8 for you on Ubuntu 24.04 and 26.04; without one, or if the accelerator fails, detection falls back to the processor and says so. See detection settings.
Use a current browser, and install the recorder's certificate authority on each device before real use. Codec support varies by browser and device, especially HEVC. Test the live view, historical playback, and exported clips on the devices the site will actually use.
Sizing a recorder
Two budgets decide the size of a site: detection and storage.
Detection. One accelerator serves every camera, so what has to fit is the number of cameras multiplied by the detection rate, not the camera count on its own. On a machine like the development host — a Ryzen 9 9955HX with a Hailo-8 M.2 — plan on about 20 cameras at the default 5 detections per second each. To fit more cameras on the same machine, lower the rate: 24 cameras at 4 per second, 32 at 3. That costs tracking detail on fast movement, not recording. Without an accelerator, each frame costs far more, and the processor has to be sized for the detection rate rather than for the recording.
Storage. Size it from the actual bitrates, not the camera count. Continuous recording on the bench cameras runs about 20 GB per 1080p camera per day and about 44 GB at 4096×1856. Multiply by cameras and by the retention the site wants, then add headroom for incident holds. A recording policy of Only around detected activity writes much less, but do not budget on it until the site's own scenes have been watched for a few days.
Before quoting a site, measure the intended resolution, bitrate, activity level, retention, and number of simultaneous viewers on the machine you intend to ship. Those planning figures come from short trials on one development machine; no recorder of any size has yet run for a full day. See detection capacity and support and limits.