Client sites that survive update day.

Before. During. After.

Every update is a protected update.

One site. One update. A way back.

1. 01

   Inventory

   Update available

   Match installed plugins, themes, and core against known vulnerabilities.

2. 02

   Protect

   Ready to update

   Create a checkpoint of files and database together before changing the site.

3. 03

   Update

   Updating

   Apply the update with the recovery point kept available.

4. 04

   Verify

   Healthy

   Check site health after the update.

If health fails↗

If the health check fails, review the result and choose whether to restore.

Restoring returns files and database to the checkpoint. Changes made since that point can be lost.

Illustrative sequence. A successful local checkpoint is shown before the update; it is not an off-server backup.

Getting sites in

• An archive. A .wpress file, a Duplicator package, or a plain zip plus SQL dump — whatever the previous host gave you.

• A live pull. Point strackt at the running site and it migrates over a signed channel, with nothing to install on the source host, while the site stays up. (Live pull is in alpha today.)

• Fresh. A clean WordPress install, managed from day one.

For the whole fleet

Coordinate updates across client sites. Each keeps its own database and restore history.

• Run a fleet update round from one place. A failure on one site stays with that site.

• Use WP-CLI for site-specific tasks, such as listing plugins with available updates.