Deployment Package Steps
A deployment package is an ordered list of steps that agents run in sequence — install an application, copy files, run a script, stop and start a service, wait, reboot. This page is the field-level reference for authoring those steps and for scripting the whole create → upload → deploy → monitor workflow over the REST API or the PowerShell module. For the conceptual overview and package types, start with Software Deployment.
The step editor is available in the Athena console under Deployments, and
the identical workflow is exposed over HTTP at api/deployment-packages so it can be
scripted. Everything below applies to both. Creating, editing, uploading files to, building,
and deploying a package require the Admin role; listing and reading packages
and executions require the Operator role.
Anatomy of a package#
A package has a name, an optional description, a
folder name, an ordered set of steps, and a set of uploaded
files. The folder name is where the package's files are stored on the server; it
must be a single, safe path segment — no path separators and no ... Names that
contain a slash, backslash, or .. are rejected.
| Package field | Meaning |
|---|---|
name | Display name. Required. |
description | Optional free-text description. |
folderName | Single-segment folder for the package's files. Required, and must not contain path separators or ... |
steps | Ordered list of steps (see Step fields). |
files | Payload files uploaded to the package. Each file records its size, SHA-256 hash, and uploader. |
stepCount / deploymentCount | Read-only counters: how many steps the package has, and how many times it has been deployed. |
createdBy / createdAt / modifiedBy / modifiedAt | Read-only authorship and timestamps. |
Step types#
Each step declares a stepType that tells the agent what kind of action to run. The
supported types are:
stepType | Action | Key fields it uses |
|---|---|---|
RunCommand | Run a command or executable. | command, arguments, workingDirectory |
InstallApplication | Install an application (EXE/MSI). | fileName, arguments |
Uninstall | Uninstall an application. | command / arguments |
CopyFiles | Copy files to a destination. | fileName, targetDirectory |
PowerShell | Run a PowerShell script. | fileName or command, arguments |
Batch | Run a batch script. | fileName or command |
Shell | Run a shell script (Linux). | fileName or command |
StartService | Start a Windows service. | serviceName |
StopService | Stop a Windows service. | serviceName |
RestartService | Restart a Windows service. | serviceName |
Wait | Pause for a fixed interval. | waitSeconds |
Reboot | Reboot the machine. | — |
TriggerInventory | Trigger an inventory scan on the agent. | — |
Step fields#
Every step shares the same field set. Only the fields relevant to a given step type need to be populated; the rest can be left at their defaults.
| Field | Default | Meaning |
|---|---|---|
name | — | Human-readable title for the step. |
stepOrder | — | 1-based position in the sequence. Steps run in ascending order. |
stepType | — | The action to perform (see Step types). |
command | — | Command line to run (for RunCommand). |
arguments | — | Arguments passed to the command, installer, or script. |
fileName | — | Name of an uploaded package file to execute or copy. |
workingDirectory | — | Working directory for command execution. |
targetDirectory | — | Destination for CopyFiles. |
serviceName | — | Service name for the service step types. |
waitSeconds | 0 | Delay for a Wait step. |
timeoutSeconds | 300 | Per-step execution timeout. |
successExitCodes | "0" | Comma-separated list of exit codes treated as success — e.g. 0,3010,1641 to accept "reboot required" MSI codes. |
osCondition | Any | Restrict the step to specific operating systems (see OS conditions). |
conditionScript | — | A PowerShell expression; the step runs only if it evaluates true (when conditions are enabled). |
conditionEnabled | false | Whether conditionScript is evaluated. |
downloadEntireFolder | false | Download the whole package folder to the agent for this step, rather than just the step's file. Use when a step needs sibling files. |
runAs | System | Identity the step runs under (see Run-as identity). |
credentialId | — | The Credential Vault entry to use when runAs is SpecificCredential. |
continueOnError | false | If true, a failed step does not abort the rest of the sequence. |
OS conditions#
osCondition lets a single package carry steps that only apply to certain platforms —
a step whose condition doesn't match the target is skipped on that agent (and reported as
skipped). Values can be combined. The available conditions are:
| Value | Applies to |
|---|---|
Any | Any operating system (the default). |
Windows10, Windows11 | Specific Windows client versions. |
WindowsServer2016, WindowsServer2019, WindowsServer2022, WindowsServer2025 | Specific Windows Server versions. |
AllWindowsClient | All Windows client versions. |
AllWindowsServer | All Windows Server versions. |
AllWindows | All Windows client and server versions. |
Linux | Linux. |
Architecture64Bit, Architecture32Bit | Restrict by processor architecture. |
Run-as identity#
runAs controls which account a step runs under:
| Value | Runs as |
|---|---|
System | The local SYSTEM account. This is the default. |
CurrentUser | The currently logged-in interactive user. |
SpecificCredential | A stored credential — set credentialId to an entry from the Credential Vault. |
Files and rebuilding#
Steps like InstallApplication and CopyFiles reference a
fileName that must first be uploaded to the package. Uploading or removing a file
automatically rebuilds the package's bundle so its contents stay in sync; you can also rebuild it
explicitly at any time. A single package file upload is capped at 1 GB.
| Endpoint | Purpose | Role |
|---|---|---|
POST api/deployment-packages | Create a package (with its steps). | Admin |
GET api/deployment-packages | List packages (paged; optional search). | Operator |
GET api/deployment-packages/{id} | Get one package, including steps and files. | Operator |
PUT api/deployment-packages/{id} | Update a package (name, folder, steps). | Admin |
DELETE api/deployment-packages/{id} | Delete a package and its files. | Admin |
GET api/deployment-packages/{id}/files | List the package's files. | Operator |
POST api/deployment-packages/{id}/files | Upload a file (multipart field file) and rebuild the bundle. | Admin |
DELETE api/deployment-packages/{id}/files/{fileId} | Remove a file and rebuild the bundle. | Admin |
POST api/deployment-packages/{id}/build | Explicitly rebuild the bundle. | Admin |
POST api/deployment-packages/{id}/deploy | Deploy the package to targets. | Admin |
GET api/deployment-packages/executions/{executionId} | Get the status and results of a deployment. | Operator |
Deploying & targeting#
Deploying a package creates a deployment execution. At least one target must be supplied; the three targeting fields can be combined:
targetAgentIds— specific agents by GUID.targetTags— every agent carrying a matching tag.collectionId— every member of a collection.
A deploy request also takes a name for the execution, an optional
scheduledAt timestamp, and an optional skipCleanup flag:
| Deploy field | Meaning |
|---|---|
name | Name for this deployment execution. Required. |
targetAgentIds / targetTags / collectionId | Targets. At least one is required. |
scheduledAt | When set, the execution is created but not started until that time. When omitted, it starts immediately. |
skipCleanup | Leave the deployment files on the agent after the run (useful for debugging). Default is to clean up. |
Omitting scheduledAt starts the deployment right away. Supplying a future
timestamp creates the execution in a Scheduled state so it runs later. For recurring
rollouts, drive the deploy from a scheduled job instead.
Monitoring results#
Poll GET api/deployment-packages/executions/{executionId} to follow a deployment. The
execution reports rollup counters — totalAgents, completedAgents,
failedAgents, runningAgents, and progressPercent — along with
the current step, and a per-agent breakdown with per-step results (exit code, captured output,
and skip reasons). The overall status is one of:
| Status | Meaning |
|---|---|
Pending | Created but not yet started. |
Scheduled | Waiting for its scheduled start time. |
Running | Currently executing on one or more agents. |
Completed | Finished successfully on all targets. |
PartialSuccess | Finished, but some agents failed. |
Failed | Failed. |
Cancelled | Cancelled before completion. |
Rejected | The agent was busy and declined the deployment. |
A step that is skipped because its osCondition didn't match the target, or its
condition script evaluated false, is reported as skipped with a skip reason
rather than as a failure.
Scripting the workflow#
The Athena PowerShell module (PowerShell 7+) wraps the same API. Three cmdlets
cover the package lifecycle:
| Cmdlet | Purpose | Role |
|---|---|---|
New-AthenaDeploymentPackage | Create a package with its steps. | Admin |
Get-AthenaDeploymentPackage | List packages, or fetch one by -Id with its steps and files. | Operator |
Start-AthenaDeploymentPackageDeployment | Deploy a package to targets and (unless scheduled) start it. | Admin |
New-AthenaDeploymentPackage takes -Name, -FolderName, an
optional -Description, and an optional -Steps array.
Start-AthenaDeploymentPackageDeployment takes -PackageId (also aliased
-Id, and accepted from the pipeline), a -Name, target
-AgentId, and optional -CollectionId, -Tag,
-ScheduledAt, and -SkipCleanup.
A complete create → upload → deploy → monitor run. The package, deploy,
and query cmdlets have dedicated commands; the file upload and rebuild have no dedicated cmdlet, so
they use Invoke-RestMethod with the bearer token captured at sign-in (see the
API Reference for the sign-in round-trip):
# Import the module and sign in (session is reused by later cmdlets)
Import-Module Athena
Connect-Athena -Server athena.example.com -Port 8443
# 1. Define the ordered steps
$steps = @(
[PSCustomObject]@{
Name = "Install 7-Zip"
StepOrder = 1
StepType = "InstallApplication"
FileName = "7z2408-x64.msi"
Arguments = "/qn /norestart"
SuccessExitCodes = "0,3010" # accept "reboot required"
OsCondition = "AllWindows"
TimeoutSeconds = 600
},
[PSCustomObject]@{
Name = "Refresh inventory"
StepOrder = 2
StepType = "TriggerInventory"
}
)
# 2. Create the package (Admin role required)
$pkg = New-AthenaDeploymentPackage -Name "7-Zip 24.08" -FolderName "7zip-2408" -Steps $steps
# 3. Sign in for raw calls, then upload the file the step references
# (uploading a file rebuilds the bundle automatically)
$base = "https://athena.example.com:8443"
$login = Invoke-RestMethod -Method Post -SkipCertificateCheck `
-Uri "$base/api/auth/login" -ContentType "application/json" `
-Body (@{ username = "admin"; password = "<your-password>" } | ConvertTo-Json)
$hdr = @{ Authorization = "Bearer $($login.data.token)" }
Invoke-RestMethod -SkipCertificateCheck -Method Post -Headers $hdr `
-Uri "$base/api/deployment-packages/$($pkg.Id)/files" `
-Form @{ file = Get-Item ".\7z2408-x64.msi" }
# 4. Deploy to a tag right now (add -ScheduledAt to schedule for later)
$exec = Start-AthenaDeploymentPackageDeployment -PackageId $pkg.Id -Name "7-Zip rollout" -Tag "workstation"
# 5. Poll the execution until it finishes
do {
Start-Sleep 5
$res = Invoke-RestMethod -SkipCertificateCheck -Headers $hdr `
-Uri "$base/api/deployment-packages/executions/$($exec.Id)"
$s = $res.data
"{0} {1}/{2} agents {3}%" -f $s.status, $s.completedAgents, $s.totalAgents, $s.progressPercent
} while ($s.status -in "Pending","Running")
Uploading or removing a file rebuilds the package bundle automatically, so the example never
calls build explicitly — that endpoint is only needed to force a rebuild. Every
endpoint returns the standard response envelope, so the results live under .data.
The -SkipCertificateCheck flag (PowerShell 7+) trusts Athena's self-signed
certificate; drop it once you have installed a trusted
certificate.