# Projects and Deployment Logic

Source: https://www.jawsdeploy.net/guides/projects-and-deployment-logic

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

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.

> **// One process, many environments - Resist the urge to create separate processes per environment.**
> 
> If your Dev and Prod processes have diverged, the platform stops giving you the "this release passed Staging" guarantee. Use variables for environment differences. Use step scoping ("this step only runs in Prod") for the genuinely environment-specific work.

## 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.