Rollback and Snapshots

Every real push (not a --dry-run) saves a snapshot of the environment’s state right before it writes anything. rollback restores that state.

lps snippet rollback            # undo the most recent snippet push
lps snippet rollback --list     # list the available snapshots
lps snippet rollback --to 1732000000000
lps snippet rollback --dry-run  # show what would be restored

Which resources support it

Resource	Command
Snippets	lps snippet rollback
ACF	lps acf rollback
Forms	lps form rollback
Menus	lps menu rollback
Custom Post Types	lps cpt rollback
Taxonomies	lps taxonomy rollback
Post Meta	lps meta rollback
Roles	lps role rollback
Options	lps option rollback
Theme Styles	lps theme style rollback
API routes	lps api rollback
Hooks	lps hook rollback
Block Patterns	lps pattern rollback

Plugins, themes, Composer, static pages, templates and apps have no rollback: to go back, check out the previous version of your files in Git and push again. For plugins, keep in mind that a downgrade replaces files only, it does not undo database migrations.

Flags

Flag	Description
--list	List the available snapshots (id, timestamp, environment) instead of rolling back
--to <id>	Restore this snapshot instead of the most recent one
--dry-run / -d	Show what would be restored without changing anything
--yes / -y	Roll back even if the environment changed since that push
--env <name>	Roll back this environment instead of the active one

Where snapshots live

Snapshots are written on the machine that ran the push, in .loopress/snapshots/<resource>/<environment>/ at the root of your project. The next push also reads the latest one to detect changes made outside Loopress since then (static pages keep snapshots for that reason, without a rollback command). The CLI keeps the last 10 per resource and environment, pruning the oldest. The .loopress/ directory ignores itself in Git, so snapshots are never committed.

A push run in CI therefore saves its snapshot on the runner, where it disappears with the job. To undo a CI deploy, revert the commit and let the pipeline push again.

How a rollback is applied

1. Drift check. The CLI reads the environment and compares it with the state right after the push that saved the snapshot. If something changed since (an edit in wp-admin, another push), it shows the difference and asks before overwriting it. In CI, pass --yes to roll back anyway.
2. Targeted restore. Only the objects that differ from the snapshot are written back, the rest is left alone.
3. No deletion. An object that exists now but not in the snapshot (created after it) is not removed. The CLI warns about it, delete it yourself if needed.

Your local files are not changed by a rollback. Run the resource’s pull afterwards to bring them back in line with the site.

From an AI agent

Each rollback is also an MCP tool (snippet_rollback, acf_rollback, …), behind the same two-step confirmation as every mutating tool. Like every mutating tool, it refuses an environment named production, including when production is the default environment, and the confirmed call rolls back the environment that was previewed. See Confirming changes.