One deployment context, three runtimes.
Not every deployment step belongs in PowerShell — and not every team writes it. Every script step in Jaws runs under a managed runtime, and you pick the language per step: PowerShell 7, Windows PowerShell 5.1, or Python 3.
Whichever you choose, the step receives the same deployment context. It can read resolved variables and packages, emit output variables for later steps, and streams into the deployment log with the same step-level and target-level visibility. You can mix PowerShell and Python steps in a single deployment process.
Pick the runtime per step
$Jaws object and emit results with Set-JawsOutputValue.
$Jaws context and Set-JawsOutputValue functions.
import jaws gives you the same context PowerShell reaches through $Jaws — no extra install on your targets.
Emit an output value from PowerShell
Read a resolved variable from $Jaws, then hand a value to later steps. -Scope defaults to Machine; pass Global to share it across the deployment.
# PowerShell 7 or Windows PowerShell 5.1
$conn = $Jaws.Parameters["ConnectionString"].Value
# Share a computed value with every later step
Set-JawsOutputValue -Name "DeployedUrl" -Value "https://$conn/health" -Scope Global
The same step in Python
import jaws exposes jaws.parameters, jaws.packages, and jaws.set_output_value() — the direct counterparts of the PowerShell context.
import jaws
conn = jaws.parameters.get("ConnectionString")
# Share a computed value with every later step
jaws.set_output_value("DeployedUrl", f"https://{conn}/health", scope="Global")
Shared script modules, per language
Helper code copied across script steps belongs in a script module — a workspace-level library any script step can import. Modules are written for a specific runtime: PowerShell steps import PowerShell modules, Python steps import Python modules. Centralise connection helpers, retry logic, and logging wrappers once instead of pasting them into every step.
See Step Templates & Script Modules and the Custom Script Modules guide.
Nothing to install on your targets
The agent provisions and caches the runtime each script step needs, so scripts behave the same on every machine.
- Runtime provisioned and cached per target on first use
- Subsequent deployments reuse the cache — no download per step
- Air-gapped targets provision from a local archive, fully offline
- Warm the runtime at agent startup so the first deploy never waits