Frequently Asked Questions

The app automatically creates a DB backup before updates and checks the HTTP status after each individual plugin update. If any of the following are detected, the offending plugin is immediately rolled back to its previous version (pinpoint rollback) and the site is re-checked to confirm recovery:
• HTTP 5xx server errors (PHP fatal, database errors, etc.)
• HTTP 4xx regressions (a page that was 200 before becomes 404, 403, 401, etc.)
• Site unreachable (connection failure, timeout, DNS issues)
Sites with "Aggressive Auto-Fix Mode" enabled will additionally restore the DB and files together to their pre-update state if the site remains broken after maintenance completes. The risk of a site staying broken is low, but not zero. Please only use this app if you are able to perform manual recovery if needed.

The app's per-plugin HTTP check detects HTTP 5xx server errors, HTTP 4xx regressions (e.g., 200 → 404), or site unreachable conditions. When any of these is detected, it automatically rolls back the offending plugin to its previous version (pinpoint rollback) and verifies recovery. The same mechanism applies to WordPress core updates. WP-CLI commands run in safe mode (--skip-plugins --skip-themes), so even if the rolled-back plugin is throwing a fatal error, the rollback itself is guaranteed to execute. Sites with "Aggressive Auto-Fix Mode" enabled will additionally restore the DB and files together to the pre-update state as a last resort if the site is still broken. Note that themes are updated in bulk and are therefore not subject to per-theme rollback. Severe database corruption and browser-only (no-SSH) mode may also fall outside the scope of automatic recovery.

When a post-core HTTP check detects an issue, the app first rolls back the core to its previous version. What happens next depends on the rollback outcome — there are two paths:

• Rollback succeeded + recovery verified (the most common case) → The remaining plugin updates proceed normally with per-plugin HTTP checks. The core is back to its previous version, and subsequent plugins are updated with their own pinpoint-rollback safety net.
• Rollback failed, or rollback succeeded but the site still does not return a healthy status → The remaining plugin/theme/language updates are halted and the situation is reported via email. Continuing to update plugins on an already-broken site risks falsely rolling back unrelated plugins, so the app errs on the side of safety and stops.

In the latter case, please verify and repair the core (via the WordPress dashboard or manual SSH as needed) before re-running maintenance. The execution log will explicitly state "Subsequent updates halted after core rollback", and this is reflected in the report and email notification.

For most use cases, leaving this OFF (default) handles the majority of issues. Turning it ON adds a last-resort comprehensive recovery layer that activates only if the site is still broken after the main maintenance run completes.

When to enable it

• You manage multiple client sites as an agency and want reliable unattended recovery during off-hours
• You want the app to resolve HTTP 500 errors as automatically as possible without waiting for human judgment
• SSH is configured for the site (this mode has no effect on browser-only sites)

Important notes

• Automatic theme switching may change the visual appearance: if a theme is identified as the cause, the site is switched to a Twenty series theme. Your client may notice the visual change before you do — review the report email and restore as needed.
• Aggressive by name and by behavior: this mode operates under the assumption that the site is already broken. There is a non-zero risk of unintended restoration when conditions are misjudged.
• Not foolproof: complex errors may not be resolved automatically. Always review the report email after each maintenance run.
• SSH required: this mode does not apply to sites configured without SSH.

A good approach: start with it OFF — the rows under 📦 / 🔧 / 🔍 already cover most failures. Turn it ON only when you encounter complex incidents that those layers couldn't resolve.

Premium plugins and themes that require activation may not be updated automatically. Any plugins that could not be updated will be listed in the report email.

No. Themes are not subject to per-theme rollback. Theme updates run as a single bulk operation (wp theme update --all), so if the site breaks afterwards, there is no way to identify which specific theme caused the failure.

Plugin and WordPress core updates are run one-by-one with an HTTP check between each, which is why pinpoint rollback works for them. Themes can't be handled the same way by design.

What happens when a theme update breaks the site:

• The end-of-maintenance home-page HTTP check detects 500 / 4xx and reports it via email (the cause cannot be attributed specifically to the theme update — the site is flagged as "requires attention")
• For sites with "Aggressive Auto-Fix Mode" enabled, if a fatal log identifies a theme as the cause, the app will attempt to switch to a default WordPress theme (Twenty series)
• Theme files themselves are NOT rolled back automatically — manual intervention is required

Note: theme-related failures are statistically less than 1/10 the frequency of plugin-related failures in production, which is why this is a deliberate priority trade-off.

