To roll back a go-to-market change deployed with Cargo, revert its commit in git and deploy the revert: git revert <sha>, then merge the revert’s pull request on a connected repository, or run cargo-ai project deploy. The deploy re-applies the previous definitions because the workspace is reconciled to whatever the code says. cargo-ai project rollback is a different tool: it restores the deploy state record, not your live plays and agents.
Revert and deploy #
git checkout -b revert-tier-1-change
git revert <sha> # a new commit that undoes the change
git push -u origin revert-tier-1-change
gh pr create --fill # the plan comment shows the diff going back
On a repository connected to Cargo, merging that pull request deploys it. Without a connection, run the same plan and deploy yourself:
cargo-ai project plan # the diff going back to the previous definitions
cargo-ai project deploy
The revert is reviewed like any other change, and git keeps both the change and its undo, so the history says what ran when.
Stop a play first, if it is sending #
A revert takes as long as a review. If a play is enrolling the wrong records right now, ship the smallest change that stops it:
export const expansion = definePlay("expansion", {
model: contacts,
// …
isEnabled: false, // the deploy disables the play and keeps it disabled
});
With isEnabled set, the deploy keeps the play’s switch reconciled to the code. Left out, the switch is manual and a toggle in the Cargo UI survives deploys, which is also a valid emergency stop.
What a revert does not remove #
A deploy never deletes. If the change you are reverting added a resource, the revert removes it from code but the live play, tool or agent stays: the plan lists it as Prune. Remove it deliberately:
cargo-ai project deploy --prune # delete everything dropped from code
cargo-ai project destroy --target play:welcome # or one resource
On a connected repository with Deploy on push on, Cargo refuses deploys from anyone but the connection’s service user, --prune included. Turn Deploy on push off in Settings → States to run it, then turn it back on.
What no rollback undoes #
- Emails, LinkedIn actions and messages already sent. Reverting a play stops future enrollments; it does not recall what went out.
- One-off executions. A batch or run declared in code that started stays in the ledger. Reverting the file does not run it backwards, and it will not run again.
- Records written by a play. Field updates to your CRM are data, not resources. Undoing them is a new batch or run that writes the old values back.
That is why the preview on the pull request matters more than the rollback: it counts the sends before they exist.
When to use cargo-ai project rollback #
cargo-ai project rollback # asks for confirmation; --yes skips it
cargo-ai project deploy --refresh # then reconcile live resources
rollback restores this project’s deploy state from the snapshot taken before the last deploy, destroy or import, and keeps the executions ledger. Live resources are untouched. It is for a deploy state that went wrong (a bad import, a deploy that recorded the wrong resources), not for undoing a change in what your plays do. The follow-up deploy --refresh re-reads the live workspace and applies your code over anything that differs, so check out the code you want before running it. rollback takes the same state lock as a deploy; --force steals a lock you believe is stale.
Check for drift before you trust the revert #
If someone edited a resource in the Cargo UI since the last deploy, a plain deploy will not notice. See it first:
cargo-ai project refresh # reports each resource as unchanged, modified or deleted externally
cargo-ai project deploy --refresh then applies code over the drift. A resource deleted in the UI is not silently recreated: the deploy stops and asks for --recreate-deleted.
Full reference: Deploying in the Cargo docs. The whole lifecycle: GTM as code: the complete guide.