Liquibase reads these at runtime, so no credential is written to disk and none needs to sit in liquibase.properties.

This is the foundation the other two methods build on. GitHub Actions secrets and Azure Pipelines variable groups both work by populating these same variables, so anything you learn here applies to both.

Why this matters for short-lived credentials

Because the value is read at runtime, it can be generated at runtime. That is the only way to use a credential that did not exist when the pipeline was written.

For a database using AWS IAM authentication, generate a token and assign it directly:

The token is valid for a limited window and is never persisted anywhere. No secret store is involved, because there is no long-lived secret to store.

Getting the names right

LIQUIBASE_COMMAND_USERNAME, not LIQUIBASE_COMMAND_USER. The shorter name is not a Liquibase variable, so setting it authenticates with no username at all and the failure reads as a credentials problem rather than a typo.

The general rule is that a command parameter maps to LIQUIBASE_COMMAND_<PARAMETER>, with hyphens becoming underscores. See What are Liquibase environment variables? for the full mapping and the precedence order when the same value is set in more than one place.

Where to go next

Environment variables are how the credential reaches Liquibase. Where the credential is kept is a separate decision:

• Secure setup using GitHub Actions secrets

• Secure setup using Azure Key Vault

• What are Liquibase secrets management extensions?, for HashiCorp Vault and AWS Secrets Manager