Zignites Sentinel
Create a checkpoint of your active theme and plugins before updating, validate that the checkpoint is sound, and restore it if an update breaks the code layer.
Why it exists
Updating plugins on a production site is a small gamble taken repeatedly. Most updates are fine. Occasionally one takes the site down, and the recovery options are all worse than they should be: restore a full backup and lose whatever happened in the database since, or start manually reinstalling old versions over FTP while the site is down.
Full backup plugins solve disaster recovery. They are not built for the specific, frequent, narrow operation of “I am about to update six plugins and I want a way back if one of them breaks the code layer.” Sentinel is built for exactly that operation and nothing else.
What Sentinel does not restore
It restores the active theme and the active plugins. It does not restore your database, your uploads or media, WordPress core, or WooCommerce order and payment state, and it does not detect or clean malware. If a plugin update broke a template, Sentinel is the right tool. If an update corrupted data, orders were placed during the outage, or the site is infected, you need a database-aware backup tool or a security cleanup tool.
What it does
How it works
The workflow is four steps: create a checkpoint before you update, validate it, restore it if an update breaks the code layer, and roll back the restore if the restore itself was wrong. Validation is the step most tools skip, and a checkpoint you have not verified is a checkpoint you are guessing about — finding out it was incomplete during an outage is the worst possible time.
Checkpoint packages, exports, staging files and restore backups are written under uploads/zignites-sentinel/. Because that path sits inside a publicly served directory on most hosts, Sentinel writes index.php guards, .htaccess deny rules for Apache and web.config deny rules for IIS.
It also does something unusual and worth calling out: the Dashboard runs an artifact exposure probe. It writes a temporary token file and tries to fetch it, then reports whether the artifact path appears blocked, publicly readable or inconclusive. Inconclusive results need checking at the host, Nginx, CDN or object storage layer. Most plugins that write to uploads simply assume their deny rules worked. This one checks and tells you when it cannot be sure.
Treat the artifacts as sensitive. A checkpoint contains your plugin and theme source, which can include configuration files, licence keys and API tokens.
Two reliability controls are built in. A shared operation lock covers checkpoint, package, staging, restore, rollback and cleanup so overlapping heavy operations cannot collide. And before checkpoint or restore work begins, Sentinel estimates the disk space required for packages, staging, live backups and rollback payloads, and blocks the operation if free space is below a safe threshold — rather than filling the disk halfway through a restore. Cleanup runs on a scheduled maintenance task and preserves active resume checkpoints.
Requirements and limits
- A writable uploads/ directory, since checkpoint artifacts are stored under uploads/zignites-sentinel/
- Enough free disk space for a package, a staging copy and a rollback payload — Sentinel estimates this and blocks the operation rather than filling the disk
- WP-Cron or a system cron for scheduled retention cleanup
- Licensed GPLv2 or later
What it does not do
The scope limits are firm: theme and plugins only. No database, no uploads, no WordPress core, no WooCommerce order state, no malware handling. Sentinel does not claim atomic restore behaviour, so a restore is a sequence of operations rather than a single transaction.
One environment caveat deserves attention. The .htaccess and web.config deny rules protect artifacts on Apache and IIS. They do nothing on Nginx, and they can be bypassed by a CDN or object storage layer serving uploads directly.
That is exactly why the exposure probe exists — if it reports inconclusive or publicly readable, resolve it at the server level before relying on the plugin in production, because checkpoint packages can contain licence keys and API tokens from your plugin configuration.
How it fits alongside a backup plugin
Sentinel is not a replacement for your backup tool, and the two are answering different questions.
A backup answers “how do I get the whole site back to how it was on Tuesday.” It is the right tool after data loss, a compromise, or a failure whose cause you do not yet understand. It is also a heavy operation: you restore everything, including database rows written since the backup, which on a site taking orders or comments means losing real activity.
Sentinel answers a narrower question: “an update I just ran broke the code, how do I undo exactly that.” Because it only touches the active theme and plugins, restoring does not roll your database back, so nothing that happened since the checkpoint is lost. Orders placed five minutes ago are still there. That is precisely why it is limited to the code layer — the limitation is what makes it safe to use on a live site mid-afternoon.
In practice the sequence is: nightly backups running as usual, and a Sentinel checkpoint taken immediately before any batch of plugin or theme updates. If an update breaks a template or throws a fatal, restore the checkpoint and you are back in a minute with no data loss. If something worse has happened — the database is wrong, orders are corrupted, the site is infected — that is the backup's job, and Sentinel will not pretend otherwise.
The validation step is worth taking seriously rather than clicking past. A checkpoint that was never verified is an assumption, and outages are a bad moment to discover a bad assumption. Validating takes seconds and is the difference between having a rollback path and believing you have one.
Who it is for
A good fit if you manage risky plugin or theme updates regularly, need a rollback path for the active code layer, and already understand that database and media recovery need a different tool.
A poor fit if you want full-site disaster recovery, expect one-click transactional restore, or your actual problem is backup retention, migration, off-site storage, malware or firewalling.
Frequently asked questions
Is this a backup plugin?
No. It checkpoints the active theme and active plugins for safe updates. Use a full backup tool for site-wide recovery.
Does it restore my database?
No. Code layer only — theme and plugins.
What exactly is in a checkpoint?
The active theme and the active plugins as they stood before the update — the code layer only.
Where are checkpoints stored?
Under uploads/zignites-sentinel/, with index guards and Apache and IIS deny rules, plus an exposure probe that reports whether those rules are actually working on your host.
What if a restore makes things worse?
Roll back the last restore from the Before Update screen. That is also why validation runs before you rely on a checkpoint rather than at the moment you need it.
Can it run out of disk space mid-restore?
It estimates the required space beforehand and blocks the operation if free space is below the safe threshold.
How do I get Zignites Sentinel?
It is not in the WordPress.org directory yet. Contact us and we will send you a packaged build.
Related plugins
Site Extensions Snapshot
View every installed plugin and theme with status, version and author, then export the lot to CSV in one click. Built for audits, compliance checks and client handovers.
View PerformanceTurboBlocks
Disable unused CSS and JavaScript on WooCommerce sites with per-page rules and context-aware detection. Reduce page weight and improve Core Web Vitals without breaking checkout.
View UtilitiesSite Info Scout
Generate a complete WordPress site report covering environment details, active plugins and configuration. Useful for support tickets and audits.
ViewInterested in Zignites Sentinel?
Tell us about your site and we will send you a build or quote the work.