How does the safety pipeline work?

Every mutating action runs the same sequence. The runner first exports the site database as a backup; only if that succeeds does it apply the update. It then runs an interior health check, and if the site comes back unhealthy or the step throws, it rolls back to the backup. A backup that fails halts the action before anything changes.

What decides whether a human has to approve?

A classifier runs in priority order. Backups always auto-run because they are non-destructive. Anything touching a site flagged sensitive requires approval, as does a WordPress core major-version jump or a plugin or theme major-version jump. Routine patch and minor updates run automatically. Held actions wait in a queue for one-click approval.

How is the fleet tracked?

A scheduled sync enumerates every site and records its core version, plugins, themes, available updates, and known vulnerabilities to a DynamoDB inventory. A separate health monitor probes each site on a short interval, uses a dwell gate to suppress false alarms from firewall challenges, and alerts over email and Slack when a site status actually changes.

What can the runner do, and what is still manual?

The runner supports backups, core updates, plugin updates, theme updates, and a targeted plugin-alignment action, all validated against strict input patterns. Phase one — scheduled inventory sync, health monitoring with alerting, and the approval-gated runner — is live in production. Triggering updates directly from the dashboard is the next phase; today the dashboard is read-only.

WordPress Fleet Ops

Safe, audited WordPress updates across ~60 managed sites: tiered approval, backup-first, auto-rollback.

Abstract

WordPress Fleet Ops is iSimplifyMe's internal control plane for keeping a fleet of roughly sixty client WordPress sites patched without breaking them. An on-demand Lambda action runner reaches each site over SSH and executes every change through a fixed safety sequence, behind a tiered-approval gate that escalates the risky cases to a human and auto-runs the rest.

Problem

A WordPress site left unpatched is a security liability; a botched update is an outage. Doing this by hand across dozens of live client sites does not scale, and blind automation is worse — a bad plugin update can white-screen a site or corrupt a database. The job needs automation that is safe by construction and auditable after the fact.

Approach

Inventory sync

A scheduled job enumerates every site on the managed hosting box and records its core version, plugins, themes, available updates, and known vulnerabilities into a DynamoDB inventory keyed per site.

Health monitoring

A second scheduled job probes each site's homepage on a short interval. A dwell gate suppresses false alarms from firewall challenges and transient blips, and status changes alert over email and Slack rather than flapping.

Tiered approval

Before any change runs, a classifier decides whether it can auto-run. Backups always auto-run. Sensitive sites, WordPress core major-version jumps, and plugin or theme major-version jumps are held for one-click human approval. Routine patches run automatically.

Safety pipeline

Every mutating action follows the same path: back up the database, apply the update, run an interior health check, and roll back automatically if the site fails or the check throws. A failed backup halts the action before anything changes. Each step appends to an immutable audit log.

Status

Phase one live in production: scheduled inventory sync, health monitoring with alerting, and the approval-gated action runner.
Supported actions: backup, core update, plugin update, theme update, and targeted plugin alignment — all validated against strict input patterns.
Read-only admin dashboard surfaces inventory, versions, vulnerabilities, and health per site.
Phase two — triggering updates directly from the dashboard and an in-UI action-log view — in design.

WordPress Fleet Ops

What is WordPress Fleet Ops?