Declarative Migrations: Pre-Execution Checks

The check "schema_apply" block brings pre-execution checks to declarative migrations, letting teams enforce policy rules on the planned migration before any statement is executed on the target database.

Pre-execution checks were previously available only for versioned migrations via the check "migrate_apply" block. Starting with this release, Atlas Pro users can define the same policy rules for declarative migrations with the new check "schema_apply" block, evaluated by atlas schema apply after the migration plan is computed and approved, but before any statement is executed on the target database.

Pre-Execution Checks for Schema Apply

Checks are defined at the project level or inside specific env blocks and support allow and deny rules with the same semantics as the versioned flow: a matching allow short-circuits all remaining checks, and a matching deny aborts the deployment with an error. For example, the following gate ensures production can only be promoted to the schema version currently deployed in staging, read from the Atlas Registry with the cloud_databases data source:

data "cloud_databases" "staging" {
  repo = "myapp"
  env  = "staging"
}

locals {
  # `try` guards against the case where no staging deployment was reported to the registry yet.
  staging_version = try(data.cloud_databases.staging.targets[0].current_version, null)
}

env "production" {
  url = getenv("PROD_URL")
  schema {
    src = "atlas://myapp"
  }
  check "schema_apply" {
    deny "version_mismatch" {
      condition = self.planned_migration.target_version != local.staging_version
      message   = <<-MSG
  Production can only be promoted to the version validated in staging.
  Current staging version: ${local.staging_version}, planned production version: ${self.planned_migration.target_version}
  MSG
    }
  }
}

Checks run for interactive, auto-approved, policy-approved, and pre-planned applies, and are evaluated on --dry-run as well. If a deny rule matches, the deployment is blocked before any change is made:

Executing pre-execution check (1 check in total):

  -- check at atlas.hcl:16 (1 rule):
    -> check deny rule "version_mismatch"
    Error: "schema apply" was blocked by pre-execution check (deny rule: "version_mismatch" at line: 17):
    Production can only be promoted to the version validated in staging.
    Current staging version: 20260610120000, planned production version: 20260611080000

-------------------------------------------

https://<your-tenant>.atlasgo.cloud/migrations/304942681163

Auditing and Deployment History

Each reported schema apply records the registry version it deployed as the deployment's target version, providing a complete, auditable trail showing which schema version was applied to each environment, when, and by which pipeline. The Deployment Trace view offers an end-to-end record of how each change was deployed across environments, allowing auditors to verify that production only ever received versions that were previously validated in lower environments.

Environment Promotion End-to-End

Together, these enable an environment promotion workflow for declarative migrations that mirrors the versioned one: push the schema once, validate the pushed version in staging, and promote to production, which reads the validated version from the registry and rejects anything else:

# CI on merge: push the schema once, creating a new version in the registry.
atlas schema push --env ci

# Deploy the pushed version to staging and run validations against it.
atlas schema apply --env staging --auto-approve

# Promote: production reads the validated staging version from the registry.
atlas schema apply --env production --auto-approve

Read the full workflow in the Environment Promotion for Declarative Schema Migrations guide, and the new pre-execution checks documentation for schema apply.