Introduction
Install one or more packages on a Linux device as part of an automation. Use this action to roll out tooling across your inventory, set up a baseline package set on new devices, or install software on a schedule without touching each machine by hand.
The action supports five package managers: Apt, Yum, Pacman, Snap, and Flatpak. You pick the manager per action step, so one automation can target a mixed-distro environment by branching on conditions.
⚙️ PREREQUISITES:
A Linux device under management.
The package manager you select must be present on the device. Selecting Apt on an Arch box, for example, fails the step.
For Flatpak, the
flathubremote must be configured on the device.
Supported Package Managers
You choose the manager explicitly from the Package manager dropdown. There's no auto-detect in the action: the value you pick is the one Level runs.
Manager | Typical distributions | Package name format |
Apt | Debian, Ubuntu, Linux Mint, Raspberry Pi OS | Debian package name ( |
Yum | RHEL, CentOS, Rocky, AlmaLinux, Fedora, Photon OS | RPM name |
Pacman | Arch Linux | Sync database name ( |
Snap | Any distro with snapd | Snap name |
Flatpak | Any distro with Flatpak | Flathub application ID (e.g. |
ℹ️ NOTE: The Yum option covers yum, dnf, and tdnf. The agent detects which binary the device actually uses and runs the right one, so you select Yum regardless of whether the device is RHEL (yum/dnf) or Photon OS (tdnf).
Add the Install Linux Package Action
Open the automation in edit mode and click + Add action.
Under App management, select Install Linux package. The action panel opens with Action type (pre-set to Install Linux package) and Step configuration.
Choose a Package manager.
Enter one or more names in Package(s). Press
Tabor add a comma after each name to add the next one.Click Save.
Package Manager
Required. Sets which tool runs on the device and which name format the Package(s) field expects.
The dropdown lists Apt, Yum, Pacman, Snap, and Flatpak. See the table above for what each one expects.
Package(s)
Required. The package names to install, in the format the selected manager uses.
The in-field hint reads "Use the package name as it appears in your distribution's repository," which is exact for Apt, Yum, and Pacman. Snap and Flatpak are different:
Snap takes the snap name (for example,
code).Flatpak takes the Flathub application ID (for example,
org.gnome.Calculator), not the friendly app name.
💡 TIP: For Apt, Yum, and Pacman, a name that doesn't exist in the repos is reported as "not found, skipping" and the rest of the action continues. Snap and Flatpak don't skip: they let the underlying tool error, so a typo there fails the step.
Specifying an Exact Version
By default the action installs the latest available version. Apt and Yum let you pin a specific version by writing it into the package name itself. Pacman, Snap, and Flatpak don't take a version string in this field.
Apt
Packages are identified by their Debian package name as shown by apt-cache search or dpkg -l.
Format | Example | Result |
|
| Latest available version |
|
| Exact version string |
|
| Specific architecture (multiarch) |
|
| From a specific release or suite |
Yum / DNF / TDNF
Packages are identified by their RPM name.
Format | Example | Result |
|
| Latest available version |
|
| Specific version |
|
| Version and release tag |
|
| Specific architecture |
|
| Fully qualified NEVRA |
Pacman
Packages are identified by their sync database name as shown by pacman -Ss.
Format | Example | Result |
|
| Latest version from the highest-priority repo |
|
| From a specific repository |
ℹ️ NOTE: Pacman doesn't support installing a specific version. It always installs whatever the configured repos currently hold.
How the Action Runs
A few behaviors apply to every install, regardless of manager:
Linux only. Run against a Windows or macOS device and the step returns "unsupported action." The rest of the automation run continues.
The selected manager must be present. If the binary isn't installed on the device, the step fails with "Unsupported package manager."
3-hour timeout on the whole action.
Live output. Command output streams line by line into the run log as it happens, so you'll see each
* Installing <pkg>line as the manager works.
For Apt, Yum, and Pacman, Level waits on the package-manager lock if another process holds it, backing off from 1 second up to 30 seconds between checks for up to 1 hour, then giving up with "Another package manager process is running." Snap and Flatpak manage their own queuing and don't wait on a lock.
Here's what runs per manager and the prep Level does first:
Manager | Install command | Preflight and notes |
Apt |
| Runs |
Yum |
| Clears the package cache first. Auto-detects yum/dnf/tdnf; on TDNF the |
Pacman |
| Removes a stale |
Snap |
| One package at a time. No "already installed" pre-check. Per-package install timeout of 60 minutes on top of the 3-hour cap. |
Flatpak |
| Installs system-wide (the agent runs as root), not per-user, from the |
⚠️ WARNING: These actions don't disable a device's own auto-updater (such as unattended-upgrades). A scheduled install can still race with the device's background updates. The lock-wait above is what keeps the two from colliding, not a hard stop on the auto-updater.
Conditions
The Conditions section restricts when this action runs based on device attributes or the outcome of a previous action. Expand it to add conditions.
See Action Conditions for the full reference on condition types, operators, and values.
💡 TIP: In a mixed-distro automation, gate each install step on the device's distribution or architecture so the right manager runs on the right machines and the rest skip cleanly.
Additional Options
Expand Additional options for execution settings including action name, failure behavior, output variables, and retries.
See Actions Overview for the full reference on options available on every action.
FAQ
Which package manager should I pick? The one that's actually present on the device. Apt for Debian and Ubuntu, Yum for RHEL-family and Photon, Pacman for Arch, and Snap or Flatpak where you've standardized on those. There's no auto-detect in the action, so the value you choose is the one that runs.
Can one action install across different distros? No, one step runs one manager. For a mixed inventory, add a step per manager and gate each on a condition (distribution or architecture) so only the matching devices run it.
How do I install a specific version instead of the latest? Write the version into the package name. Apt uses
name=version, Yum usesname-version(and longer NEVRA forms), Pacman has no version pinning, and Snap and Flatpak don't take a version string here. See Specifying an Exact Version above.What happens if a package name doesn't exist? For Apt, Yum, and Pacman, the package is reported as "not found, skipping" and the action keeps going. Snap and Flatpak surface the underlying tool's error for that package.
The package is already installed. Does the action fail? No. Apt, Yum, and Pacman skip packages that are already present. Snap runs the install command without a pre-check, which is a no-op if it's already there.
What's the difference between this and Install Linux Updates? Install Linux updates applies pending OS and security patches across the system. This action installs named packages you specify. Use updates for patching and this action for deploying specific software.
Does the device need to be online? Yes, for the action to run. If it's offline when the automation fires, the step queues and resumes once the device reconnects.
Who can add or edit this action? Technicians with permission to edit automations in the relevant group. See Workspace → Permissions for access control.