© 2025 JawsDeploy. Founded and operating in the EU.
This article outlines the key concepts and building blocks of Jaws Deploy. It explains how Jaws Deploy organizes information about your infrastructure and deployment logic—two elements that, when combined, define the deployment flow.
Organization represents a single company or software vendor. During signup a new organization is always created. Organizations are also containers and direct parents of other core entities in JawsDeploy (such as users, service accounts and workspaces).
Every organization has the ability to organize their infrastructure into one or multiple workspaces. Workspaces are a convenient way to group apps, products or business partners of a company and are well isolated from each other. Workspaces are in a way sub-accounts of an organization. Note that users are defined on the Organization level and it is possible to configure workspace-specific access rights, including blocking access entirely to certain workspace for a given user.
When a new organization is created it gets a default workspace called "Main".
Environment is a well-known concept in the IT industry. Most software projects follow a typical flow:
This flow can be represented using a set of environments:
it is worth to point out, that some environments, usually test and production, should be configured in a very similar way in order to replicate production specific behaviors on the test environment. This helps in spotting any bugs early. Using a CD tool like Jaws Deploy makes this task easy, as all environments share most of the deployment logic.
In Jaws Deploy environments belong to a workspace, and all projects within that workspace share this set of environments. Each new workspace is created with two default environments: Staging and Production. You can easily customize this — specify any environment names you prefer and add as many environments as you need.
Functionally, environments are used to group servers. Each server (machine) may have zero, one, or many environments assigned. While a machine with no environments isn't very useful, it's still a valid setup. When executing a deployment, the user must pick an environment where the software should get deployed. Based on this choice, Jaws Deploy will distribute the software only to machines belonging to that specific environment.
Machines represent servers where the deployed apps and services are running. Any server, whether physical or virtual, can be transformed into a Jaws Deploy machine by installing a small piece of software — Jaws Deploy Agent. Agent runs in the background and facilitates communication with Jaws Deploy servers, enabling the execution of custom logic or the deployment of software across multiple machines simultaneously.
Cloud targets are a similar concept to Machines. Software package are uploaded to a cloud target and are executed there. The difference is that there is not direct access to the cloud target as a virtual machine, and it is not possible to interact with the underlying operating system. Cloud target exposes a set of APIs and often a GUI to control its behavior and deploy software to it. This means you can't install Jaws Deploy Agent on such target. Instead Jaws Deploy includes built-in logic which is able to automate basic interactions with a cloud target e.g. uploading software packages or restarting the hosted application or entire target.
Jaws Deploy supports only Azure Web Apps at the moment. More targets are in the works (AWS).
Projects define the deployment flow. They are like cooking recipes — consisting of multiple deployment steps and variables. Steps contain the logic that should be executed (e.g. fetch secret values from a key vault, or install a Windows service) and variables allow to parametrize that logic. Typically you would create a new project for every app or service that needs to be deployed.
Lifecycles are workspace-specific resources. The are like recipes for deploying code to multiple environments in a specific order. A lifecycle is composed of multiple ordered phases. Every phase:
On top of the above every environment in a phase may be set to “automatic” or “manual” mode. Automatic environments from first phase get deployed to when a release is created, without any additional actions required. Later when the system considers a phase complete - a set of deployments is triggered to all automatic environments from the immediately following phase. To assign lifecycle rules to a project and release use the Channels feature.
Read our guide about lifecycles and channels to learn more.
Channels represent assignment of lifecycles to a project. You can specify multiple lifecycles in a workspace, and later certain projects might depend on one or many lifecycles via adding channels to them. A channel has a direct relation to a single lifecycle.
Once a project supports a set of channels/lifecycles, every release that is created may (but does not have to) point to a channel. This way a specific release can be deployed to environments in the order specified in the referenced lifecycle, and also cannot be deployed to environments specified in phases which are not available yet (e.g. deployment to Production environment is blocked until a single successful deployment to Staging is performed).
Read our guide about lifecycles and channels to learn more.
Deployment steps are basic building blocks of a project as they contain the logic to be executed. Steps can be configured in many different ways: executed only on specific environments, machines (either via tagging or by selecting specific machines from a list) or they can be skipped entirely.
To define a step you always need to select what template it should be based on. The simplest possible step template, built into JawsDeploy by default, is “Run a PowerShell script”. Based on that you could implement virtually any kind of deployment step. But JawsDeploy has also other re-usable step templates, which encapsulate commonly used logic (e.g. a template that deploys a pakcage to a server and adjusts its configuration files). This greatly speeds up the time needed to set-up a complete deployment.
Every workspace has its own collection of step templates. If you find the built-in step templates not enough — it's very easy to update them or create your own.
Our roadmap includes a step template gallery, maintained by Jaws Deploy, with support for community-contributed step templates.
Tags are very similar to labels. Every workspace has its own set of tags. It is possible to add your own or modify existing tags. Once you have a set of tags ready, you can apply them to machines or cloud targets. Every machine may be tagged with multiple tags. Later on you can use those tags to control variable scoping or let Jaws Deploy pick the right machines to deploy to.
Tags can be used to:
Variables are a powerful mechanism to drive and customize the deployment flow and logic. Most of Jaws Deploy editable fields within a project step mayb include variables. Use variables to:
When all the machine, project and environment setup is ready and the deployment time comes — that's when a release must be created. A release freezes state of the project (it literally copies the project’s logic and variables) which allows you to deploy it multiple times and to many different environments using exact the same flow and variables, even after there are changes made to the project. This also means that for any project changes to be applied to next deployments, a new release must be created.
Releases are versioned using SemVer 2.0 (https://semver.org). Whehn you create one Jaws Deploy will suggest new version by increasing the latest version’s patch number by 1. You are free to use any version number though - as long as it is SemVer compliant.
A release can be optionally associated with a channel, which in turn is related directly with a single lifecycle. This allows fine-grained control over progression between environments for this release, and allows preventing arbitrary deployments to protected environment (e.g. Production). Read our guide about lifecycles and channels to learn more.
Every release can be deployed to multiple environments and as many times as required. Performing the deployment creates a new deployment instance directly attached to the release. Every deployment has it’s output logs, warnings and errors recorded. When a release is associated with a channel deployment to specific environments may be restricted based on flexible rules of the related lifecycle. Read our guide about lifecycles and channels to learn more.
Every workspace in your organization has a built-in NuGet package feed. The feed is managed internally by Jaws Deploy server and stored securely in the cloud (or on your infrastructure in the case of Jaws Deploy Stack installation). You can push packages to this feed in two ways:
Later you can fetch packages from the feed and deploy them to target machines. It is a convenient way to let JawsDeploy server deploy your packages in case you don’t want to expose your internal package feeds to the outside world.
Jaws Deploy built-in NuGet feeds are not full-fledged like the ones found on nuget.org. They can be only consumed by the built-in “Deploy package” step template and via Jaws Deploy Rest API.
You can connect your existing NuGet feeds to Jaws Deploy. This is particularly useful if you already publish build artifacts to a NuGet feed and don't want to alter your build automation. To do this, create a new Package Feed within a workspace and provide the feed URL and credentials (if authentication is required). You can then reference this feed in a "Deploy package" project step and select the package you want to deploy. To ensure Jaws Deploy can access your existing feed, make sure your firewall allows Jaws Deploy's public IP to access the feed server on port 443 (HTTPS).
Script modules are PowerShell modules, which you may be familiar with as .psm1 files. Specify your own modules, fill them with utility functions and commandlets and reference them in your projects. Then use module’s functions and commandlets within the project’s deployment steps. This allows you to re-use common logic across multiple projects.
Read our guide to script modules to learn more.
Users in JawsDeploy are directly associated with an Organization. Each user can have multiple roles, which define their access rights. These rights specify which resources a user can access and what actions they can perform on those resources. A single user may have access to multiple workspaces and various projects within these workspaces.
Service accounts are very similar to users. They are created on the Organization level and may have multiple roles attached. The purpose of a service account is to authenticate against Jaws Deploy HTTP Rest API. The server will fulfill API request only if the service account has appropriate access rights (which are based on the roles assigned to that account).
To call the HTTP API as a service account you will need an API key connected with that account. The API key is just like a password, which must be attached to every API request.
API keys are available to the user who creates them only once, at the time of creation. It is not possible to recover them later due to security reasons. If your API key is lost or compromised you’ll need to create a new one.
Keep your API keys secure, preferably in a key-vault or a password manager.
Jaws Deploy includes the following built-in roles:
It is not possible to create more custom roles - this feature is on our roadmap.
When you assign a role to a user, you usually will also specify scope of the role. This does not apply to “Organization administrator” role, which allows full access to everything.
Scope of a role may be defined by:
© 2025 JawsDeploy. Founded and operating in the EU.