By Jaws Deploy team · Updated

Creating Releases

A release is an immutable snapshot of packages, variables, and deployment process for a specific version.

Search guides... Ctrl K

A release is the unit of promotion in Jaws Deploy. It carries three frozen pieces under a single version number: the packages, the variable definitions, and the deployment process. Once created, none of these change.

What a release captures

Packages Exact package versions at release time - zip, tar, NuGet, whatever the steps consume.
Variable schema Variable definitions at release time. Values still resolve per environment - the set is what's frozen.
Deployment process The ordered steps the project had when the release was created.

When to create one

The usual moment is after a successful CI build. CI calls the Jaws Deploy API or SDK and passes: the project, the version, and any package mappings. The platform snapshots the rest from the project's current state.

// PowerShell SDK

How CI typically creates a release

Same shape works for TeamCity, GitHub Actions, GitLab, Jenkins, and Azure Pipelines.

Import-Module ./JawsDeploySdk.psm1   # github.com/JawsDeploy/powershell-sdk

# JAWS_API_LOGIN (service account ID) and JAWS_API_PASSWORD (API key)
# come from the CI secret store.

$release = New-JawsRelease `
    -projectId       "<project id>" `
    -version         "2026.5.17.$env:BUILD_NUMBER" `
    -packageVersions @{ "Checkout.Web" = "2026.5.17" } `
    -notes           (Get-Content ./CHANGELOG.md -Raw)

$release.releaseId

What you don't snapshot

A release does not capture environment state, target state, or live external systems. Those drift independently of releases. If the database schema in Staging is different from Production, re-deploying the same release to both will hit different state - that's a Staging/Prod parity problem, not a release problem.