Deployment

Install the Runtime Sensor directly on Linux, run it in a host container, or deploy it as a Kubernetes DaemonSet.

Supported Platforms

Installation Methods

Native Packages

Native packages install the endura CLI, Sensor service, and environment file. Package-manager upgrades preserve configuration and restart a Sensor that was running before the upgrade.

The installation script detects the operating system and configures the appropriate package or signed TGZ:

curl -sSf https://repo.endurasecurity.com/install/endura-sensor/testing.sh | sudo -E sh

Review the script before running it if required by your change-control process.

Containers

The official image is ghcr.io/endurasecurity/container/endura-sensor:testing. A containerized Sensor still monitors the host, so it requires privileged kernel access, the host PID namespace, and host mounts described in the Docker and Podman guides.

Kubernetes

The Helm chart deploys a privileged DaemonSet so each eligible node has one Sensor. Kubernetes examples pin explicit chart and image versions.

Release Channels

Native, Docker, Podman, and CI examples use testing. Kubernetes pins an immutable version because a mutable tag is not re-pulled when its underlying image changes.

Team Server Compatibility

The Sensor and Team Server are compatible when their major versions match. Minor and patch versions do not gate compatibility and can be updated in either order.

At startup and every 15 seconds, the Sensor reads unauthenticated GET /api/version from Team Server. The response has this shape:

{"version":"1.0.0","build":"f57af95c"}

When the major versions differ, the Sensor warns, continues enforcing its current policies, and stops submitting registration, status, heartbeat, violation, and log data. It continues sending its version so Team Server can display the mismatch. Logs retained during the mismatch are submitted after compatibility is restored.

The Sensor resumes submission automatically within 15 seconds of a compatible response. No restart is required.

Use endura sensor status to distinguish the three states:

• active (online, N/M hooks attached)
• active (offline, ...)
• active (incompatible: team server <version>, ...)

The hook count shows how many supported programs are attached. Root can run endura sensor hooks for the per-program list.

For a major upgrade, update Team Server and all Sensors during the same maintenance window. Either order is supported. ENDURA_VERSION_CHECK=false disables the compatibility gate and should be used only as a temporary last resort.

Enforcement Technology

The Sensor prefers eBPF LSM hooks, which can deny operations directly. When the kernel lacks the required eBPF LSM support, the Sensor uses supported fentry hooks and terminates a task after detecting a prohibited operation. Review endura sensor status, endura sensor hooks, and startup logs to confirm coverage on each host.

Host Requirements

• 64-bit Linux with BTF data available at /sys/kernel/btf/vmlinux
• Kernel access required to load and pin eBPF programs
• Root privileges to manage the Sensor
• At least 1 GB of available memory; high-core systems may require more for per-CPU eBPF maps
• Outbound HTTPS to Team Server when centrally managed

Container deployments additionally need host /proc, host PID visibility, and /sys/fs/bpf access. Follow the container guide exactly because a root-only smoke test can hide an incorrect PID or proc mount configuration.

Team Server Enrollment

Create a Sensor in Team Server, copy its access token, and configure:

ENDURA_LICENSE_KEY=your_license_key
ENDURA_TEAM_SERVER=https://team-server.example.com
ENDURA_SENSOR_TOKEN=your_sensor_token

Store these values in the platform-specific secret or environment file. See the configuration reference for optional settings.

Next Steps

Choose the guide for the target host or cluster from the supported-platform table above.