The Power of Variables

Define a value once, scope it where it applies, and let Jaws Deploy resolve it per deployment.

Search guides... Ctrl K

A variable in Jaws Deploy is a named configuration value with a scope. Scopes are workspace, project, environment, target, and tag. At deployment time the platform resolves the value by walking the scope hierarchy from most-specific to least-specific.

The shape of the win

Without scoped variables, teams end up with a config.production.json, a config.staging.json, and a script that picks one based on $ENV. That works until somebody renames an environment, adds a fourth one, or needs a per-region override.

Scoped variables flip this. The variable lives in one place. The scope decides which deployment sees which value.

// Variable definition example

One variable, three scoped values

Jaws Deploy resolves to the most specific matching scope at deployment time.

Name: ConnectionStrings.Main

Values:
  scope: project                       -> "Server=localhost;Database=app"
  scope: environment=Staging           -> "Server=stg-sql;Database=app_stg"
  scope: environment=Production        -> "Server=prd-sql;Database=app_prd"
  scope: environment=Production, tag=region:eu -> "Server=prd-sql-eu;Database=app_prd"

Where variables are used

Three places: script steps (read as $Variables['Name'] or env vars), config files (token-replaced during deployment), and step inputs (any step parameter can take #{Variable.Name}).

The coverage matters - it means almost no deployment-time value needs to live in CI scripts or version-controlled config files.