# The Power of Variables

Source: https://www.jawsdeploy.net/guides/the-power-of-variables

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

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.

## 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 `$Jaws.Parameters["VAR.Name"].Value` in PowerShell, `jaws.parameters["VAR.Name"]` in Python), config files (token-replaced during deployment, as `#{Name}` or `#{VAR.Name}`), and step inputs (any step parameter can take `#{VAR.Name}`).

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

> **// Secrets - Secret variables are encrypted at rest and redacted in logs.**
> 
> Mark a variable as a secret at creation. Once saved, the value isn't shown in the UI or returned via the API. Secrets follow the same scoping rules as regular variables.