atlas schema apply: Declarative Schema Sync
atlas schema apply inspects the target database and alters it to match a declared desired schema in one step.
This is the declarative workflow: instead of versioned migration files, you declare the desired schema and Atlas computes and applies the diff. It needs care in CI because it can drop objects.
What it does
atlas schema apply reads the desired schema from --to (HCL or SQL), inspects the live database from --url, computes the difference, and applies the DDL to make them match. It prints the plan and, without --auto-approve, waits for confirmation.
Common usage
atlas schema apply \
--url "postgres://ci:$DB_PASSWORD@db:5432/app?sslmode=disable" \
--to "file://schema.hcl" \
--auto-approveOptions
| Flag | What it does |
|---|---|
| --url <url> | Database to bring in line with the schema |
| --to <url> | Desired schema source (HCL or SQL) |
| --auto-approve | Apply without an interactive confirmation |
| --dry-run | Print the plan without applying |
| --exclude <pattern> | Ignore objects matching a pattern |
In CI
schema apply is interactive by default and will hang a pipeline waiting for approval; pass --auto-approve for non-interactive runs, but only where dropping unexpected objects is acceptable. Prefer the versioned migrate apply workflow for production; reserve declarative apply for dev or ephemeral databases.
Common errors in CI
A hanging job usually means schema apply is waiting at the approval prompt; add --auto-approve. Atlas warns on destructive changes ("Detected 1 destructive change") and can block them unless approved; review before allowing them in CI. Connection and permission errors mirror the other Atlas commands.