Architecture Overview
Telovix has two operational components: the Console and the Sensor. The Console is the security workspace and control plane. A Sensor runs on each protected Linux host or Kubernetes node and sends observed runtime evidence to the Console over an authenticated outbound connection.
Deployment models
| Model | Console responsibility | Sensor responsibility |
|---|---|---|
| Self-hosted | Your team operates the Console and its data services | Your team deploys Sensors |
| Managed | Telovix operates the Console and its data services | Your team deploys Sensors |
Both models provide the same Sensor deployment choices and security workflows. The difference is who operates the Console infrastructure.
Platform components
| Component | Purpose |
|---|---|
| Console | User interface, authentication, fleet management, detections, investigations, API Security, Telco views, policies, and upgrades |
| Sensor | Runtime, process, file, network, API, TLS, Kubernetes, and optional telecom observation on a protected node |
| PostgreSQL | Users, settings, fleet state, policies, investigations, and other operational records |
| ClickHouse | Runtime observations, DNS activity, API evidence, metrics, and historical analytics |
| Redpanda | Optional durable buffer for production event delivery |
The Console binary includes its web application, current Sensor binaries for supported architectures and flavors, and the supported local SBOM scanner. A self-hosted installation does not require a separate frontend package.
Data flow
- An Admin or Operator creates the appropriate enrollment token in the Console.
- The Sensor enrolls and receives its client identity.
- The Sensor initiates an authenticated connection to the Console.
- The Console stores operational state in PostgreSQL and runtime analytics in ClickHouse.
- Users investigate evidence, assign detection policies, and manage response from the Console.
The Console never needs to open a connection to a Sensor. This outbound-only model is the same for virtual machines, bare metal, Kubernetes, K3s, and ephemeral hosts.
Identity and trust
Each Sensor receives a unique identity during enrollment. Certificates are renewed automatically while the Sensor can reach the Console. Revoking a Sensor prevents that identity from reconnecting.
Use one-time tokens for persistent VM or bare-metal installation, cluster tokens for Kubernetes, and fleet tokens for ephemeral hosts. See Enrollment Tokens.
Storage responsibilities
PostgreSQL and ClickHouse are both required for a complete Console. PostgreSQL holds control-plane records; ClickHouse holds the high-volume evidence queried by operational pages. Redpanda can be enabled for durable buffering when the deployment plan and ingestion profile require it.
Analytics retention is 30 days for Trial and 90 days for paid plans by default. Capacity must be based on measured daily ingestion, not only enrolled-node count. See Requirements for sizing.
Standard and Telecom
The Standard platform provides Linux, container, Kubernetes, API, TLS, runtime detection, investigation, and response capabilities. Telecom includes the complete Standard feature set and adds telecom protocol, network-function, RAN, user-plane, SLO, and packet-capture workflows.
Choose the platform vertical during Console setup and the matching Sensor flavor during deployment. A telecom Console can operate a mixed fleet of Standard and Telecom Sensors.
Kubernetes model
The Kubernetes Sensor is a privileged DaemonSet with one pod on each selected Linux node. Kubernetes metadata enriches observations from cluster workloads. The same fleet and API Security workspaces are used for Kubernetes and non-Kubernetes deployments; cluster selection scopes the shared data rather than creating a separate pipeline.
Availability and scale
For production:
- place PostgreSQL and ClickHouse on persistent storage;
- reserve ClickHouse free space for merges and retention cleanup;
- use Redpanda when durable buffering is required;
- expose the Console through a stable DNS name;
- monitor Console, database, and Sensor delivery health;
- roll out policies and upgrades through canaries;
- back up PostgreSQL and the Console data directory;
- apply your ClickHouse backup and disaster-recovery policy.
For regional boundaries or data-sovereignty requirements, deploy separate Consoles and use federation where licensed. Do not stretch one local data tier across unreliable regions.