Requirements

This page lists the confirmed hardware, OS, kernel, and network requirements for the Telovix Console and the Telovix Sensor. Requirements differ between the standard and telecom sensor flavors and between VM/bare-metal and Kubernetes deployments.

Telovix Console

Telovix self-hosted Console host

Requirement	Minimum	Notes
Operating system	Linux, any modern systemd-based distro	The Console binary is a single statically-linked Rust binary. It has no distro-specific dependencies.
CPU	2 cores	4+ cores recommended for production fleets
RAM	2 GB	4+ GB recommended for production fleets
Disk	10 GB for binaries and logs	Console state and policy packs are small. ClickHouse data grows with fleet size and retention period.
Architecture	x86_64 or aarch64	Both binaries are available from the Portal

Database requirements

Both databases must be reachable from the Console host before the setup wizard runs. The Console exits with an error if either is unreachable.

Database	Minimum version	Notes
PostgreSQL	15	Stores operational state. Schema migrations run automatically at startup.
ClickHouse	24.8	Stores all runtime events. Schema applied automatically at startup.
Redpanda	Any Kafka-compatible 2.x+ broker	Optional. Recommended for deployments above approximately 1,500 sensors.
Redis	Any recent stable release	Optional. Used for shared rate-limit state in multi-replica deployments only.

Console Kubernetes (Helm chart)

Default resource requests and limits from charts/telovix-console/values.yaml:

Resource	Request	Limit
CPU	250m	2000m
Memory	256 Mi	1 Gi
Persistent volume	5 Gi	Configurable

The Console requires a PersistentVolumeClaim for /data. Do not use emptyDir for this mount. Staged binary updates and the Console configuration file are written to this volume; they are lost on restart if the volume is ephemeral.

Telovix Sensor

Hard kernel minimum

The sensor will exit at startup if the kernel version is below 5.4. This is enforced in code:

Telovix Sensor requires Linux 5.4 or later.
This node will not be monitored.

The check reads /proc/sys/kernel/osrelease. An unreadable version string is treated as "unknown" and startup is allowed; the eBPF engine may then fail when it attempts to attach programs.

Kernel requirements table

Requirement	Minimum	Recommended	Impact if missing
Kernel version	5.4	6.x	Sensor exits at startup below 5.4
BTF (vmlinux)	Required	/sys/kernel/btf/vmlinux present	kprobe type resolution fails; some hooks may not attach. Build with CONFIG_DEBUG_INFO_BTF=y
BPF LSM	Optional but strongly recommended	CONFIG_BPF_LSM=y + lsm=...,bpf in kernel config or boot args	Without it, the LSM baseline policy is removed at startup. File access and privilege escalation detection falls back to kprobes only. Requires kernel 5.8+.
BPF filesystem	Required	/sys/fs/bpf mounted	BPF maps are unavailable without it
cgroup	v1 or v2	v2 preferred	v1 works; v2 gives more accurate container attribution
/proc filesystem	Required	Always present	Resource metrics and process inspection require /proc

How to check kernel readiness

# Kernel version
uname -r

# BTF
ls /sys/kernel/btf/vmlinux

# BPF filesystem
grep bpf /proc/mounts

# BPF LSM: check if "bpf" is in the active LSM list
cat /sys/kernel/security/lsm

# Full kernel config check (if /proc/config.gz available)
zcat /proc/config.gz | grep -E 'CONFIG_DEBUG_INFO_BTF|CONFIG_BPF_LSM|CONFIG_BPF_SYSCALL'

To enable BPF LSM at boot on a kernel that was compiled with CONFIG_BPF_LSM=y:

# Add to kernel boot parameters (GRUB or similar):
lsm=landlock,lockdown,yama,apparmor,bpf

PREEMPT_RT kernels

PREEMPT_RT (real-time) kernels are supported. The sensor detects them by reading /proc/version and checking for the PREEMPT_RT string. When a real-time kernel is detected, the sensor disables kprobe_multi and loads RT-safe policies only. Collection continues normally but some kernel probes that use BPF_MODIFY_RETURN on syscalls are skipped because the BPF verifier rejects them on RT kernels.

RT kernels are common on O-DU and vDU nodes. This is expected and handled automatically without operator action.

Sensor resource usage (VM / bare metal)

Resource	Quiescent	Normal load	Peak load
CPU	< 0.5%	< 1.0%	< 2.0%
Memory (RSS)	~60 MB	~80 MB	~120 MB

These figures are measured at representative telecom workloads (NGAP/GTP-U traffic, active UE sessions). The sensor is an event-driven process, not a polling loop.

