A new ariga/atlas-action/migrate/drift action runs atlas migrate drift in CI, so a scheduled workflow checks a database for drift between deployments.

The ariga/atlas-action/migrate/drift action runs atlas migrate drift as a CI step. It compares the database with the state its migration directory defines at the last applied version, read from the revisions table, and fails the step when the two differ. Pending migration files are not drift. The action never changes the database, and it takes the same lock as atlas migrate apply, so a deployment in progress is not reported as drift.

The action requires Atlas Pro and authenticates with a bot token: store it as a repository secret and pass it to ariga/setup-atlas with cloud-token. To create an account or start a free trial, run atlas login.

Scheduled Drift Check

The following workflow checks the production database every hour:

.github/workflows/drift.yml

name: Drift Detection
on:
  schedule:
    - cron: '0 * * * *'
jobs:
  drift:
    runs-on: ubuntu-latest
    steps:
      - uses: ariga/setup-atlas@v0
        with:
          cloud-token: ${{ secrets.ATLAS_TOKEN }}
      - uses: ariga/atlas-action/migrate/drift@v1
        with:
          url: ${{ secrets.DATABASE_URL }}
          dir: atlas://app

With dir set to an atlas:// URL, the expected state is fetched from the Atlas Registry. For a local directory, set dev-url to a dev database and the expected state is computed by replaying the directory on it.

The step fails when drift is found, or when a database cannot be checked because it is unreachable or has no migration history.

Inputs

All inputs are optional when the env in atlas.hcl sets them:

Input	Description
url	The database to check.
dir	The migration directory that defines the expected state, for example atlas://app or file://migrations.
dev-url	The dev database to compute the expected state on. Required unless the directory is in the Atlas Registry.
exclude	Glob patterns for objects managed outside the migration directory.
revisions-schema	The schema that holds the revisions table.
config, env, vars	Read the inputs from an env in atlas.hcl.
working-directory	The Atlas working directory.

Job Summary

On GitHub Actions, every checked database gets a section in the job summary, headed No Drift Detected, Drift Detected, or Drift Check Failed. It shows the applied version, where the expected state came from, the pending files, the change counts, and the fingerprint. Drifted objects are listed as extra (only in the database), missing (only in the expected state), or modified, with the SQL that reproduces them in a collapsible block. Each drifted database also gets a warning annotation.

Outputs

Output	Description
drifted	"true" if any checked database drifted.
fingerprint	Identifies the drift and changes only when the drift does, for deduplicating alerts. Set when a single database was checked and it drifted.
report	A JSON array with one report per database: the URL, applied version, mode, pending files, change counts, drifted objects with their SQL, and any error.

Multiple Targets

When env names an env defined with for_each, such as one database per tenant, every target is checked one at a time, each at its own applied version, and gets its own section in the job summary and its own entry in report.

Other CI Platforms

The Atlas task in Azure DevOps gets a Migrate Drift command. On TeamCity, the step reports two build statistics: atlas.migrate.drift.drifted, the number of drifted databases, and atlas.migrate.drift.changes, the number of changed objects.

Where It Fits

The pre-apply check in atlas migrate apply catches drift at deploy time. This action catches it between deployments.
Schema Monitoring runs as an agent and also covers databases without a migration directory. This action runs in your own CI with no agent, and needs a migration directory.

GitHub Actions: migrate/drift