Environments and Targets

An environment is a stage. A target is where work runs. Tags decide which targets a step touches.

Search guides... Ctrl K

Three nouns do most of the work in Jaws Deploy infrastructure modelling: environment, target, and tag. Used with intent they keep the model small even as the deployment surface grows.

The three nouns

Environment A deployment stage like Dev, Staging, or Production. Variables scope to it. Lifecycles order them.
Target A machine, a cloud service, or any other endpoint that receives a deployment.
Tag A label on targets. Scopes steps and variables. Lets one process serve many target roles.

Environments are policy

An environment isn't just a name - it's a scope. When a release is deployed to Production, the platform resolves every variable through the Production scope, runs every step that opted into Production, and writes the deployment to Production's history.

That is why "deploy this release to Staging then to Production" works as a sentence: each environment carries its own resolution context.

// Topology example
// Environments
Dev └─ agent-dev-01 [role:app, role:db]
Staging ├─ agent-stg-01 [role:app]
└─ agent-stg-02 [role:db]
Prod ├─ agent-prd-01 [role:app, region:eu]
├─ agent-prd-02 [role:app, region:us]
└─ azure-prd-db [role:db]

Tags as schema

Tags are plain strings, but treat them as schema. Pick conventions early - role tags (role:app, role:db, role:cache), region tags (region:eu-west), tenancy tags (tenant:acme). Then a single deployment process can scope its database step to role:db, its package step to role:app, and its smoke test to role:app, region:eu-west.

Reduce the temptation to introduce new noun types as the surface grows. A region is a tag. A cluster is a tag. A tier is a tag.