Projects and Deployment Logic

A project bundles a deployment process, variables, lifecycle, and release history into one unit.

Search guides... Ctrl K

A project is the unit of deployment in Jaws Deploy. It typically maps to a single application, service, or batch job - the smallest thing you would deploy on its own. A project owns four things and references a fifth.

What a project contains

Deployment process Ordered steps that run when a release is deployed to an environment.
Variables Project-scoped values, inherited and overridden at finer scopes (environment, target, tag).
Lifecycle reference Which lifecycle releases follow - Dev/Staging/Prod, or any other shape.
Release history Every release ever created from this project, with deployment outcomes per environment.

The deployment process

The process is the active part of a project. It's a list of steps, in order. Each step has a type (deploy a package, run a script, restart a service, etc.), a configuration, and a target scope (which environments and which tags it applies to).

The same process runs against every environment. Differences between Dev, Staging, and Production come from variables, not from forked processes.

How projects relate to other objects

Projects live inside a workspace. A workspace can hold many projects, all sharing the same environments, lifecycles, feeds, and targets. Project-level isolation comes from variable scoping and permissions, not from running multiple workspaces.

Larger organisations sometimes run multiple workspaces (one per product line, one per regulated tenant), but the default is one workspace per team.

When to split into multiple projects

Split when two units have independent release cadences, different deployment processes, or genuinely separate codebases. Don't split when two things ship together - keeping them in one project means one release, one deployment, one rollback boundary.