Overview

You build your data model on a development instance, and at some point that work has to reach staging and production. Environment Sync makes that a git workflow: the Directus CLI (directus-cli, or its short alias d6s) writes an instance's Schema and Configuration to JSON sync files you commit, then applies those files to any instance you point it at.

d6s sync pull --from staging     # write the instance's Schema + Configuration to sync files
d6s sync diff --to production    # preview what pushing the sync files would change
d6s sync push --to production    # apply them

Because the sync files live in your repository, you can review changes in pull requests, promote them through git history, and use a revert plus another push to restore an earlier state. d6s sync on its own runs a small interactive wizard that pulls and pushes in one pass.

The CLI is built to be safe to point at production: diff never applies anything, deletions happen only in mirror mode behind their own explicit consent (that includes removals during a rollback), and the CLI asks you to resolve records that match more than one target record. It never guesses. How It Works covers the full safety model.

What syncs

• Schema: every collection, field, and relation, including custom fields on system collections.
• Configuration: roles, policies, access, permissions, flows, operations, dashboards, panels, settings, media-library folders, and custom Data Studio translation strings.
• Opt-in: user accounts, with every secret field stripped.

Unlike a full schema snapshot, a pull is not all-or-nothing. --collections posts narrows which Schema files it overwrites, and resource flags like --flows or --no-schema choose which Configuration files it touches. That is how you promote finished work from a shared development instance while unfinished work stays out of the sync files entirely. Scope is by collection and resource type, not by individual record. See Promote only the changes that are ready.

Records in your own collections are content, and Environment Sync does not sync them. It moves the shape of a project and its configuration, not its content.

Before you start

• Both instances must run Directus 12.2.0 or later, at the same exact version and on the same database vendor. The patch release must match. The server refuses an incompatible schema comparison: some patches change the snapshot format, and database vendors describe column types differently. --allow-drift bypasses the check when you accept that risk; see the compatibility gate.
• An admin credential for each instance. A static token from an admin user is the usual choice. The CLI verifies this and refuses non-admin tokens: the server rejects non-admin schema and import writes, and non-admin reads are silently filtered by permissions, which would produce sync files that look complete but aren't.
• A git repository. The sync files are designed for review and versioning. Any repository works; many teams use the one that already holds their Directus deployment configuration.

Where to go