Pulling

Pulling snapshots a source instance into the committed files that diff and push later apply:

d6s sync pull --from staging

What a default pull exports

A pull touches two axes, and the success output reports each:

◇ Pulled from staging — https://staging.example.com
  Schema     24 collections → directus/default/schema
  Resources  206 records in 10 resources → directus/default/data

Exact counts depend on your project.

• Schema: a full snapshot of every collection, field, and relation, including custom fields on system collections and collection folders.
• Resources: records of 10 directus_* configuration resource types, listed below.

Users and translations are excluded by default. Opt in with --users and --translations, or --all.

Configuration resources

Resource selection follows a dependency graph: selecting a resource pulls in what it needs.

Selecting resources

Three ways to change the default set:

• Positive selection: --flows --roles narrows the pull to those resources plus their dependencies.
• Subtraction: --no-flows keeps the default set and removes flows.
• Everything: --all adds users and translations on top of the default set.

Positive selections cannot be combined with --all or with --no- subtractions.

Resource selection changes only the resources axis: a pull with --flows still snapshots the full schema. Schema has its own scoping.

Scoping the schema

d6s sync pull --from staging --collections articles,authors

The Schema line reads (scoped to: articles, authors) and only those collections' schema files refresh. --exclude-collections inverts the scope: snapshot everything except the named collections.

Two warnings a scoped pull can raise:

• Out-of-scope references. If the scoped snapshot points at something you omitted (a relation target, a group parent, a many-to-any collection), the pull warns, because pushing that snapshot to a fresh target can fail. It warns; it never widens the scope for you. Add the missing collections to --collections yourself.
• A name the server didn't return. A --collections name absent from the returned snapshot (usually a typo) draws a warning naming the gap. The partial snapshot still commits, but never silently.

Skipping schema entirely

Schema and resources are independent axes, and resource selection never narrows the schema snapshot. To make a configuration-only project explicit, opt out of schema:

d6s sync pull --from staging --no-schema

To make it permanent, set "schema": false on the project in directus.config.json. Such a project carries no schema authority: pull skips the snapshot, and push and diff for that project never touch schema. Reports say schemaSkipped, so automation can tell a skipped phase from a matching one. Combining "schema": false with a collections scope is refused as a contradiction.

What a pull touches

Two rules govern every pull, scoped or not:

1. A pull only rewrites what it fetched. Everything it did not fetch keeps its committed bytes, untouched.
2. A push only applies what is committed. Work that never entered the repository cannot ship.

Refreshed means the file is rewritten from the source; because writes are deterministic, an unchanged resource produces no git diff. Preserved means the file is not touched at all.

Determinism

Re-running a pull with no instance changes produces byte-identical files and a clean working tree, so git diff after a pull shows exactly what changed on the instance and nothing else: no timestamps, no reordering noise.

Scoped pulls are just as predictable: a scoped or resource-selected pull refreshes only its subset and preserves every other committed file. Scope limits what a pull may replace; it never deletes the rest of your snapshot.

Pull before you push

Next step

With files committed, preview what they would change on a target: Diffing & Pushing.