Built for Windows servers

Many deployment tools assume Linux and containers. Jaws Deploy started from .NET applications on Windows Server, deployed with PowerShell. The agent runs as a native Windows service, and the built-in steps cover the usual IIS and Windows service work.

Built-in steps for Windows

Deploy package Extracts a package from the built-in feed or your own NuGet feed. Runs config transforms and replaces #{Variable} tokens in config files and JSON settings. Optional PowerShell hooks run after each stage.
Deploy IIS website Creates or updates the site and its app pool: bindings with HTTPS certificates and SNI, .NET CLR version, pipeline mode, 32-bit mode, app pool identity and authentication modes. IIS writes are retried when the config file is locked.
Install Windows service Stops and removes the existing service, installs the new build, and sets the service account, start mode and state after install.
PowerShell and Python Write your own steps in PowerShell 7, Windows PowerShell 5.1 or Python 3. Share helper functions across projects with script modules.

A typical IIS deployment

Three steps cover most ASP.NET sites. Values in #{...} are variables scoped per environment.

1. Deploy package
     Package:                 Acme.Web
     Installation directory:  D:\Sites\Acme.Web
     Replace variables in:    appsettings.json, web.config

2. Deploy IIS website
     Website name:            Acme.Web
     Physical path:           D:\Sites\Acme.Web
     Bindings:                https *:443:#{Site.Host} #{Site.CertThumbprint} sni
     Application pool:        Acme.Web (No managed code, ApplicationPoolIdentity)

3. Run a script (PowerShell 7)
     Invoke-WebRequest "https://#{Site.Host}/health" -UseBasicParsing

.NET Framework and modern .NET side by side

The deployment process doesn't depend on the runtime your app targets. A .NET Framework 4.8 site and a self-contained .NET 8 service use the same packages, variables and environments. web.config and appsettings.json both get variable replacement, and config transforms run per environment.

Variables can be scoped by environment, machine or tag. A different service account on each server doesn't need a separate pipeline. The agent also handles file paths longer than 260 characters.

Trigger deployments from your CI

The PowerShell SDK wraps the REST API in a few functions. They create a release, deploy or promote it, and stream the deployment log back into the build output. TeamCity also has a plugin. Any CI tool that can run PowerShell can use the SDK.

Create and deploy a release after the build

The service account ID and API key come from environment variables. The call waits for the deployment and prints its log.

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

$env:JAWS_API_LOGIN    = "<service account id>"
$env:JAWS_API_PASSWORD = $env:JAWS_API_KEY

Invoke-ReleaseAndDeployProject `
    -projectId       "<project id>" `
    -version         "2026.10.4.$buildNumber" `
    -environmentName "Staging"

Coming from Octopus

Projects, environments, variables, step templates, lifecycles, channels and releases work the way Octopus users expect. The Octopus Deploy alternative page covers the differences and how a migration goes.

When it isn't the right fit

If everything you run is in containers on Kubernetes and deployed with Helm, a GitOps tool will suit you better. Jaws Deploy is strongest where Windows servers, IIS and PowerShell are the norm.

Try it on one server

Create a free workspace (2 machines, no card needed). Install the agent on a Windows test server and deploy a sample site with the three steps above. Plan on about 30 minutes. If something doesn't work, tell us.