> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/developer-machines/installation/script.md).
# Script
The **Script** page generates a ready-to-deploy installation package for Dev Machine Guard. It walks you through a four-step wizard: pick an operating system, choose a deployment pattern, set your configuration, then review and generate the output.
The page supports **macOS, Windows,** and **Linux**. The deployment patterns, scheduler mechanisms, configuration fields, and generated output all adapt to the operating system you select in Step 1.
For the underlying delivery model (loader script versus signed installer) and the binary verification flow, see the [Installation](/developer-machines/installation.md) overview.
### Generating an installation package
The wizard has four steps. Use **Continue** to advance and **Previous** to go back. Your selections carry through to the output generated at the end.
#### Step 1: Operating system
Select the target platform: **macOS, Windows,** or **Linux**. Your choice determines the loader type, the available deployment patterns, the scheduler used, the configuration fields shown, and the format of the generated output.
#### Step 2: Deployment pattern
Choose how you want to run the agent. The available options depend on the operating system selected in Step 1.
On macOS and Windows, patterns are grouped by intent under **Get started** (try it on a single machine) and **Scale deployment via MDM** (roll out to many machines). Linux offers its two patterns directly, without the MDM grouping.
**macOS**
* Get started: **One-time execution** (recommended) runs the script once for an on-demand scan; **Scheduled via launchd** installs a LaunchAgent so it runs on a schedule on this machine.
* Scale via MDM: **MDM-scheduled** (recommended) has your MDM run the script on a recurring schedule; **Scheduled via launchd** pushes once via MDM and the agent self-schedules via launchd.
**Windows**
* Get started: **One-time execution** (recommended) runs the script once for an on-demand scan; **Scheduled via Task Scheduler** registers a Scheduled Task so it runs on a schedule on this machine.
* Scale via MDM: **Win32 app** (recommended) produces a `.intunewin` package for Microsoft Intune; **MSI installer** provides the signed `.msi` for SCCM / Configuration Manager.
**Linux**
* **One-time execution** runs the script once per invocation.
* **Repeated execution** registers a systemd user timer to run on a schedule on this machine.
For step-by-step fleet rollout guides, see [MDM Deployment](/developer-machines/installation/script/mdm-deployment.md).
#### Step 3: Configuration
The configuration fields depend on the operating system and deployment pattern selected.
**Scan frequency** (self-scheduling patterns only)
Sets how often the agent scans the device after install, in hours (default `4`). It appears whenever the agent runs on its own recurring schedule: Windows Task Scheduler, the Linux systemd user timer (Repeated execution), and the macOS scheduled and MDM-scheduled patterns. On Windows MSI deployments it maps to the `SCANFREQUENCY` property. It does not appear for one-time execution, where there is no recurring schedule.
**Agent version**
* **Latest** (loader-based and Win32-app patterns): the agent resolves the newest release on each run. The page shows the current latest version (for example, `1.12.0`). This enables automatic updates. See [Auto-updating](#auto-updating).
* **Pin specific version**: lock the install to a known release.
* **MSI version** (Windows MSI installer pattern): the MSI is pinned at install time. Push a newer MSI to upgrade. Select the version from the dropdown. Unlike the loader-based patterns, MSI installs do not auto-update the binary in place; you upgrade by deploying a newer MSI through your MDM.
**Inactive threshold**
Sets the number of days after which a device with no telemetry is marked inactive in the device list. This applies to all devices and is saved to your organization settings when you generate. The same setting can be managed later on the [Settings](/developer-machines/installation/settings.md) page.
**Advanced configuration**
Expand this section to control install location, scan scope, and package scanners. On Windows MSI deployments these values are delivered via the MSI bootstrap file.
* **Install directory**: where the agent binary and logs live. Leave blank for the default: `~/.stepsecurity` on macOS and Linux, `%ProgramData%\StepSecurity` on Windows.
* **Scan directories**: one absolute path per line. Leave blank to scan the user's home directory.
* **Include TCC-protected directories** (macOS): scan Documents, Downloads, and similar locations. Requires Full Disk Access.
* **Package scanners**: choose which package ecosystems to scan (**npm, Homebrew, Python**).
* **Scan timeout**: maximum run time, in hours.
* **Stale-process age**: kill hung runs after this many hours.
#### Step 4: Review and generate
Review a summary of every selection. Hover a field to jump back and edit it, then select **Generate script** (or **Regenerate script** after a change).
The generated output depends on the deployment pattern:
* **Script patterns** (one-time execution, scheduled, repeated, MDM-scheduled) produce a loader script you copy or download, plus deployment instructions. The script is named for the platform and tenant, for example `stepsecurity-loader-linux-.sh`.
* **Win32 app** (Windows) produces the **Install** and **Uninstall** command lines to use when adding the `.intunewin` package as a Win32 app in Intune, along with a link to the [Intune guide](/developer-machines/installation/script/mdm-deployment/windows/microsoft-intune.md). Download the `.intunewin` from the GitHub release.
* **MSI installer** (Windows) produces the architecture-specific MSI download URLs (x64 and ARM64), a `bootstrap.json` to pre-stage tenant credentials and advanced scan configuration, and a link to the [SCCM guide](/developer-machines/installation/script/mdm-deployment/windows/microsoft-configuration-manager-sccm.md).
For the exact upload and configuration steps in each MDM tool, follow the linked guide rather than the summary values alone.
### Deploying the output
For script patterns, copy the script from the page or use **Download**, then deploy it through your MDM or EDR tooling. Because the loader handles binary download, version checking, and execution, no further configuration is required on the device. For a quick proof of concept, run the script on your own machine to see results right away.
For Windows Win32-app and MSI patterns, follow the [Windows MDM Deployment](/developer-machines/installation/script/mdm-deployment/windows.md) guides, which cover credential passing (inline MSI properties versus a pre-staged bootstrap file), architecture selection, upgrades, and uninstall.
#### Fleet deployment via MDM
For step-by-step guides on deploying at scale, see [MDM Deployment](/developer-machines/installation/script/mdm-deployment.md):
* **Windows** — [Microsoft Configuration Manager (SCCM/MEMCM)](/developer-machines/installation/script/mdm-deployment/windows/microsoft-configuration-manager-sccm.md), [Microsoft Intune](/developer-machines/installation/script/mdm-deployment/windows/microsoft-intune.md)
* **macOS** — [Iru](/developer-machines/installation/script/mdm-deployment/macos/iru-formerly-kandji.md)
### Auto-updating
**Loader-based deployments support automatic updates.** When you set **Agent version** to **Latest** in Step 3, devices pick up the most recent published release on their next scheduled run, with no further action required from you.
**To enable auto-update:**
1. Open the **Script** page.
2. In **Step 3: Configuration**, set **Agent version** to **Latest**.
3. Complete the wizard and generate.
Devices that already have the loader deployed pick up the change on their next scheduled run, and every subsequent release is delivered the same way. You do not need to redeploy the loader through MDM.
**How often updates arrive.** Devices check for a new release once per scheduled run. On self-scheduling patterns, the cadence is set by **Scan frequency**.
**Windows MSI is different.** The **MSI installer** pattern pins the binary at install time and does not auto-update in place. To upgrade an MSI fleet, deploy a newer MSI version through your MDM. See [Windows MDM Deployment](/developer-machines/installation/script/mdm-deployment/windows.md).
**Is auto-update safe?** Yes. Every binary the loader downloads is cryptographically verified before it runs. The loader carries an embedded StepSecurity releases public key, and a release is only executed if its signed manifest verifies against that key and its SHA-256 matches. See the [Installation](/developer-machines/installation.md) overview for the full verification flow.
{% hint style="info" %}
**Rolling back.** On loader-based patterns you can leave **Latest** at any time: set **Agent version** to a known-good pinned version and devices roll back on their next scheduled run. On MSI, roll back by deploying the previous MSI version.
{% endhint %}
### Pinning a specific version
If your environment requires change-controlled rollouts, or you want to validate a release in a staging fleet before promoting it, pin devices to a specific version instead of using **Latest**.
**To pin a version:**
1. Open the **Script** page.
2. In **Step 3: Configuration**, select **Pin specific version** (or, for Windows MSI, choose the desired **MSI version**) and pick the release (for example, `1.11.0`).
3. Complete the wizard and generate.
Loader-based devices move to the selected version on their next scheduled run. For MSI, the selected version is the one packaged for deployment. To roll out a later release, repeat with the new version selected.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.stepsecurity.io/developer-machines/installation/script.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.