Environments

One dblift.yaml describes all your environments, and a single selector picks the active one for every command. This is a config merge — it does not require a paid licence.

The model in one file

Root sections are the shared base. Each block under environments: is deep-merged over them when that environment is active.

database:                 # root sections = shared base
  type: postgresql
  username: dblift_app
migrations:
  directories: [migrations]

environments:
  prod:
    database:
      url: "${DBLIFT_PROD_URL}"
  uat:
    database:
      url: "${DBLIFT_UAT_URL}"
  staging:
    database:
      url: "${DBLIFT_STAGING_URL}"

resolve:
  branch_var: GITHUB_REF_NAME
  branch_map:
    "env/prod": prod
    "env/uat": uat

dblift migrate --env prod

An environments.agent block is the usual way to give dblift mcp a read-only login without putting the migrator password in the agent's process. Pin it with --env agent before mcp. Grant that role only the one schema the server should see: --db-schema can retarget any schema the role can read. See MCP Server.

Which environment wins

Selection, highest priority first:

Value precedence within the resolved config, highest first: CLI flag → environment variable → active environments.<name> block → root config sections → built-in default.

Every section can be specialised

Because environment resolution is a config merge performed before any feature reads the config, any section can differ per environment with no feature-specific support — a hardened corrections policy in prod and a permissive one in staging, different cutover settings, different migration directories, different secrets.

Enterprise snapshot source

An environment block can also name the snapshot that plan and preflight read. That key is Enterprise — it does not change how --env selects the overlay.

See Snapshot models for capture, publish, and snapshot.source.