Appwrite CLI push pruning of server-side resources removed from local manifest

Question

Schema-as-code drift reconciliationAppwrite CLI push applies a local appwrite.json manifest to a target project, enabling schema-as-code across development, staging, and production instances. Teams adopting this workflow need predictable reconciliation when the manifest no longer declares collections, attributes, or indexes that still exist on the server.The CLI's push command has historically been additive, and deletion handling has shifted across releases without a single documented default that covers all resource types. Some versions require explicit flags to prune drifted attributes or collections, while others may preserve them silently. This version-dependent behavior makes it difficult to codify a team-wide policy on whether drift should be automatically removed or preserved for manual review. The manifest itself does not express intent for deletion, and the CLI does not surface a dry-run summary of destructive changes before they are applied.Which CLI version introduced explicit pruning flags for collections versus attributes, and are those flags idempotent across push operations?Does push emit a structured diff or warning when server-side resources have no corresponding manifest entry, or must teams implement their own drift detection?Can a project enforce a "manifest as source of truth" policy without scripting custom pre-push validation?

Tasadduq Burney · Answer

Direct answersPruning flags introduced: Explicit --delete-collections and --delete-attributes flags appeared in CLI v5.x (mid-2023). They are not idempotent across runs—re-running push with the same manifest can produce different server state if the manifest changed between runs.Drift detection: push emits no structured diff, JSON summary, or warning for resources that exist on the server but are absent from appwrite.json. Teams must implement their own drift detection (e.g., appwrite list collections vs. manifest parse)."Manifest as source of truth" enforcement: No single CLI flag enforces this policy. A pre-push script that compares the manifest to the live project and aborts on drift is the only reliable gate today.What the CLI actually doesThe push command is additive by default. When you run appwrite push:Collections, attributes, and indexes present in the manifest are created or updated on the server.Resources that exist on the server but are not in the manifest are left untouched unless you pass the corresponding delete flag.Delete flags operate per resource type: --delete-collections removes collections missing from the manifest; --delete-attributes removes attributes missing from their collection definition. Indexes have no dedicated flag—they follow attribute deletion.Because the manifest contains no deletion intent, the CLI cannot distinguish "remove this collection" from "I haven't added it yet." This is why the flags are opt-in and why their effect depends on the manifest state at the moment of each push.Verification steps for your versionRun appwrite push --help and confirm which --delete-* flags are listed.In a sandbox project, create a collection via the console, omit it from appwrite.json, then run appwrite push --delete-collections. Observe whether the collection is removed.Repeat with an attribute-level drift to test --delete-attributes.One diagnostic detail neededWhat exact CLI version (appwrite --version) are you standardizing on? The flag set and idempotency behavior shifted between v5.0, v5.1, and v6.0 releases, so the recommendation for a team-wide policy depends on that version pin.

Appwrite CLI push pruning of server-side resources removed from local manifest

Schema-as-code drift reconciliation

1 answer

Direct answers

What the CLI actually does

Verification steps for your version

One diagnostic detail needed

Your perspective belongs here.

0 question comments