While writing the comparison pages for ManageWP, MainWP, WP Umbrella, and InfiniteWP on our LP, I tried to line up the four products under a single "connection method" column — and got stuck. The same ManageWP gets called a "Hosted SaaS tool" in one source, a "Worker plugin tool" in another, and a "self-hosted" tool in yet another.
On closer look, these labels are mixing two distinct axes into one column. Once you separate them, the four products fit cleanly into a two-axis, six-cell grid. This post lays out that grid and walks through what each cell means for day-to-day operations.
Axis 1 — What gets installed on the client site
The first axis asks what the maintenance tool installs on the WordPress sites it manages. There are two answers.
- A. Worker / Child plugin: Each managed site gets a dedicated plugin from the maintenance tool. ManageWP Worker, MainWP Child, WP Umbrella, InfiniteWP Client — the names differ, but they all play the same role: a "gateway plugin" that exposes a REST/HTTP endpoint the dashboard talks to.
- B. Direct SSH + WP-CLI: Nothing gets installed on the site. The tool logs in via SSH and invokes WP-CLI directly on the server.
The difference shows up as how invasive the tool is on the client side. The plugin route carries the cost of "a vulnerability in the gateway plugin cascades to every managed site" and "you owe the client an explanation for the extra plugin." The SSH route carries the constraint of "hosts that disallow SSH are out of reach" and "operators need basic SSH literacy."
Axis 2 — Where the dashboard lives
The second axis asks where the dashboard itself runs. There are three answers.
- ① Hosted SaaS: The dashboard runs on infrastructure operated by the vendor. Site credentials live in their cloud — a trust model where the vendor holds your secrets.
- ② Self-hosted: You stand up your own WordPress site or server and install the dashboard there. The data stays in your control, but you also inherit the operational burden of maintaining that dashboard platform itself.
- ③ Desktop app: The dashboard runs on your local PC. Data stays local — no cloud component, no server to operate.
Axis 2 determines where the data lives and where the responsibility line is drawn. Who holds the credentials? Who is on the hook when something goes wrong? That cell choice shapes the risk structure your team takes on.
The two axes overlaid — a six-cell grid
| Dashboard ↓ / Connection → | Worker / Child plugin | Direct SSH + WP-CLI |
|---|---|---|
| ① Hosted SaaS | ManageWP, WP Umbrella | (industry gap) |
| ② Self-hosted | MainWP, InfiniteWP | (industry gap) |
| ③ Desktop app | (industry gap) | WP Maintenance Manager |
The four major products cluster in the top two cells of the "plugin" column. The "SSH" column is almost entirely blank. Let's walk through the three occupied cells first.
Cell 1 — Hosted SaaS × plugin (ManageWP, WP Umbrella)
The industry's most classic configuration: browser access from anywhere, the vendor handles infrastructure updates and redundancy, and uptime monitoring fits naturally. WP Umbrella's EU-based hosting, which leans on data-residency as a selling point, is a story this cell makes possible.
The trade-off is that client credentials get handed to a third-party cloud. A breach at the vendor cascades to every managed site, and your operations are tied to the vendor's business continuity. Pricing tends to layer "per-site × add-on" charges on top of the monthly base.
Cell 2 — Self-hosted × plugin (MainWP, InfiniteWP)
For teams that don't want credentials in a third-party cloud but still want the compatibility of plugin-based connections. Full data ownership and affinity with one-time-purchase and annual-license models are the upsides.
The trade-off is that the burden of maintaining the dashboard platform falls on you. MainWP requires you to keep updating and securing the very WordPress site that runs the dashboard; InfiniteWP's panel server needs the same kind of care. A meta-recursion of "you maintain the tool that maintains your tools" is built into this cell. If the dashboard platform is compromised, the credentials for every connected site can leak from one place.
Cell 3 — Desktop × SSH (WP Maintenance Manager)
The dashboard runs as a desktop app on your PC, and the tool connects to sites directly over SSH. Three properties stand out: data lives only on the local PC, no infrastructure to operate, and nothing installed on client sites. The cascading-vulnerability risk of a gateway plugin structurally doesn't exist.
The trade-off is that continuous uptime monitoring isn't a natural fit — when the PC is asleep, the monitoring loop isn't running. Hosts that disallow SSH also fall outside the supported set, so the hosting coverage is narrower than the other cells.
Why the three empty cells stay empty
The remaining cells have essentially no products. There are structural reasons.
- Hosted SaaS × SSH struggles because handing SSH private keys to a cloud vendor is a trust model the market resists. Plugin-based connections keep credentials on the site side; storing and using SSH keys inside a third-party cloud raises the audit bar significantly.
- Self-hosted × SSH is technically possible, but layers two costs at once: running your own dashboard platform and absorbing the SSH connectivity constraints. Teams that opt into self-hosting rarely want to give up plugin-route compatibility on top of that.
- Desktop × plugin fights a fundamental mismatch: some gateway plugins assume continuous push communication to the dashboard, which doesn't reconcile with a desktop app that only runs when the user's PC is on.
Closing — how to choose a cell
Cell selection is a trade-off between acceptable costs and where the responsibility line sits. Three questions tend to do most of the work during evaluation.
- Credentials in a third-party cloud, or kept locally? (Axis 2)
- A maintenance plugin on every client site, or none? (Axis 1)
- Operating an infrastructure tier yourself, or not? (Axis 2, only the self-hosted row adds this)
The industry has consolidated into "Hosted SaaS × plugin" and "Self-hosted × plugin" largely for historical reasons — SSH-route constraints (host coverage and the SSH knowledge requirement on operators) made industry-wide adoption hard. Choosing the SSH column structurally avoids the client-side invasiveness and gateway-plugin cascade risk that the plugin column carries.
There's no single "correct" architecture. Operating style, client contracts, and data-handling requirements all shift the right cell. Carrying this six-cell map in your head makes it easier to ask the right comparison questions when picking a maintenance tool — and to see which trade-offs actually matter for your own operations.