Disk usage for the event spool (/var/lib/telovix-sensor/events.jsonl) is bounded at 100,000 events. Each event is approximately 1–3 KB of JSON, so the maximum spool size is roughly 100–300 MB. The spool fills only when the Console is unreachable for an extended period; on reconnect it drains at up to 100 events per heartbeat.

Sensor Kubernetes resource defaults

From charts/telovix-sensor/values.yaml:

Resource	Request	Limit
CPU	50m	500m
Memory	128 Mi	1 Gi

::: note O-RAN vDU and vCU nodes On constrained O-RAN devices with dedicated L1 DPDK cores, do not set the CPU limit above 200m. L1 radio processing has zero tolerance for CPU contention on non-isolated cores. Use the values-oran-vdu.yaml overlay which sets cpu: 200m and memory: 256Mi. Review NUMA affinity and isolcpus guidance before deploying on vDU nodes. :::

Sensor Kubernetes security context

eBPF requires privileged mode. The Helm chart sets these by default and they cannot be removed without breaking collection:

securityContext:
  privileged: true
  runAsUser: 0
hostPID: true
hostNetwork: true
hostIPC: false

The sensor requires hostPID: true for host-wide telemetry, hostNetwork: true for network-level collection, and privileged: true for BPF filesystem access and memory locking.

Verified distributions and kernels

The following combinations are confirmed working based on code comments and test references in the sensor source:

Distribution	Kernel	Notes
Debian 12	6.1.x	BTF and BPF LSM available by default
Debian 13	6.12.x	BTF and BPF LSM available by default
Ubuntu 22.04	5.15.x	BTF available; BPF LSM requires boot parameter
Ubuntu 22.04	6.5.x (HWE)	BTF and BPF LSM available
Ubuntu 24.04	6.8.x	BTF and BPF LSM available by default

Other systemd-based Linux distributions with kernel 5.4+ and BTF enabled are expected to work. RHEL/Rocky 8/9 and Fedora 38+ are commonly used but not listed as explicitly verified in the sensor source code.

Network requirements

Sensor to Console

Port	Direction	Protocol	Purpose
15483	Sensor outbound	HTTPS + mTLS	Heartbeat, enrollment, WebSocket stream (Telovix self-hosted default)
443	Sensor outbound	HTTPS + mTLS	Same as above for Telovix Cloud

All traffic is initiated by the Sensor. The Console never opens an inbound connection to a Sensor. No firewall rules are needed on the sensor host for inbound traffic from the Console.

Operator browser to Console

Port	Direction	Protocol	Purpose
15483	Browser outbound	HTTPS	Operator web UI (Telovix self-hosted default)
443	Browser outbound	HTTPS	Operator web UI (Telovix Cloud)

Console to databases (internal)

Port	Direction	Purpose
5432	Console outbound	PostgreSQL
8123	Console outbound	ClickHouse HTTP
9092	Console outbound	Redpanda Kafka broker (Scale tier only)
6379	Console outbound	Redis (HA rate-limiting only)

All database connections are outbound from the Console. No inbound ports need to be opened on the Console host for database traffic.

Telecom sensor: AF_PACKET monitoring interface

The telecom sensor flavor uses AF_PACKET raw socket capture for GTP-U, PFCP, SCTP, Diameter, RADIUS, and M3UA traffic. This requires CAP_NET_RAW, which is available when the sensor runs as root.

The monitoring interface is auto-detected at startup using this priority order:

1. Active sockets on telecom ports (2152 UDP for GTP-U, 8805 UDP for PFCP, 38412 SCTP for NGAP, 3868 TCP/SCTP for Diameter, etc.)
2. Default route interface from /proc/net/route
3. First physical interface from /proc/net/dev
4. Fallback: eth0

The monitoring interface can be overridden in Console Settings after enrollment.

Summary checklist

Before enrolling a node, verify:

# 1. Kernel is 5.4 or newer
uname -r

# 2. BTF is available (required)
test -f /sys/kernel/btf/vmlinux && echo "BTF OK" || echo "BTF MISSING"

# 3. BPF filesystem is mounted (required)
grep -q "bpf" /proc/mounts && echo "BPF FS OK" || echo "BPF FS MISSING"

# 4. BPF LSM is active (required for enforcement and LSM hooks)
grep -q "bpf" /sys/kernel/security/lsm && echo "LSM BPF OK" || echo "LSM BPF NOT ACTIVE"

# 5. systemd is present (required for VM/bare-metal sensor install)
command -v systemctl && echo "systemd OK" || echo "No systemd: use Helm chart instead"

# 6. Architecture is x86_64 or aarch64
uname -m

Further reading

• Quick Start
• Console Installation
• Sensor: VM / Bare Metal
• Sensor: Kubernetes (Helm)