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
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.
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 tierCloud 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.
// Machines
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.
// Cloud targets
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.
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.