Revertix is a staging, rollback and backup plugin for WordPress. The free plugin makes a staging copy of your site, and the PRO add-on compares that copy against live, pushes selected changes back, rolls plugins and themes to earlier versions, and runs scheduled backups.
I tested it over about three weeks: every feature, on a clean install, with a licence covering the full Agency tier. This review covers what it does well, where the limits are, two bugs I found and reported, and who the plugin suits.
Short version: recommended for the staging-and-push loop on a single host, with two caveats about what it is not, and one piece of housekeeping if you have been running it since before version 1.0.2.
What it actually is
Revertix is a staging and rollback tool for a single WordPress install. The free plugin creates
a staging copy inside your existing site, at yoursite.com/staging/. The PRO add-on compares
that copy against live, pushes selected changes back, rolls plugins and themes to earlier
versions, and runs scheduled backups.
The word "sync" made me expect something it is not. Revertix does not connect two independent WordPress installations. There is no field for a remote host, an API key or credentials for a foreign site. The other side of every comparison is a staging copy Revertix itself made, picked by slug from its own registry.
So if your staging lives at one host and production at another, this is not your tool. Reach for WP Migrate or WP Staging Pro. What Revertix does is the loop where you make a staging site next to production, work on it, and push the result back.
That is a narrower promise than the marketing implies, and it is worth knowing before you pay.
What is genuinely good
The rollback is the best part, which is fitting for a plugin named after it. I took Akismet from 5.7 down to 5.6. Three seconds, including an automatic snapshot of 5.7 taken before the switch. The confirmation dialog told me the truth in advance: a snapshot gets taken first, and the site may briefly enter maintenance mode. No surprises, no manual cleanup afterwards.
Premium plugins get handled properly, and this is where most rollback tools go quiet. Point Revertix at something not on WordPress.org and instead of an empty version list you get a "Premium / custom" label, a sentence explaining why there is no public history, and a button to snapshot the current version so you have something to return to. It also snapshots premium items automatically once a day when their version changes.
The safety backup before a push is real. I checked the archive: 4,048 files, 88 MB uncompressed. I killed one backup job halfway through archiving and the resulting zip was still complete. One caveat on that, from a bug I did not find myself, at the end of this review.
The database footprint is the thing I did not expect. Revertix creates no tables of its own. Its
options total a few hundred bytes and every single one has autoload=off. I measured TTFB with
the plugin on and off across twelve samples each, and the difference disappears into the noise.
Plenty of plugins with a fraction of this feature set are heavier.
Scheduled backups deserve a note. Six frequencies, a chosen hour, retention, and a per-area scope selector. More usefully, it is the only job in the plugin that finishes on its own. Every task you click in the interface is driven by polling from the open admin tab, so closing the tab strands the job mid-flight. I learned that by stranding one. The cron path has no such problem.
Staging access control is layered properly: a login wall, blog_public = 0, a
noindex, nofollow, noarchive tag that stays on even if you disable the wall, plus per-user and
per-role allow lists. There is also a configurable admin bar colour on staging copies, which
sounds trivial until you remember how people edit production by accident.
The two bugs I found in 1.0.0
Neither threw an error. In two days of testing I never saw a fatal, a white screen or a stack
trace. WordPress never even created debug.log. That is the part worth sitting with, because a
crash at least tells you something went wrong.
The staging site could boot against the live database. The wizard completed, the panel
reported Table prefix: wp_stgstaging_, the tables really were cloned. But the prefix swap in
the generated wp-config.php was done with a regular expression that only matched a quoted
literal. My config declares the prefix through a function call, the pattern missed, and nothing
checked whether the substitution had happened. The staging install came up pointing at
production.
I proved it rather than inferring it. I wrote a marker into the staging tables only, then
requested a file served by the staging directory. It returned the live site's title. I changed
one line in wp-config.php by hand and the same URL returned the staging marker.
The panel promises that nothing you do on staging touches the live site. In that state you got a second front end wired into production, and every test you ran there wrote to it.
The file comparison saw nothing on the staging side. I planted differences in five places so every bucket had something to show. The scan came back with one bucket: 4,045 files to remove from live. Zero modified, zero staging-only. That bucket was the entire installation.
An actual push confirmed the consequence: files: 0. The database moved across correctly, and a
post that existed only on live survived, so row merging is additive and sane. Not one file moved.
The feature sold as "file by file, line by line" synchronised only the database, and reported
success while doing it.
There was a third, smaller one. The licence server returned expires_at as 2027, four digits,
and the plugin read it as a Unix timestamp. As a timestamp, 2027 is January 1970, so
is_expired() returned true the moment you activated.
I got that one half wrong in my own notes, so I will correct myself here. I wrote that it did not
block updates, because I checked WordPress's update_plugins transient and Revertix was absent
from it whatever the licence date said. Revertix does not use WordPress.org. It has its own
update endpoint, and the code that feeds results into WordPress returns early when
is_expired() is true. It did block updates, for every customer, and I had tested through the
wrong door.
Reporting them, and what came back
I sent the report on 9 August: two blocking bugs, one moderate, reproduction steps, line numbers, and an offer to retest. Version 1.0.1 shipped on 10 August with the staging database bug fixed. The file comparison lives in the PRO add-on and took longer, arriving on 21 August alongside 1.0.2 of the free plugin.
The fixes are not patches over the symptom. The prefix swap now verifies its own result, and where it cannot guarantee the separation the job stops with a clear message instead of building a staging site that lies to you. The expiry parser handles a timestamp, a bare year and an ISO date string, and migrates values written by the old version on read. The licence server was changed too, so it now sends a full date instead of four digits. Both ends, not just the cheap one.
He also acted on two things I mentioned in passing and never filed as bugs. Backups, packages
and the log now carry names nobody can guess, and every Revertix folder ships its own protection
files instead of trusting the parent. On nginx, where .htaccess is ignored, the plugin now
tells you outright that your backup folder is exposed and hands you the rule to add. That was a
remark at the bottom of my report and it came back as a feature.
The changelog also describes the staging bug in the author's own words, which is a thing worth noticing on its own. Plenty of vendors would have written "improved staging reliability".
I retested on the same install, with the same wp-config.php that defeated the original regex.
Fresh staging site: correct prefix, reads its own tables. Changeset: two modified, one
live-only, one staging-only, each planted file in the right bucket. Push: three files moved,
verified on disk.
Buying a plugin is partly a bet on the person behind it, and this is the part of the test you cannot run yourself before you pay. A fix at the root the day after the report, the second blocker eleven days later, and two unfiled remarks picked up along the way. Worth knowing.
If you already run it, redo your backups
This one is not mine. I found it in the 1.0.2 changelog while checking dates, and it matters enough that I am not going to bury it.
Before 1.0.2, every % character in your content was mangled inside exported databases and
backups. Percent-encoded values took the worst of it: any slug generated from a non-Latin title,
any encoded URL, growing to several times its length. An import could fail outright. The author's
own instruction is to take a fresh export or backup, because anything made before that version
carries the damage.
So the archive I praised earlier was structurally sound, and I verified that it was, but I was verifying the wrong property. A zip can be complete and still hold corrupted rows. If you have been running Revertix and have backups from before 1.0.2 sitting on a disk somewhere, they are not the safety net you think they are. Take fresh ones. The same changelog says staging sites created before the fix should be deleted and re-created, which is the other half of the same housekeeping.
Two things about that. It is a real hit, and anyone weighing this plugin should know before they buy. It is also exactly what a changelog is for, written plainly enough that a non-technical reader can act on it. I would rather have a vendor who tells me my old backups are damaged than one who quietly fixes it and hopes nobody looks.
The verdict
Recommended, without the caveat I was expecting to write.
If you run the staging-and-push loop on one host, this does the job, and the parts around the edges are better than the category average. The confirmation dialogs tell you what is about to happen. The autoload discipline suggests someone who has cleaned up after other people's plugins. The rollback handles the premium case that most tools ignore.
Three things still deserve a sentence. It is not a two-server migration tool, whatever "sync" suggests. Interactive jobs need the admin tab left open, so start a big push and go and do something else in another window. And if you were running it before 1.0.2, do the housekeeping in the section above before you trust anything you backed up.
Pricing
Lite is $9 once for eleven modules on unlimited sites. PRO runs $79 a year for one site, $199 a year unlimited, or $499 once. For an agency running the staging-and-push loop across client sites, the unlimited annual tier is the one that makes arithmetic sense.
Plans and the current prices are on the vendor's page: Revertix on nitramix.com. The free plugin is on WordPress.org if you want to try the staging side before paying for the PRO add-on.
What I did not test
Pull in the other direction, importing a package into a separate install, and the end-to-end
update flow from inside wp-admin. I also could not tell you how many real hosting setups the
original prefix bug would have hit. My wp-config.php declares the prefix through a function
call, which is what exposed it, and I did not survey what other hosts generate.
Disclosure
Nobody asked for this review and nobody saw it before publication. I sent the author a full bug report with reproduction steps and line numbers before writing it, and I offered to retest the fixes on the same environment. He shipped them, I retested, and this post says so.