Swif's Run by Command Script allows administrators to automate and manage tasks across devices in your organization, regardless of whether they are running macOS, Windows, or Linux.
With this feature, you can execute commands that streamline processes like system configuration, application management, or any custom task automation. Additionally, Swif provides flexibility to run commands manually or on a scheduled basis.
Run by Command Script Per OS
Swif supports a variety of command executions for macOS, Windows, and Linux. Below is a comparison of the command features available across different operating systems:
OS | macOS | Windows | Linux |
Run as Swif Admin | ✓ |
| ✓ |
Run as a Logged-in user | ✓ | ✓ | ✓ |
Run as System User | ✓DEFAULT | ✓DEFAULT | ✓DEFAULT |
Scheduled Job | ✓ | ✓ | ✓ |
Run as Swif Admin: Execute commands with administrative privileges (macOS, Linux). Make sure the Swif admin account is not disabled.
Run as a Logged-in user: Run commands as the logged-in user (macOS, Windows, Linux).
Run as System User (DEFAULT): Execute commands as the system user (macOS, Windows, Linux).
Scheduled Jobs: Run commands at specific times (or intervals) based on a defined schedule.
How to create a Run by Command Script
Step 1: Log in to the Swif Console
Start by logging into the Swif Console and navigating to Device Management. Select Commands to proceed.
Step 2: Create a New Command
Click on the Create New Command button to open the command configuration page.
Step 3: Add Basic Information
Fill in the following fields for your command:
Command Name: Give your command a clear, descriptive name (e.g., "Install Updates").
Description: Add an optional description to help identify the purpose of the command (e.g., "This command installs the latest security updates").
OS Type: Choose the operating system(s) for the command (macOS, Windows, or Linux).
Command Script: Enter the script you wish to run on the target devices. This script will vary depending on the selected OS:
For macOS and Linux, use bash or sh scripts (e.g.,
#!/bin/bash).To run as sudo, you can use `echo '{PASSWORD}' | sudo -S ls` where the PASSWORD is the local user password.
For Windows, use PowerShell or Batch scripts (e.g.,
#!/usr/bin/env pwshfor PowerShell). By default, it runs as a SYSTEM user.
Step 4: Schedule the Command
Run Schedule: Choose how the command will be executed:
Run Manually: The command will only run when manually triggered.
Run as Scheduled: The command will run at a specified time using the UNIX crontab format (
minute hour day-of-month month day-of-week). For more details on how to schedule commands, refer to the link on scheduling commands.
Command Status: Choose Enabled for the command to be active upon creation and trigger at the scheduled run time. If disabled, the command will not run unless manually enabled.
Tooltip: "Enabled: Command will be active upon creation and trigger at the scheduled run time. Disabled: Command will be inactive and won't trigger at the scheduled time until enabled."
Step 5: Set Timeout and Run with Admin Privileges (Optional)
Timeout After: Optionally set a timeout (in seconds) for the command to automatically stop if it exceeds a certain duration.
Run on Swif Admin Account: If you wish the command to execute with Swif Admin privileges (instead of a local user), check this box. This is particularly useful for running administrative tasks that require elevated permissions.
Step 6: Save the Command
Once you’ve filled out the necessary fields and configured the schedule, click Continue to deploy to devices or groups.
Running on the Swif Admin Account
When running on the Swif Admin Account, with the latest update, Swif now supports the use of dynamic placeholders in command scripts, enhancing security and ease of use. One of the key features introduced is the {{SWIF_ADMIN_PASSWORD}} placeholder. This allows scripts to dynamically use the generated Swif admin password at runtime, eliminating the need to hardcode sensitive credentials.
How to Use {{SWIF_ADMIN_PASSWORD}}
When writing command scripts in the Swif command editor, you can now insert the Swif admin password automatically. This is particularly useful for commands that require admin privileges. Here are some example commands:
sysadminctl -adminUser {{SWIF_ADMIN_USER}} -adminPassword '{{SWIF_ADMIN_PASSWORD}}' -secureTokenOn YOUR_USER -password 'YOUR_USER_PASSWORD'sysadminctl -adminUser {{SWIF_ADMIN_USER}} -adminPassword '{{SWIF_ADMIN_PASSWORD}}' -secureTokenOff YOUR_USER -password 'YOUR_USER_PASSWORD'This feature streamlines workflows by securely managing admin credentials and reducing manual input errors. For more detailed instructions on running commands as sudo on macOS with Swif, please take a look at Running Commands as sudo on macOS. For more details on running as a SYSTEM user, you can refer to Running Commands as Administrator on Windows.
How to Use {{SWIF_ADMIN_USER}} on Windows
Note, for security reasons, Windows usually prompts for the password interactively when you try to run as another user. This is a built-in security mechanism to avoid exposing credentials directly in scripts or command-line parameters.
Unlike macOS or Linux, where you can often pass credentials programmatically (e.g. sudo with automation), Windows requires the user to enter the password manually when using commands like runas.
Workarounds are using PowerShell’s Start-Process -Credential, or third-party tools like PsExec, but natively, RunAs itself doesn’t accept a password directly for security reasons.
Run Commands as Local User on Devices
Swif now supports running scripts as the logged-in local user on Mac/Windows/Linux devices.
How to Enable:
When creating or editing a command for Windows, you can now select:
Run As: Choose between
System(default, runs as the Windows SYSTEM user)Local User(executes in the context of the currently logged-in user)
✅ This is useful for scenarios where user-specific permissions, UI interactions, or profile paths (e.g., %USERPROFILE%) are required.
Notes:
If no user is logged in when the command runs, it will not execute.
This enhancement provides more flexibility in managing tasks like app installs, registry edits, or scripts that require user context.
To learn more details on running as Administrator or sudo user, you refer to How to run Commands as Administrator on Windows devices or How to Run Commands as sudo on macOS with Swif..
Viewing Command Reports
After executing a command, you can view the Command Report to review its output:
Go to Device Management and select Commands.
Click on View Command Report to see details about its execution, including any errors or success messages.
Troubleshooting Command Execution Issues
If you encounter any issues while running commands, refer to the following resources:
Troubleshooting Command Queueing Behavior and Status in Swif: Understand how a command is queued and processed.
Troubleshooting Windows Command Execution: If your Windows commands aren’t running as expected, consult this troubleshooting guide.
General Command Errors: Review the Command Report to check for any potential issues with the script or execution environment.
Triggering a Command by Webhook
In addition to running commands manually or on a schedule, Swif also lets you trigger a Run by Command Script from external systems using a webhook.
This is useful when you want another tool (for example, a CI/CD pipeline, security scanner, or monitoring system) to remotely trigger a command on your devices without logging into the Swif Console.
Webhook triggering is available on Growth plan and above.
How Webhook Triggering Works
Every command can be executed via webhook (both Run Manually and Run as Scheduled commands).
Webhook access is controlled via command tokens.
A webhook request can optionally target specific devices by serial number; if no serial numbers are provided, the command runs on all devices or groups configured for that command.
At a high level, the flow is:
Create or select a Run by Command Script.
Configure Webhook for that command and generate a command token.
Use the generated Webhook URL and token in your external system to trigger the command.
Webhook Configuration in a Command
When you create or edit a command, you’ll see a Webhook Configuration section (separate from the Run Schedule):
Webhook is optional and can be enabled on:
Commands that are run manually
Commands that are run on a schedule
This means the same command can:
Run automatically on a defined schedule, and
Be triggered on-demand by webhook when your external system calls it.
Webhook URL Format
Each command has a webhook endpoint in the following format:
:commandIdis the unique identifier of the command.The actual URL is shown in the command’s Command Details panel once webhook is configured.
You will use this URL together with a command token to trigger the command.
Managing Webhook Command Tokens
Webhook security is enforced by command tokens. A token represents permission to execute a specific command via webhook.
You manage tokens from the Command Details side panel:
View existing tokens
Create new tokens
Delete (revoke) tokens
Tokens are scoped to commands:
A token can be created and then assigned to a command.
You can manage multiple tokens per command if needed (for example, separate tokens per external system).
Triggering a Command via Webhook
Basic Trigger
To trigger a command without targeting specific devices, your external system should:
Make an HTTP request (typically
POST) to the webhook URL:Include your command token in the request (for example, in headers or payload, depending on your integration pattern).
When the request is valid and authorized, Swif will enqueue and execute the command as if you triggered it from the console.
Trigger for Specific Devices (by Serial Number)
The webhook API also supports triggering the command for specific devices by serial number.
In your request body, you can include a list of serial numbers to target:
{ "serialNumbers": [
"SERIAL_ABC123",
"SERIAL_DEF456"
] }When serial numbers are provided, the command runs only on those devices.
When serial numbers are not provided, the command runs on its default scope (for example, all assigned devices or groups for that command).
This is useful when:
An external tool reports an issue for a particular device and you want to remediate just that device.
You need fine-grained control over which endpoints receive a corrective or investigative script.
Where to See Webhook Tokens in the UI
In the Command Details side panel:
You’ll see a Webhook section that includes:
The Webhook URL for the command
A list of tokens associated with that command
From here, you can:
Create a new token
Copy an existing token (to configure in your external system)
Delete a token to immediately revoke webhook access
Token management is fully self-service and does not impact manual or scheduled executions of the same command.
Webhook Common Use Cases
Integrations with scanners or security tools
Example: A vulnerability scanner detects a risky package on certain endpoints and calls the webhook with their serial numbers to run a remediation script.CI/CD or deployment hooks
Example: After a deployment completes, a pipeline triggers a command by webhook to restart services or clear caches on specific devices.Monitoring and alerting
Example: A monitoring system detects abnormal behavior on one machine and triggers a diagnostic script via webhook for that device only.