For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deploying on Linux

Device Protection ships as a plain .deb or .rpm package, so any tool that can copy a file and run a package manager can roll it out. Every method does the same thing: fetch the package for the host, install it with your user group token in the environment, and get users onto a fresh login shell afterwards. The guides below cover the tool-specific parts.

Start with Install Device Protection for Linux for the token, the packages, and the install options they all share. The Linux Rollout Reference has the detail behind the shared steps: token handling, reboots, repeat runs, device identity, and upgrades.

Which guide to use

Situation
Use

A single machine, or one you're testing on

Existing fleet, agent checks in on a schedule

Existing fleet, you push over SSH

New cloud instances

Machines built from an image you control

Container images for CI or build jobs

Dev Containers and Codespaces

Buildkite agents and pipelines

Every guide follows the same shape: the configuration for that tool, how to verify the rollout, and what to check when something breaks.

If your MDM manages Linux devices, push the install command through it as a script. Otherwise, use the configuration management or provisioning tool you already run.

Device Protection secures the machines your developers work on. To scan servers for vulnerable packages instead, use VM Scanning.

Before you roll out

  • Decide which version the fleet gets. The download URL always resolves to the newest release. Mirror the package if you want the fleet to move on your schedule instead. See Versions and upgrades.

  • Guard repeat runs. Check whether the agent is already installed before downloading, so a second run does nothing. See Make repeat runs cheap.

  • Plan the reboot. Protection is only complete after a new login shell, so don't restart machines people are working on from an automation run. See When protection becomes active.

  • Roll out to a pilot group first. Each token belongs to one user group, so give your pilot hosts their own token and widen from there.

Last updated

Was this helpful?