NoldusViso – System requirements
Last updated: Nov 09, 2026
NoldusViso runs an entire behavioral observation lab from a single system — either a dedicated workstation acting as a server, or a laptop for portable set-ups. Cameras stream directly into it, users watch live or recorded sessions from any browser, and every recording is stored in one place. No separate recording PCs or viewer PCs are needed.
This chapter covers what's needed to run NoldusViso: the hardware to buy, how the platform is architected, and the network and security requirements for integrating it into your environment.
- Hardware scales with the number of cameras and simultaneous viewers — from a small single-room lab to a large multi-room facility.
- The network and security sections are written for IT/network administrators and system integrators who need to plan, secure, and support a deployment.
Important note: Network requirements, port configurations, and architectural details may change as the product evolves. Contact your Noldus representative for the latest specifications before finalizing a network or security configuration.
Prerequisites
- No prior NoldusViso setup is needed to read this chapter — it's the starting point, read before the Installation chapter.
- Implementing the network and security sections requires involvement from your IT/network administrator (firewall rules, DNS, certificates).
- A professional GPU is only needed if you plan to use the future AI analysis pipeline — it is not required to run NoldusViso today.
Hardware: choosing between a workstation and a laptop
NoldusViso can run on a central workstation (fixed lab installations) or a laptop (portable/mobile labs).
| Central server workstation (fixed lab installations) | Laptop (portable / mobile labs) | |
|---|---|---|
| Location | Stays in one location; cameras, microphones, and network connect into it. | Goes wherever your research or training takes you. |
| Scale | Scales from a small lab set-up to a large, multi-room facility. | Recommended for portable set-ups of 4–8 cameras. |
| Network | Integrates into your network environment. | Not intended to replace a workstation for larger, permanent installations. |
The specifications below are tested minimums per tier. The number of cameras and the number of simultaneous viewers together determine the load on the system — each camera-to-viewer combination is one "stream." Choose the tier that matches your camera count today, and check the notes if you're planning to grow.
Coming in the near future: it will become possible to install the NoldusViso software on a server environment the customer already has available, instead of on Noldus-supplied hardware. This requires a technical requirements discussion with your Noldus representative beforehand, to confirm the environment meets the specifications in this chapter.
Hardware: workstation set-ups
| Tier | Cameras | Viewers | Processor (min.) | RAM | Storage (NVMe) | Network card | Graphics card |
|---|---|---|---|---|---|---|---|
| Small lab — no expansion planned | 4–8 | 1–6 | Intel i7, 13th gen | 16 GB | 1 TB | 10 Gb | Onboard or expansion option* |
| Medium lab — environment, 1–3 rooms | up to 12 | 1–10 | Intel i7, 13th gen | 32 GB | 1 TB | 10 Gb | Onboard or expansion option* |
| Larger multi-room set-up | 12+ | 10+ | Intel i7, 13th gen | 64 GB | 2 TB+ | 10 Gb | Onboard or expansion option* |
All tiers have been tested by Noldus at these minimum specifications.
* Graphics card expansion: Nvidia RTX Pro 2000 Blackwell — optional, only needed if you expect to use the future AI analysis pipeline in NoldusViso.
Why these specs matter:
- Memory (RAM) scales with the number of camera streams. Both more cameras and more simultaneous viewers add load — four cameras watched by 10 viewers is 40 streams; 12 cameras watched by 10 viewers is 120 streams. More RAM keeps everything running smoothly as that number grows.
- Storage (NVMe) needs to be fast enough to record and save video without delay. As a rule of thumb, one hour of full-HD video from one camera is about 1 GB — size your disk for your longest recording days, and keep usage under roughly 80% of capacity. Storage capacity can be scaled to your needs.
- Network card (10 GbE) gives you the bandwidth headroom needed as your lab grows, so you don't need to replace the network card later.
- Professional graphics card (GPU) — optional. Not required to run NoldusViso today, since it runs mainly on the CPU. A professional GPU becomes important once AI-based analysis features arrive in later versions. A computer case with room for a professional-grade card (RTX Pro 2000 Blackwell) is recommended so one can be added later without replacing the workstation.
- Standard consumer graphics cards are not suitable for AI functionality and do not support more than 8 camera streams.
Hardware: laptop set-ups
A laptop lets you take NoldusViso with you. It is recommended for portable set-ups of 4 to 8 cameras.
| Tier | Cameras | Viewers | Processor (min.) | RAM | Storage (NVMe) | Ethernet | Graphics card |
|---|---|---|---|---|---|---|---|
| Portable lab | 4 | 1–10 | Intel i7, 13th gen | 16 GB | 1 TB | Gigabit (on laptop) | RTX 2000 — built-in |
| Portable lab | 8 | 1–10 | Intel i7, 13th gen | 32 GB | 2 TB | Gigabit (on laptop) | RTX 2000 — built-in |
Good to know:
- Laptops are recommended only for mobile labs of 4 to 8 cameras. For anything larger, use a workstation — a laptop should not serve as the "server" for a bigger, permanent installation.
- Unlike a workstation, a laptop's graphics card cannot be added or upgraded afterwards. If you may want AI-based analysis in the future, choose a laptop with the right GPU already built in. If not, a standard graphics card is enough.
Hardware: network switch and connected devices
- Network switch — must support 10 Gb/s and Power over Ethernet (PoE), so cameras receive power directly through the network cable with no separate power adapters needed.
- Cameras / screen-capture devices — IP cameras that support the ONVIF protocol are generally supported. Portable and stationary labs typically use AXIS cameras such as the 5526-E and the M1075. A PC or monitor screen can also be added as an extra input, adding one extra stream to the system's load, same as a camera. Talk to your Noldus sales consultant about specific camera types/brands and supported set-ups.
- Microphones — connected via the IP camera, through a Dante audio network, or via line-in microphones. Your Noldus contact can confirm the exact recommended models for your set-up.
Note: Anyone on the team — technician, administrator, trainer, trainee, or viewer — logs in to NoldusViso through the Chrome browser on their own PC or laptop. No special software or installation is needed on their device.
If your plans don't match one of the tiers above — more cameras, more viewers, longer recordings, or multiple locations — contact your Noldus representative so the right system can be sized together.
System architecture
NoldusViso is delivered as a self-contained appliance built from independently deployable, containerized services, organized into five logical layers:
| Layer | Responsibility |
|---|---|
| Edge | TLS termination, HTTP security headers, authentication enforcement for every request |
| Application | Web user interface, REST API, session and scheduling logic |
| Media | Live streaming (WebRTC), camera ingest (RTSP), recording and playback |
| Data | Relational database, time-aligned event store, video recordings |
| Observability | Metrics, logs, and traces for health monitoring and support |
Only three service entry points are exposed to the customer network: HTTPS on the edge (with an HTTP-to-HTTPS redirect), the WebRTC media port range, and a local NTP time service for cameras. All other services communicate exclusively over isolated internal container networks and are not reachable from outside the appliance.

