Cross platform support
Jaws Deploy is built on .NET 8 and PowerShell 7, ensuring full cross-platform compatibility. All deployment steps and custom scripts run in PowerShell 7, with support for both Windows and Linux agents.
Support for more scripting languages (bash, python) is on our roadmap for 2025.
Topology
Topology is the structural map of everything Jaws Deploy manages — projects, environments, machines, tags, variables and more. It defines how your components relate and operate together. It reflects how your systems are organized and interact, whether in cloud, on-prem, or hybrid setups. This model serves as the foundation for orchestrating deployments, managing configuration, and enforcing environment-specific workflows at scale.
The following entities make up the topology model:
- Projects
- Environments
- Machines
- Cloud targets
- Tags
- Variables
- Script modules
- Step templates
- Lifecycles
- Channels
- Package feeds
Read more about each entity on our Core Concepts page.
Step-based deployment logic
Every deployment executed within Jaws Deploy is based on a project (which typicaly represents a single application or service) which is composed of a series of ordered deployment steps. Each step can be scoped to specific environments, machines, or tags, ensuring it only runs when the step scope matches the current deployment target.
You can define each step in one of two ways:
- Custom PowerShell Script
Write a one-off PowerShell 7 script for full control over deployment logic — ideal for advanced or project-specific needs. - Step Templates
Reuse pre-built, configurable templates that encapsulate common deployment patterns. Step templates simplify complex logic into a few input fields while maintaining flexibility.
Step templates
Step templates are reusable building blocks for deployment pipelines. They consist of a custom script and UI definition (JSON).
- Use built-in steps
Jaws Deploy comes with a set of templates that are ready to use right out of the box - Deploy Package, Run Script, Install Windows Service and more. - Create your own
Design custom templates tailored to your environment and processes.
Fully flexible: Templates support custom input controls and layered custom logic. Custom input controls become variables available in your deployment scripts. A step template may also include sub-scripts that can be hooked up at different stages of the main deployment script. - Fully flexible
Templates support custom input controls and layered custom logic. Custom input controls become variables available in your deployment scripts. A step template may also include sub-scripts that can be hooked up at different stages of the main deployment script.
A full Step Template Library packed with ready-to-use templates for AWS, Azure, Docker, and more is on our 2025 roadmap.
Tagging
Organize your machines with custom tags — by role, region, hardware specs, or any criteria that fits your infrastructure. Tags make it easy to filter, group, and understand your fleet at a glance.
Tags also power targeted deployments: scope steps to run only on machines with specific tags, like role:applicationServer or region:Europe. This gives you precise control over where and how updates roll out.
Variables
Variables are multi-valued and allow scoping. This means that deployment logic picks a specific variable value depending on environment, machine, or a tag. Every scriptable component of Jaws Deploy can use deployment variables and has access to all built-in variables in current deployment context. Variables may reference other variables, as long as there is no circular dependency.
Typically variables are used to:
- Inject values into a config file based on JSON or XML path
- Replace special placeholder in configuration files
- Configure a deployment step property
- Control the flow of a deployment script
Jaws Deploy supports project-level and workspace-level variables. Project variables are accessible only within the project they belong to. Workspace variables can be imported (linked) into any project in the workspace.
Fragment of a configuration file with variable placeholders:
appsettings.json
{
"ConnectionStrings": {
"MyDb": "server=#{db_server};user=#{db_user};..."
},
...
}
When a deployment flows through project steps, before a step script is executed Jaws Deploy will resolve the step context (depending on environment, current machine) and apply variable values accordingly to the script context. It will also populate the context with a set of built-in variable values, which can be accessed within deployment scripts. Below is a sample snapshot of a step context:
9:19:40 PM [Debug] Starting remote step runner
9:19:40 PM [Information] Skipping package upload - no packages to upload
9:19:40 PM [Information] Preparing script to be executed on agent 1d1b94ae-1ca2-4780-8d70-8af7b7080e31 / Web server EU 001
9:19:47 PM [Debug] Running script
9:19:47 PM [Debug] =============================================Script context dump - agent---------------------------------------------
Parameters:
CONTEXT.CurrentStep.Index: [Number] 1
CONTEXT.CurrentStep.Skipped: [Boolean] False
CONTEXT.CurrentStep.StepId: [Text] 054a71b9-4235-4e9f-9a5b-375fdbca1e98
CONTEXT.CurrentStep.StepName: [Text] Prepare deployment environment
CONTEXT.DeploymentDate: [Date] 07/21/2025 19:19:40
CONTEXT.DeploymentId: [Text] ce8a62e1-75c4-46a2-98a5-63973d5ab1ea
CONTEXT.EnvironmentId: [Text] 4d7d330d-4876-437c-852f-3d75c2be243f
CONTEXT.EnvironmentName: [Text] Staging
CONTEXT.MachineId: [Text] 1d1b94ae-1ca2-4780-8d70-8af7b7080e31
CONTEXT.MachineName: [Text] Web server EU 001
CONTEXT.ProjectId: [Text] 139828d9-b8a6-4c92-b3d4-ca725d7e786d
CONTEXT.ProjectName: [Text] Onyx Web Api
CONTEXT.ReleaseVersion: [Text] 0.0.16
STEP.ScriptBody: [Script] Write-Host "Starting logic..."
VAR.Install path: [Text] /opt/web/onyx
VAR.__debug: [Boolean] True
Variable scoping
Variable scoping is designed to provide precise control over configuration values across different environments, machines and deployment stages. Variables can be scoped at multiple levels — environment, machine or tag. When a variable is not scoped - its value is constant in every context. When multiple scopes are specified - the variable value with the strongest matching scope wins. Here "strongest match" depends on how many conditions are met. Value that matches environment and machine context wins over a value that matches only machine, or only environment.
Example scoped variable with multiple values:
Configuration transforms
Jaws Deploy includes custom PowerShell commandlets which allow modifying configuration files. Two formats are supported: JSON and XML. Transformation of JSON files merges the file on the left side of the => operator into the file to the right.
Merging XML files is based on XDT transformations. This approach is most often found in older .NET Framework applications (e.g. App.config, Web.config, log4net.config and similar). JSON merging is based on Newtonsoft.Json Merge function strategy with Array merging set to Replace.
Structured variable replacement is also supported - replace nested values in JSON files using hierarchical variable names. E.g. variable foo:bar:baz=123 will update this JSON:
{ “foo”: { “bar”: { “baz”: 0, “moo”: 100 } } }
into:
{ “foo”: { “bar”: { “baz”: 123, “moo”: 100 } } }
Here is a sample setup for a configuration transformation in a "Deploy package" step:
Package feeds
Deployments can't live without code that needs to be deployed. Jaws Deploy can operate with the following package formats: NuGet, .zip, .tar and .tar.gz. There are two ways to let Jaws pick up your packages:
- Built-in package feed
Every Workspace comes with a separate package feed which accepts all package formats mentioned above. You can upload them manually using the App UI or via Rest API. This approach is suitable for scnearios where you want Jaws Deploy to be isolated from your CI or package repository. Deploy only what you specifically uploaded to the feed. - Custom NuGet feeds
Hook up your existing package NuGet feeds from TeamCity, Azure DevOps and other CI tools. Jaws Deploy will automatically scan the feed and pick the latest package to release. Package version can be also overridden when creating a release - both via App UI and via Rest API.
Lifecycles and channels
Lifecycles define how a project release is flowing from environment to environment. Some projects might require different progression rules on a release-basis - here are some examples:
Lifecycles are defined per workspace. They contain multiple ordered phases, each phase with a set of environments to deploy to. A project release created based on a specific channel will flow through phases defined in the lifecycle. Moreover - some environments may be deployed to automatically, when release is created, or when previous phase has completed.
- Typical releases will flow through certain test/staging environments and then on to production.
- Others might need to be delivered only to a staging server (e.g. for feature preview).
- The same project might also need a hotfix release which should be quickly delivered to production, without going through all typical environments.
Deployment history
All deployments are recorded, including the snapshot of all data and variables of a specific release. Review previous deployments, inspect their execution time and trends.
Deployment live preview
Whether you are running deployments from the App UI or automated from your CI tools - there is a live preview od all deployment logs, structured into a tree-hierarchy - grouped by steps and deployment targets (machines).
Rest API
Jaws Deploy offers a simple Rest API to automate your workflows easily from any CI. Our PowerShell SDK will help get you started - it wraps the most important APIs and exposes them as PowerShell commandlets.
