# Environments & Targets

Source: https://www.jawsdeploy.net/features/environments-targets

Environments, machines, cloud targets, and tags are first-class objects - not strings inside a script. That is the difference between a pipeline that scales and one that gets copied for every new region.

## The vocabulary

Four nouns do most of the work in Jaws Deploy infrastructure modeling: **Environment**, **Machine**, **Cloud Target**, and **Tag**. They map cleanly to what you already have in production - the trick is using them with intent instead of treating them as labels.

## The four building blocks

- **Environment**: A logical deployment stage - Dev, Test, Staging, Production, Customer-A-Prod. Steps and variables scope to it.
- **Machine**: A physical or virtual server running the Jaws Deploy Agent. The agent makes outbound calls; you do not open ports inward.
- **Cloud Target**: An Azure Web App or similar service the platform talks to without a machine sitting underneath. Agentless by design.
- **Tag**: A label attached to machines and cloud targets. Tags scope variables, scope steps, and let you target by role or region.

## Environments are policy, not folders

A Jaws Deploy environment is more than a name. It is a **scope** that variables, steps, and lifecycles attach to. 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 history.

That is what makes "deploy this release to staging then to production" a sentence the platform actually understands, instead of a wish you encode into a shell script.

> **// Avoid this antipattern - Don't create one environment per machine.**
> 
> Treating each server as its own environment is the fastest way to lose the value of the model. Environments are stages of the release lifecycle. Machines are *where the work runs*. Tags are *how you group them*. Keep those three layers separate and the platform pulls its weight.

## Machines, agents, and how work actually reaches them

A machine in Jaws Deploy is a server with the **Jaws Deploy Agent** installed. The agent connects outbound to the control plane and waits for work. That single design decision shapes a lot of evaluator concerns:

## Network and security implications

- **No inbound ports.** The control plane never initiates a connection into your network. Useful when production lives behind a NAT or a hardened firewall.
- **Same model on Windows and Linux.** The agent runs on both. Steps that should work on one usually work on the other, with the obvious caveats around path separators and shell.
- **Survives intermittent connectivity.** If the agent loses the control plane briefly, it reconnects and resumes streaming logs.
- **One agent per machine.** That is the unit. Don't try to share agents across machines or run two on one box - you will eventually regret it.

## Tags are how a single pipeline serves multiple roles

Tags are pure strings, but you should treat them as schema. Pick a convention early. Examples that work well in the field:

```
role:app          # application servers
role:db           # database hosts
role:cache        # redis / memcached
region:eu-west    # geographic placement
tenant:acme       # multi-tenant isolation
size:large        # capacity tier
```

## Cloud targets: when there is no machine

For Azure Web Apps - and increasingly for other managed services - there is no agent because there is no OS to install one on. Cloud targets cover that gap. The platform talks to the service's management API and deploys to it directly.

The trade-off is real: you get less control over the execution environment, and some custom PowerShell tricks won't run. In exchange, you skip the agent lifecycle entirely. For a team that ships an Azure App Service plus a couple of supporting Windows boxes, mixing both models in one project is normal.

**When you need an agent**

Use machines for Windows Services, IIS sites, custom binaries, anything that needs to run **inside** the server. The agent is the bridge.

**When you don't**

Use cloud targets for managed services where the cloud provider runs the host. Less control, less to maintain, fewer moving parts.

> **// Real-world layout - What a healthy infrastructure model looks like**
> 
> Three environments (Dev, Staging, Production), each with a handful of tagged machines and one or two cloud targets. Tags `role:app`, `role:db`, `region:*`. Every variable scoped to either an environment, a tag, or a specific target. No project hardcodes a machine name. That is the shape that scales.

## Why this matters when you're evaluating

Every deployment tool can deploy a single artifact to a single box. The interesting question is what happens when the count goes up - twelve services, three regions, two tenants. If your model treats each as its own snowflake, the platform stops paying for itself.

Jaws Deploy's environment/machine/tag triple is deliberately small. There is no "Cluster", no "Region" object, no "Stack". A tag is a tag. An environment is a stage. A machine is a machine. The reduced surface area is the feature.