Network requirements
In summary, NoldusViso needs:
- Inbound HTTPS (TCP 443) — web application access (TCP 80 is open only to redirect to HTTPS)
- Bidirectional UDP (10000–10499 by default) — live video streaming (WebRTC); the range is configurable and sized per deployment
- Outbound RTSP (TCP 554) — camera connectivity
- Inbound NTP (UDP 123) — required. NoldusViso is a time-aligned observation system: recordings, events, and annotations from multiple cameras and sensors are correlated on a single shared timeline. All cameras must synchronize their clocks against the appliance's local time service (or a common upstream source) — without it, multi-camera alignment isn't possible. The appliance's built-in time service also covers air-gapped networks.
Network topology and deployment scenarios
A segregated VLAN deployment is recommended: it isolates the camera network from the user network and limits the server's exposure to only the traffic it needs to send or receive.

| Scenario | Description | Pros | Cons |
|---|---|---|---|
| A — Single subnet | All devices on one network segment; minimal firewalling | Simple, easy to troubleshoot | No network segmentation, limited security isolation |
| B — Segregated VLAN (recommended) | Cameras isolated on a separate VLAN from users and server | Camera network isolated, improved security | Requires VLAN-capable infrastructure |
| C — DMZ (production, external access) | NoldusViso in a DMZ behind a reverse proxy for external access | External access supported, defense-in-depth | Complex configuration, NAT considerations for WebRTC |
Network traffic flows
Required flows
| # | Source | Destination | Protocol | Port(s) | Direction | Description |
|---|---|---|---|---|---|---|
| 1 | Browser | NoldusViso server | HTTPS | 443 | Inbound | Web application access, all web UI (TCP 80 redirects to 443) |
| 2 | Browser | NoldusViso server | WSS | 443 | Inbound | WebRTC signaling (WebSocket over HTTPS) |
| 3 | Browser | NoldusViso server | UDP | 10000–10499* | Bidirectional | Live video streams (WebRTC RTP/RTCP) |
| 4 | NoldusViso server | IP cameras | RTSP | 554** | Outbound | Video stream negotiation |
| 5 | IP cameras | NoldusViso server | RTP/UDP | Dynamic | Inbound | Video data transport |
| 6 | IP cameras / devices | NoldusViso server | NTP | 123 | Inbound | Camera clock synchronization against the appliance's time service — required for time-aligned recording and annotation |
| 7 | Admin workstation | NoldusViso server | HTTPS | 443 | Inbound | All admin interfaces |
* Default range; it is configurable and scales with the number of concurrent streams. Confirm the configured range for your deployment before writing firewall rules.
** Port 554 is the standard RTSP port; the actual port may vary by camera configuration.
Optional flows
| # | Purpose | Source | Destination | Protocol | Port(s) | Direction |
|---|---|---|---|---|---|---|
| 8 | Camera discovery (network scan) | NoldusViso server | Camera network | TCP/UDP | Camera service ports | Outbound |
| 9 | ONVIF device management | NoldusViso server | IP cameras | HTTP/S | 80/443 | Outbound |
| 10 | WebRTC NAT traversal* | User workstation (browser) | STUN server | UDP | 3478 | Outbound |
| 11 | Upstream time synchronization | NoldusViso server | Customer NTP server | UDP | 123 | Outbound |
| 12 | Name resolution | NoldusViso server | DNS server | UDP | 53 | Outbound |
| 13 | SSO / OIDC / SAML | NoldusViso server | Identity provider | TCP | 80/443 | Outbound |
| 14 | Event notifications (webhooks) | NoldusViso server | Customer services | TCP | 443 | Outbound (if configured) |
| 15 | Email notifications | NoldusViso server | Customer SMTP server | TCP | 587/465 | Outbound (if configured) |
* Required only when clients reach the server across NAT (Scenario C); typical on-premises LAN deployments do not use STUN. WebRTC NAT traversal originates from the user's browser, not from the server.
Firewall configuration
Required rules
- Inbound TCP 443 from the user network (HTTPS web access, WebRTC signaling, admin access); inbound TCP 80 may be allowed for the automatic HTTPS redirect
- Inbound/outbound UDP 10000–10499 (or the deployment's configured range) from the user network — bidirectional WebRTC media
- Outbound TCP 554 to the camera network (RTSP stream negotiation)
- Inbound UDP (dynamic) from the camera network (RTP video data)
- Inbound UDP 123 from the camera network — camera clock synchronization; required for time-aligned recording
Optional rules
- Outbound TCP 80/443 to the camera network (ONVIF device management, discovery)
- Outbound UDP 3478 from the user network to a STUN server (only for NAT scenarios)
- Outbound UDP 123 (upstream NTP) and UDP 53 (DNS) — recommended where an upstream source is available
- Outbound TCP 443 to an external identity provider — required only for external SSO
- Outbound TCP 587/465 to the customer SMTP server — required only for email notifications
Example: segregated VLAN firewall rules
# User VLAN -> NoldusViso Server VLAN
allow tcp from 192.168.1.0/24 to 192.168.2.100 port 443
allow udp from 192.168.1.0/24 to 192.168.2.100 port 10000-10499
# NoldusViso Server VLAN -> Camera VLAN
allow tcp from 192.168.2.100 to 192.168.3.0/24 port 554
# Camera VLAN -> NoldusViso Server VLAN
# (RTP return traffic + camera time sync only; scope the RTP rule to your
# cameras' configured RTP port range where your firewall supports it)
allow udp from 192.168.3.0/24 to 192.168.2.100
allow udp from 192.168.3.0/24 to 192.168.2.100 port 123
# Deny camera-initiated connections (security)
deny tcp from 192.168.3.0/24 to 192.168.2.100
Bandwidth guidance
| Traffic | Estimate |
|---|---|
| Per user, 1 video stream (live viewing) | ~2–4 Mbps |
| Per user, 4 video streams (live viewing) | ~8–16 Mbps |
| Per camera (recording) | ~2–4 Mbps |
| Administrative traffic | <1 Mbps |
Example: 20 concurrent users each viewing 4 cameras, plus 20 cameras recording — user traffic 20 × 16 Mbps = 320 Mbps, recording traffic 20 × 4 Mbps = 80 Mbps, total ≈ 400 Mbps. A 1 Gbps uplink is recommended for deployments of this size.
Security architecture
NoldusViso encrypts data in transit at every network hop and protects sensitive data at rest. This section states the guarantees the platform provides; implementation details are available under NDA where a customer security review requires them.

Encryption in transit
- All browser traffic is served over HTTPS at the edge with TLS 1.2 as the minimum version, a restricted modern cipher suite (TLS 1.3 is preferred whenever the client supports it), and HSTS enforced. Session cookies are Secure and HttpOnly.
- WebRTC media (camera and peer video/audio) between the browser and the platform is encrypted in transit using WebRTC's mandatory DTLS-SRTP profile.
- Single sign-on is handled via OpenID Connect over HTTPS.
- Internal database connections are TLS-encrypted; plaintext database connections are rejected, and this is verified as part of the deployment's automated checks.
- All remaining service-to-service traffic stays on isolated internal container networks. No application service is reachable from the customer network except through the entry points listed under Network requirements.
Data protection at rest
- Device and camera credentials are stored with an additional layer of column-level encryption using a key unique to each deployment; they are never stored or logged in plaintext.
- All application secrets are generated uniquely for each deployment at first boot — no deployment shares default credentials, and secrets are not embedded in shipped images.
- User password storage is the responsibility of the identity provider: the built-in identity provider stores only salted, adaptively hashed password verifiers (never plaintext); customers using an external IdP retain full control of their own password policy.
- Backup archives are encrypted with customer-held keys before they leave the appliance; backups are unreadable without the customer's key.
- For protection of bulk data (video recordings, database files) against physical access to storage media, Noldus recommends running the appliance VM on encrypted storage (hypervisor- or host-level full-disk encryption), which keeps key custody with the customer. Contact your Noldus representative regarding appliance-level disk encryption options for your deployment.
Identity and access
- Authentication uses OpenID Connect; role-based access control is enforced by the API on every request.
- Internal service-to-service calls are authenticated and fail closed in production.
Integration considerations
Camera compatibility
- Compatible: any IP camera with RTSP stream output.
- Commonly deployed camera families include Axis, Bosch, Sony, and Panasonic.
# Generic RTSP URL
rtsp://<ip>:554/stream
# Axis cameras
rtsp://<ip>/axis-media/media.amp
Identity provider integration
- OIDC (OpenID Connect) — OAuth 2.0 based, recommended.
- SAML 2.0 — enterprise SSO.
- LDAP — Active Directory integration.
Outbound HTTPS (TCP 443) to the external identity provider is required for any of the above.
DNS and SSL/TLS requirements
- Development: a self-signed certificate is acceptable.
- Production: a CA-signed certificate is required (Let's Encrypt, DigiCert, or equivalent); the certificate must match the domain name (CN/SAN).
- DNS: create an A record for the primary domain (e.g.
noldusviso.company.com). Depending on configuration, additional host names may be required — your Noldus representative will provide the exact set for your deployment. Internal DNS works for air-gapped environments, and the appliance's built-in time service keeps cameras synchronized without internet access.
Storage and retention planning
- Live viewing requires minimal local storage (<1 GB).
- Recording: approximately 1 GB per camera per hour (H.264, 1080p, 30 fps).
- Retention estimate: cameras × hours/day × retention days × 1 GB. Example — 10 cameras, 8 hours/day, 30-day retention: 10 × 8 × 30 × 1 GB ≈ 2.4 TB.
Reference: port quick guide
| Service | Protocol | Port(s) | Direction | Required |
|---|---|---|---|---|
| Web UI & admin | TCP | 443 (80 redirects) | Inbound | Yes |
| Live video (WebRTC) | UDP | 10000–10499* | Bidirectional | Yes |
| Camera RTSP | TCP | 554 | Outbound | Yes |
| Camera RTP | UDP | Dynamic | Inbound | Yes |
| Camera time sync (appliance NTP service) | UDP | 123 | Inbound | Yes |
| Camera ONVIF / discovery | TCP | 80/443 | Outbound | Optional |
| STUN (NAT traversal, from user browsers) | UDP | 3478 | Outbound | Optional** |
| Upstream NTP | UDP | 123 | Outbound | Recommended |
| DNS | UDP | 53 | Outbound | Recommended |
| SSO / IdP | TCP | 443 | Outbound | Optional*** |
| Email (SMTP) | TCP | 587/465 | Outbound | Optional |
* Default; configurable per deployment — confirm before writing firewall rules.
** Required only for NAT scenarios (Scenario C); originates from user browsers, not the server.
*** Required only when using an external identity provider.
Reference: deployment checklist
Pre-deployment
- Determine the NoldusViso server IP address
- Configure a custom DNS domain name
- Identify the camera network / subnet
- Verify network connectivity to cameras
- Obtain an SSL certificate (or generate a self-signed one for testing)
- Decide the time-sync topology: appliance as local NTP source for cameras, with an upstream NTP server where available
- Confirm the configured WebRTC UDP port range for this deployment
Firewall configuration
- TCP 443 inbound from user network (80 for redirect) — required
- UDP 10000–10499 (or configured range) bidirectional from user network — required
- TCP 554 outbound to camera network — required
- UDP outbound to camera network (RTP) — required
- UDP 123 inbound from camera network (camera time sync) — required
- TCP 80/443 outbound to cameras (ONVIF / discovery) — optional
- UDP 3478 outbound from user network (STUN) — only for NAT scenarios
- UDP 123 outbound (upstream NTP) — recommended
- UDP 53 outbound (DNS) — recommended
- TCP 443 outbound to identity provider — if using external SSO
- TCP 587/465 outbound to SMTP server — if using email notifications
Post-deployment verification
- Users can access the web interface via HTTPS (and HTTP redirects to HTTPS)
- Live video streams display in the browser
- Cameras are discovered or manually added
- Recording and playback function correctly
- Admin interfaces are accessible
- WebRTC media flows (check UDP ports with browser devtools)
- Camera clocks are synchronized against the appliance time service — verify before first recording; time-aligned playback and annotation depend on it