Yes — reliably. The app runs all WP-CLI commands with --skip-plugins --skip-themes ("safe mode"), which causes WordPress to skip loading plugins and themes during WP-CLI bootstrap entirely.

As a result, even if the just-updated plugin is throwing a fatal error, the WP-CLI process performing the rollback is unaffected and can complete the file replacement (restoring the previous version) reliably.

The actual sequence:

• 1. Plugin X is updated (files replaced)
• 2. HTTP request to the site → fatal → HTTP 500
• 3. The app runs wp plugin install X --version=OLD --force --skip-plugins --skip-themes
• 4. WP-CLI bootstraps without loading the broken plugin → file replacement succeeds
• 5. HTTP request again → site loads with the old plugin version → 200 (recovery verified)

Note: PHP-CLI (command line) and PHP-FPM (web) run as separate processes. Even if the web side is completely down due to a fatal, the SSH-side rollback runs independently.

There is no built-in scheduler. Please trigger maintenance manually when you want it to run.

When this feature is enabled, screenshots of the homepage are automatically taken before and after updates, and the visual difference is detected. If the difference exceeds 8%, it is flagged and reported as an anomaly.
※ Sites with carousels or animated content are likely to produce false positives, so this feature is not recommended for such sites.

Screenshots are saved in the 「screenshots」folder on the PC running the app. They are not stored on the server. After maintenance, you can download files from the "📸 Screenshots" section in the log detail view (click on any site's log entry).
※ Post-maintenance screenshots are automatically saved for all sites. Sites with "Screenshot Comparison" enabled will have two images saved (before and after), with automatic diff detection. Images are retained for 90 days by default.

Backups are saved in two locations: on the server (inside a wpmm_backups/ folder within the WordPress installation directory) and locally on the PC running the app. During maintenance, a backup_YYYYMMDD_HHMMSS.sql file is automatically created and downloaded to your local machine via SSH/SFTP. Only the latest 3 generations are kept both on the server and locally — older files are automatically removed so the disk does not fill up over time.

Note: the retention count (3 generations) is fixed by design and is not user-configurable.

Yes — the wpmm_backups/ folder on the server is protected by two layers of defense, applied automatically.

① .htaccess blocks all requests: On Apache-based hosts (Xserver, Sakura, Heteml, ConoHa WING, and most major shared hosting), the folder includes an .htaccess file that returns 403 Forbidden for everything inside. Even if someone guesses the URL of a SQL file, the server refuses to serve it. The rules are written to work on both Apache 2.2 and 2.4.

② index.php as an Nginx fallback: For Nginx-based hosts that ignore .htaccess, the folder also contains an index.php that returns 403 Forbidden directly via PHP — providing the same protection through a different mechanism.

Both files are generated and maintained by the app automatically. If either is accidentally removed, it will be re-created on the next maintenance run, so the protection cannot silently degrade over time.

There is no technical conflict, but for safety we recommend disabling WordPress's built-in auto-updates and managing all updates through WP Maintenance Manager.

■ Why no conflict
WP Maintenance Manager only processes plugins that currently have updates available. If WP-Cron already auto-updated a plugin, the app simply skips it. No errors, no race condition.

■ Why we recommend disabling WP auto-updates
WordPress's built-in auto-update has none of the safety nets that WP Maintenance Manager provides:
・Database backup before every run
・Post-update HTTP check after each plugin
・Pinpoint rollback to the previous version
・Pre / post screenshot comparison

An auto-update triggered by WP-Cron at 3 AM can break the site silently. By the time someone notices in the morning, the previous version is no longer recorded, and automatic recovery is no longer possible.

■ Important note about excluded plugins
The "Excluded Plugins" setting in WP Maintenance Manager does not control WordPress's built-in auto-updates. To freeze a specific plugin at a particular version, you need to set both:
① Add the plugin to the Excluded Plugins list in WP Maintenance Manager
② Open the WordPress Plugins page and click "Disable auto-updates" for that plugin individually

If you only do one, WP-Cron will eventually override the freeze.

■ Recommended setup
・Default (recommended): Disable auto-updates for all plugins on the WordPress side, and let WP Maintenance Manager handle every update
・Emergency security only: Leave auto-update on for select plugins, with awareness of the risks above

Pressing Stop sends a stop signal to the process. The app will finish processing the current site before stopping, so updates are never interrupted mid-way. Sites that have already been processed remain updated; remaining sites are skipped.
※ After sending the stop signal, it may take a few seconds to tens of seconds before the app actually halts.

The app runs on the following environments:

Item	Windows	Mac
OS	Windows 10 / 11 (64-bit)	macOS 13.5 Ventura or later
CPU	64-bit processor	Intel / Apple Silicon
RAM	4 GB or more recommended
Required	Internet connection, WordPress 5.0 or later

SSH uses a key pair instead of a password. The private key is a file stored on your computer; the public key is registered on the server. Both are required to connect.

How to generate a key on major hosts:

• SiteGround: Site Tools → Devs → SSH Keys Manager → Create → Actions → Private Key → copy & save as a file. Use port 18765.
• Bluehost: Websites → Manage → Files & Access → Shell Access ON → Manage SSH Keys → generate or register a key.
• AWS (Lightsail / EC2): Use the .pem key pair downloaded when you created the instance. No extra steps needed.

For full step-by-step instructions, see the "Before You Start" section in the User Guide.

Enter the file path to where you saved the private key on your computer.

• Mac / Linux: ~/.ssh/your-key.pem
• Windows: C:\Users\YourName\.ssh\your-key.pem

We recommend moving the downloaded key file into your .ssh folder (create it if it doesn't exist), then entering that path.

In most cases, leave it blank. SiteGround, AWS Bitnami images, and most major hosts include WP-CLI by default — leaving this field empty will work automatically.

Only fill this in if you have installed WP-CLI at a custom path, or if the connection test reports "WP-CLI not found." If that happens, see the next FAQ item for a GUI-only fix.

Some shared hosting environments (Bluehost, GoDaddy, ConoHa WING, and similar shared cPanel hosts) don't expose WP-CLI on the non-interactive shell that this app uses, even when WP-CLI is technically installed on the server. No terminal commands are required to fix this — you can drop your own copy of WP-CLI into your home directory using your host's File Manager (browser-based).

Quick overview:

1. Download wp-cli.phar on your computer and rename it to wp
2. Open File Manager in your hosting control panel and create a folder called bin in your home directory
3. Drag and drop the wp file into the bin folder
4. Right-click the file → "Change Permissions" → set to 755
5. Enter /home/(your-username)/bin/wp in the app's "WP-CLI Path" field (e.g. /home/user1234/bin/wp)

Step-by-step instructions with details are in the User Guide under "What is SSH & WP-CLI?" → Bluehost tab → "If the connection test reports 'WP-CLI not found'."

Yes — two complementary systems are available: categories and tags.

• Categories — A single exclusive label per site. Best for organizing by client or project, with a custom color so you can spot each group at a glance in the list.
• Tags — Multiple cross-cutting labels per site (e.g. EC, needs report, contracted year). Useful for attributes that span across categories.

Manage them under ⚙ Settings → "Categories & Tags". Assign them in the site add/edit dialog, and filter the list with the dropdowns above the registered-site table.

The tag filter has both OR (any of the selected) and AND (all selected) modes, and works in combination with the text search.

Yes. Click the "🕒 Logs ›" link in the "Last Run" column of any row in the registered-site list. The log dialog opens scoped to just that site.

Renaming a site keeps its log history intact. Each site has a stable internal identifier, so logs from before and after a rename appear under the same scope.

Click "Show all logs" at the top of the dialog to leave the scoped view. Older logs (recorded before v1.5.8) don't have the internal identifier, so they fall back to site-name matching.

Yes — three flexible options are available:

• Per site: Open the per-site log view via the "Logs ›" link in the registered-site list, then click "Delete this site's logs". Logs for other sites are kept intact.
• Filtered results: Filter by status (Success / Error / etc.) or by period (last 7 / 30 / 90 days), then click "Delete filtered results". Only entries matching the filter are deleted.
• By selection: Tick the checkboxes for individual rows and click "🗑️ Delete Selected". Useful for cleaning up specific entries one-by-one.

In every case, a confirmation dialog shows the **exact number of entries** that will be deleted. "Delete all" only appears when there is no filter at all — kept as the explicit last resort.

A confirmation dialog appears before deletion so your site data stays safe.

• Deleting a category: Choose whether to reset affected sites to "Unassigned" or move them to another category in bulk (the impact count is shown up front).
• Deleting a tag: The tag is automatically removed from every site that uses it. Other tags and any other site setting are untouched.

Site data itself (SSH info, WordPress paths, history, etc.) is never affected by category/tag operations.

Basic operations can be completed just by following the on-screen prompts. However, SSH configuration is required, which involves enabling SSH in your hosting control panel and making WP-CLI available. Major hosting providers like Xserver and Sakura Internet provide detailed setup guides on their side.

For a step-by-step walkthrough from SSH profile setup to your first maintenance run, see the User Guide.

Yes. Without SSH, you can still run maintenance using browser automation (Playwright) mode, which operates through the WordPress admin dashboard. Note that features such as DB backup will not be available in this mode.

No. No plugin installation is required whatsoever. The app operates externally without modifying your WordPress installation.

Yes. Installers are available for both Mac and Windows.

Any server with SSH enabled is supported, regardless of hosting provider. Confirmed working on Xserver, Sakura Internet, ConoHa WING, Heteml, AWS, Vultr, and more. For servers without SSH, browser automation (Playwright) mode is available. (DB backup and some features are not available in this mode.)

The app opens your OS's default browser automatically. There is no in-app browser selection setting.

• 🍎 Mac: Change your default browser in System Settings → Desktop & Dock → Default web browser.
• 🪟 Windows: Change your default browser in Settings → Apps → Default apps → Web browser.

Once the app is running, copy the URL shown in the address bar of the browser that opened automatically and paste it into any other browser to access the same screen.

Yes. The Free plan requires no registration and allows up to 1 site, 3 runs per month — completely free. Try it out before deciding on a paid plan.

Both monthly and annual billing are available. Annual billing saves approximately 20% compared to monthly. You can switch between them at any time.

The license period starts from the moment you enter the license key in the app. Validity is calculated to the end of the month.
Example: Monthly license key entered on March 15 → valid through April 30
※ The period starts from when the key is entered, not when it was purchased.

You can cancel immediately at any time. Cancellation is self-service through the customer portal (the email address used at signup is required). You may also contact us to handle it, but there may be a 1–2 day delay. After cancellation, you can continue using the service until the end of your current billing period.

Payments are processed via Stripe. Credit cards (Visa, Mastercard, JCB, Amex, etc.), Apple Pay, Google Pay, and many other methods are supported through Stripe's global payment infrastructure.

It depends on your plan: Free (1 site), MINI (3 sites), LITE (15 sites), STANDARD (100 sites), BUSINESS (200 sites). For more than 200 sites, please contact us.

Backups are saved to your local PC. You can choose any folder and download them with one click.

Backup files also remain on the server inside a wpmm_backups/ folder within the WordPress installation directory (the folder specified as "WordPress Path" in the site settings), named backup_YYYYMMDD_HHMMSS.sql. You can retrieve them manually via FTP or your hosting control panel's file manager.

Only the latest 3 generations are kept both on the server and locally — older files are automatically removed. The retention count (3 generations) is fixed by design and is not user-configurable. The wpmm_backups/ folder is protected by .htaccess and index.php files to block external access.

Yes. Select sites from the maintenance log screen, preview the report, and download it as a PDF or HTML file (Standard plan and above). Send it to your client as an email attachment. Direct URL sharing is not currently supported.

There are four status types:

• Success All updates and checks completed normally.
• Warning Work completed, but something requires attention — e.g. a pending plugin update, an admin dialog requiring action, or an HTTP check timeout.
• Attention Not an error, but worth noting — e.g. HTTP status returned 4xx (such as 404), or a visual diff was detected. A manual check of the site is recommended.
• Error SSH connection failure, update process error, or HTTP 500+ detected. Prompt investigation is recommended.

The status badge is displayed for 7 days after the last maintenance run. After 7 days, only the date and time are shown and the badge is hidden. Running maintenance again will re-display the badge.

Maintenance log history in the Logs tab is retained for 365 days, after which older records are automatically removed.

Hovering over a status badge should show a quick summary popup, but if no updates were performed or no detail information was recorded, nothing will appear. For full execution details, check the Maintenance Logs tab at the top of the screen.

The settings backup contains only the file path to your SSH private key — the key file itself is not included in the backup. When restoring on a different PC, you will need to:

① Copy your SSH private key file (e.g. ~/.ssh/id_rsa) from the old PC to the new one
② Open the SSH Profile settings in the app and update the "Private Key Path" to the correct path on the new PC (sites reference profiles, so updating the profile applies to all linked sites automatically)

When migrating to a new PC, always copy your SSH private key files manually alongside the settings backup. Sites using password authentication only are not affected.

Preview and sample viewing are free on all plans. Downloading as PDF or HTML requires the Standard plan or above. Use the "View Sample Report" button in the Report Settings modal to see what a finished report looks like before upgrading.

No. The report uses your agency's logo, company name, colors, and contact information. There is no mention of WP Maintenance Manager in the output. It appears as your own branded maintenance report.

Open Report Settings from the main screen. You can set your agency name, address, email, website, logo image, and accent color. These settings are applied to every report you generate.

Each report includes: execution date/time, site name, update details (WordPress core / plugin / theme version changes), status (Success / Warning / Error), HTTP health check result, and optional before/after screenshots. You can also add a custom greeting and per-site notes directly in the preview screen.

Yes. From the maintenance log screen, select only the sites belonging to a specific client and generate a report for that group. You can generate per-client reports as many times as needed. There is no limit on the number of reports.

Yes. In the preview screen, click Edit Text to customize the greeting message and add a per-site note for any site in the report. Changes are reflected immediately in the preview before you download.

Use PDF for formal client delivery — it's professional, consistent, and easy to attach to an email. Use HTML if you want to host, embed, or further customize the report internally. Both formats share the same visual design.

Yes. If screenshot comparison is enabled for a site, before and after images are embedded in the report. You can toggle screenshot inclusion on or off in the preview screen header.

Yes. The preview screen lets you switch between This Month, Last Month, and All Time. You can also manually select specific log entries from the log list to include exactly what you need.

The responsible plugin has been automatically deactivated. If "Aggressive Auto-Fix Mode" is enabled, the DB and files have also been restored to their pre-update state, so your site should be displaying normally. If the mode is OFF, only the plugin was deactivated — please verify the site visually. The plugin that caused the issue is listed in the report email. Check the vendor's release notes or wait for the next version before trying to update it again.

Not necessarily. Common Warning scenarios include: "a plugin update is still pending", "an action dialog appeared in the admin dashboard", or "a visual diff was detected in the screenshot comparison". Check the details section of the report email and manually review the flagged items.

This occurs when using browser automation (Playwright) mode. Common causes: the admin URL has been changed by a security plugin, two-factor authentication is enabled, or the login URL differs from /wp-login.php. Check that the "WordPress Admin URL" in the site settings matches the current login URL.

Yes, but some plugin settings may affect operation.

The update process itself (WP-CLI over SSH) is not affected, so Core, plugin, and theme updates run as usual. However, the post-update "admin login verification" and the "browser automation (Playwright) update mode" will fail when any of the following settings are enabled (a warning like "Admin login not possible" will appear in the log, but SSH update results are unaffected):

① Image CAPTCHA (e.g. Hiragana CAPTCHA) / Fail Once — Automated browser login cannot pass these. If you want the admin-side verification to run as well, please disable these features.
② Login page rename — When registering a site, enter the renamed URL in the "WordPress Admin URL" field. As long as the correct URL is provided, both updates and verification work normally.
③ Login Lock — If your execution IP gets locked out, consider adding it to an IP allowlist on the server side.

* If you operate only with SSH updates (no browser verification), none of the above settings need to be changed.

Please check the following:
① SSH is enabled in your hosting control panel
② The hostname, port number, and username in the site settings have no typos or extra spaces
③ If using SSH key authentication, the key file path is entered correctly

For Xserver, note that the SSH port number is 10022. Your hosting provider likely provides the correct SSH connection details in their documentation.

For a full breakdown of each SSH field, see User Guide STEP 1.

Each site references an SSH profile, so updating a profile automatically applies to all linked sites. If you still encounter errors, check the following:

① Open the edit screen for the affected site and verify the correct SSH profile is selected
② Confirm the WordPress installation path is correct
③ Re-run the "Test Connection" in the SSH Profile manager

After restoring a backup on a new machine, update the private key path in the SSH profile. The change will automatically apply to all linked sites.

The DB backup on the server succeeded, but the transfer to your local PC failed. Common causes are insufficient disk space on your PC or an SSH connection drop mid-transfer.

The backup file remains on the server inside the wpmm_backups/ folder within the WordPress installation directory (the folder set as "WordPress Path" in your site settings), named backup_YYYYMMDD_HHMMSS.sql. Retrieve it manually via FTP or your hosting file manager.

Plugins not registered in the WordPress official repository (wordpress.org) are excluded from automatic updates — this is a WP-CLI limitation. They will be listed under "Pending Updates" in the report email; please update those plugins manually from the WordPress admin dashboard.

First, check your spam folder. If it's not there, verify that the SMTP host, port, and email address in the app's settings are correct.

If you're using Gmail, you need to set up an "App Password". Regular Gmail passwords will fail authentication. Generate an App Password from your Google Account's security settings and enter it in the password field.

For a full breakdown of the notification settings fields, see User Guide STEP 2.

This is a false positive. Some antivirus software may flag apps built with PyInstaller as unknown programs. Please refer to the Install Guide for step-by-step instructions on excluding the app.

On first launch, Playwright (the browser automation engine) needs to be downloaded. Please wait a few minutes with an active internet connection. If it still doesn't start, close the app and relaunch it.

This is normal behavior. On Mac in particular, the app performs initialization on startup, so it may take around 15 seconds before the browser opens. Please wait — once the browser appears, you can use the app immediately. Subsequent launches will be faster.

Closing the browser tab alone does not stop the app's internal server process. Due to macOS behavior, clicking the app icon while the server is still running will not launch a new instance — it simply activates the existing process, which can appear as if nothing happened.

Always use the "Quit App" button in the app UI to properly shut down the server before closing. This ensures the next launch works smoothly.

If you already closed the tab without using the Quit button, wait approximately 90 seconds — the server will shut down automatically after detecting no activity. You can then relaunch the app normally.

No uninstall is needed. Simply install the new version on top of the existing one. All your data — site settings, logs, and backups — will be preserved.

We recommend closing the app before running the update.

Windows: Download and run the new .exe installer. It will overwrite the existing installation automatically.
Mac: Open the new .dmg and drag the .app to the Applications folder. When prompted with "Replace existing item?", click Replace.

Please check the following:
① No extra spaces were included when copying and pasting the key
② Your internet connection is active
③ If the key is already in use on another PC, only one PC is allowed per key (per-plan limits apply)

If the issue persists, please contact us via the contact form.

You can deregister using the 「Deregister This PC」button in the License tab of the app's settings. If the old PC is no longer accessible, please contact us via the contact form and we will handle the deregistration.

The Business plan supports simultaneous registration on up to 2 PCs. For example, you can use it on both your main Mac and a laptop at the same time.

Note that no duplicate site check is performed between the two registered PCs. Feel free to use the plan flexibly across team members or multiple work locations.

If you need to use a third PC, simply deregister one of the current PCs first, then register the new one.

All site information, settings, and backup files on your PC remain intact. Nothing is deleted. However, after expiry, maintenance execution reverts to the Free plan limits (1 site, 3 runs per month).

Yes — we publish detailed comparison pages against the four most-used tools: ManageWP, MainWP, WP Umbrella, and InfiniteWP. The hub page includes an at-a-glance table across 7 dimensions, a 30-second summary of each tool, and a quick decision guide based on what matters most to you.

👉 See the 4-tool comparison hub

Three main differences:
① No plugin required on client sites (SSH + WP-CLI connection). ManageWP requires the ManageWP Worker plugin on every managed site.
② Per-plugin pinpoint rollback built in. ManageWP's "Safe Updates" reverts the entire site if anything breaks.
③ $28/mo for full features at 100 sites (Standard plan). ManageWP's All-in-One Bundle is $150/mo for the same site count.

That said, ManageWP has its own strengths: continuous uptime monitoring, team collaboration features, and a longer brand track record.

👉 See the full vs ManageWP comparison

All three differ from WP Maintenance Manager in two key ways: they require a dedicated plugin on each client site, and they don't offer per-plugin automatic rollback. Here's a quick summary of each, with links to the full comparisons:

・MainWP: open source, self-hosted on a WordPress site you provision. Pro $29/mo or $599 lifetime. See vs MainWP →

・WP Umbrella: EU-based SaaS, €1.99/site/mo. Strong on continuous uptime monitoring and GDPR-aligned data residency. See vs WP Umbrella →

・InfiniteWP: self-hosted, annual add-on licensing (from $147/yr). Hosted version $597/yr for 100 sites. See vs InfiniteWP →

We don't offer automatic site import from other tools. However, adding a single site takes about 30 seconds — just enter SSH credentials and the WordPress install path.

Parallel use is fully supported. WP Maintenance Manager connects via SSH and never touches the existing tool's plugin (ManageWP Worker, MainWP Child, WP Umbrella plugin, or InfiniteWP Client) — they don't conflict. We recommend starting with our free plan (1 site), then migrating gradually as you build confidence.

For a step-by-step parallel evaluation flow, see the "Try alongside [tool]" section on each comparison page.