SaltStack deploys AI Watch to Linux fleets the config-management way: Salt
installs the runlayer-aiwatch package on each minion and manages the two
config files, so a state.apply both rolls out and continuously asserts the
Detect-only contract. This is the same Linux (Detect only)
package — see that page for supported distributions and the scan cadence. This
page covers only the Salt-specific delivery.
An example formula (runlayer-aiwatch/init.sls, the config templates, and
pillar.example.sls) is available from your Runlayer account team. It is a
starting point, not a supported product — copy it into your own Salt tree
and adapt it to your conventions.
What it does
- Installs the
.deb / .rpm from your own Salt fileserver
(salt://runlayer-aiwatch/), selecting the right filename by OS family.
- Manages
/etc/runlayer/aiwatch/config.json (0644, non-secret) and
/etc/runlayer/aiwatch/credentials (0600, root-only) from pillar, so Salt is
the source of truth for both.
- Ensures the cron daemon is enabled. Cron re-reads the packaged
/etc/cron.d/runlayer-aiwatch on its own; the config files trigger nothing.
Linux is Detect-only: cron-scheduled scans across all users, no endpoint modes,
Sessions, or browser extension. In the dashboard the device shows Detect =
Active and Protect / Enforce / Sessions = Disabled — the expected state, not an error.
Prerequisites
-
A Salt master with the minions enrolled, plus a cron daemon on each minion
(the package pulls one in automatically — see Linux).
-
The
.deb and .rpm on your Salt fileserver under salt://runlayer-aiwatch/.
The Runlayer CDN is token-gated, so fetch the packages once with your
download token and serve them from salt:// — Salt itself never talks to the
CDN:
Contact your Runlayer account team if you don’t have a download token.
Pillar keys
The formula reads a single runlayer_aiwatch pillar. Copy pillar.example.sls,
fill it in, and target it at the right minions:
Never put the org API key in config.json, and never commit it in plaintext.
config.json is world-readable by design so unprivileged per-user scan children
can read managed settings; the key belongs only in the 0600 credentials file.
Keep the plaintext key in a GPG-encrypted pillar (Salt’s #!gpg|yaml
renderer decrypts it on the master at compile time) or your existing secrets
backend. The formula writes the credentials file with show_changes: False so
the key is never echoed into Salt job returns or master logs.
config.json renders Host, plus DetectProcesses / DetectContainers when
the optional detect_processes / detect_containers pillar values are set;
settings managed in Runlayer override the pillar-rendered toggles once
delivered. To change scan limits or enable other optional discovery, add the
supported settings from the Linux deployment guide
to your Salt-managed template. The Linux package remains Detect-only.
Managed self-update is always on. Pin the Client Updates version to match the
Salt pillar version.
Apply
The first apply installs the package and writes both config files; cron fires
the first scan on the next 15-minute tick. The packaged hourly updater remains
enabled and applies the version selected by your Client Updates policy.
Verify
In the Runlayer dashboard, go to Shadow AI → Devices: the device appears
with OS = Linux, Detect = Active, and Protect / Enforce / Sessions =
Disabled within about 15 minutes. For on-host verification
(sudo /usr/lib/runlayer/run-aiwatch-scan.sh), see Linux (Detect
only).
Idempotency
A second state.apply is a no-op while the installed package and the two
config files match the pillar. Upgrade by bumping version in the pillar and
placing the new .deb / .rpm on your fileserver; the next apply installs it
in place. Your managed config.json and credentials are re-asserted from
pillar on every run.
Other config managers
This generalizes directly: install the .deb / .rpm, manage config.json
(0644) and credentials (0600), and ensure cron runs — the same three steps
port to Ansible, Puppet, or Chef. 
