\n
\n 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 \u2014 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.<\/p>\n
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.<\/p>\n
Axis 1 \u2014 What gets installed on the client site<\/p>\n
The first axis asks what the maintenance tool installs on the WordPress sites it manages. There are two answers.<\/p>\n
A. Worker \/ Child plugin: Each managed site gets a dedicated plugin from the maintenance tool. ManageWP Worker, MainWP Child, WP Umbrella, InfiniteWP Client \u2014 the names differ, but they all play the same role: a “gateway plugin” that exposes a REST\/HTTP endpoint the dashboard talks to.<\/p>\n
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.<\/p>\n
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.”<\/p>\n
Axis 2 \u2014 Where the dashboard lives<\/p>\n
The second axis asks where the dashboard itself runs. There are three answers.<\/p>\n
\u2460 Hosted SaaS: The dashboard runs on infrastructure operated by the vendor. Site credentials live in their cloud \u2014 a trust model where the vendor holds your secrets.<\/p>\n
\u2461 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.<\/p>\n
\u2462 Desktop app: The dashboard runs on your local PC. Data stays local \u2014 no cloud component, no server to operate.<\/p>\n
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.<\/p>\n
The two axes overlaid \u2014 a six-cell grid<\/p>\n
Dashboard \u2193 \/ Connection \u2192
\nWorker \/ Child plugin
\nDirect SSH + WP-CLI<\/p>\n
\u2460 Hosted SaaS
\nManageWP, WP Umbrella
\n(industry gap)<\/p>\n
\u2461 Self-hosted
\nMainWP, InfiniteWP
\n(industry gap)<\/p>\n
\u2462 Desktop app
\n(industry gap)
\nWP Maintenance Manager<\/p>\n
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.<\/p>\n
Cell 1 \u2014 Hosted SaaS \u00d7 plugin (ManageWP, WP Umbrella)<\/p>\n
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.<\/p>\n
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 \u00d7 add-on” charges on top of the monthly base.<\/p>\n
Cell 2 \u2014 Self-hosted \u00d7 plugin (MainWP, InfiniteWP)<\/p>\n
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.<\/p>\n
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.<\/p>\n
Cell 3 \u2014 Desktop \u00d7 SSH (WP Maintenance Manager)<\/p>\n
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.<\/p>\n
The trade-off is that continuous uptime monitoring isn’t a natural fit \u2014 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.<\/p>\n
Why the three empty cells stay empty<\/p>\n
The remaining cells have essentially no products. There are structural reasons.<\/p>\n
Hosted SaaS \u00d7 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.<\/p>\n
Self-hosted \u00d7 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.<\/p>\n
Desktop \u00d7 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.<\/p>\n
Closing \u2014 how to choose a cell<\/p>\n
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.<\/p>\n
Credentials in a third-party cloud, or kept locally? (Axis 2)<\/p>\n
A maintenance plugin on every client site, or none? (Axis 1)<\/p>\n
Operating an infrastructure tier yourself, or not? (Axis 2, only the self-hosted row adds this)<\/p>\n
The industry has consolidated into “Hosted SaaS \u00d7 plugin” and “Self-hosted \u00d7 plugin” largely for historical reasons \u2014 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.<\/p>\n
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 \u2014 and to see which trade-offs actually matter for your own operations.<\/p>\n