I enrolled two WordPress applications in Cloudways Site Manager for this review, one through the onboarding screen tucked inside an application’s own sidebar, one through the bulk flow that lives at the account level.

From there, I ran a real Safe Update on four plugins, built a shared auto-update schedule covering both sites, turned on activity logging, and spent enough time in the account-level dashboard to understand where the same piece of information shows up in more than one place, and why that matters more than it sounds.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Kunjungi Cloudways

What is the Cloudways Site Manager?

Site Manager replaced an older Cloudways add-on called SafeUpdates. Understanding what SafeUpdates couldn’t do explains almost every design decision in the current product.

SafeUpdates ran everything over SSH, which created a specific set of problems for anyone managing more than a couple of sites:

• No dashboard, so no way to see which sites needed attention without checking each one individually
• Updates locked to a fixed weekly schedule, regardless of whether a client needed daily patching or monthly maintenance
• Visual regression testing limited to three desktop pages per site, thin coverage for anything beyond a brochure site
• No audit trail showing what changed, when, or who made the change

Agencies managing twenty or more WordPress installs told Cloudways, in effect, that the tool worked until it didn’t scale, and scaling was the whole reason they were on Cloudways in the first place.

Site Manager is the direct answer to that feedback. That context matters for reading the rest of this review, because it explains why some parts of the product feel unusually mature for something still in Public Preview, and why other parts, like the onboarding step you’ll hit on day one, still show the seams.

What Can Cloudways Site Manager Do?

With that background in place, the next question is scope: what can this tool actually reach. Before getting into onboarding, updates, and scheduling, it’s worth being precise about what Site Manager covers and what it doesn’t, because the honest answer is more nuanced than a flat yes or no.

The native dashboard is Cloudways-only

Every application available to enroll in the account-level Site Manager, whether through the per-app screen or the bulk wizard under Integrations, came from a server already sitting inside my Cloudways account.

There was no field to paste in credentials for an externally-hosted install, and no connector for a site running on a different host entirely.

The full feature set covered in this review, Safe Update’s staging clone, visual regression testing, activity logs, bulk scheduling, all of it lives inside this native, Cloudways-hosted layer.

A separate plugin extends lighter monitoring to any site

Cloudways also publishes a free WordPress plugin, also called Cloudways Site Manager, co-developed with WP Remote.

Unlike the native dashboard, this plugin installs directly on a WordPress site regardless of where it’s hosted, meaning it can bring an external, non-Cloudways site into a version of the same centralized view.

It’s a genuinely different product from the native dashboard, though, and the gap between the two matters:

The plugin also disables WordPress’s own automatic updates while active, a deliberate choice on Cloudways’ part to avoid conflicts during remote management.

Cloudways is upfront that the plugin route is a stepping stone rather than the destination: if you want the full stack, automated backups, one-click staging, Cloudflare integration, managed caching, the stated best practice is migrating the external site onto Cloudways rather than managing it remotely long-term.

For an agency with a fully Cloudways-hosted portfolio, none of this matters. For anyone still running a handful of sites elsewhere, and most agencies I’ve spoken with over the years have at least a few, the plugin is a real option for basic monitoring and updates, just not a substitute for what the native dashboard does.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Kunjungi Cloudways

Getting Started: Two Ways to Onboard Sites

With the scope question settled, the practical part starts here: actually getting a WordPress application enrolled. Cloudways gives you two ways into the native Site Manager, and they are not equally suited to the job.

Path 1: through an application’s own sidebar

Here’s exactly how I got there the first time. From the Cloudways home dashboard, I clicked into my server, then into the WordPress application sitting on it, which drops you on that app’s Access Details page.

The left sidebar there lists Access Details, Staging Management, Monitoring, Application Security, Domain Management, and then Site Manager, marked with a “New” tag. Clicking it took me straight to a screen titled “Simplify App Management with Site Manager,” scoped entirely to that one application, with two plan cards sitting side by side, Basic and Pro.

I clicked Get Pro. That’s when things went sideways.

The screen changed to “Subscribing to the Site Manager Plan…” with a message explaining that Cloudways was installing the plugin and syncing my site’s data, and that this could take a few minutes depending on the size of the application.

It ran for about two minutes and then failed, returning a red error notification: “Please delete existing plugin and install again.” I had no prior installation to delete, so the message itself didn’t tell me what had actually gone wrong.

I clicked Get Pro a second time, on the same plan screen, without changing anything. That attempt worked. It ran for roughly three minutes and finished with a green success notification confirming I’d subscribed to the Site Manager plan, landing me on the app’s Site Manager Overview page, plugin count, theme count, a performance score, and a Manage Updates table all populated and ready.

Path 2: through the account-level dashboard

This is the path worth using the moment you have more than one site to manage, and here’s exactly how I found and used it.

From the Cloudways home dashboard, the left-hand navigation has a row of icons: Home, Flexible, Autonomous, Integrations, and Agency Partners. I clicked Integrations. That opened a panel of cards, Site Manager (marked “New”), Application Migration, DNS Made Easy, CookieYes, and Equalize Digital Accessibility Checker among them.

Clicking the Site Manager card took me to a completely different screen from Path 1, one that lives under the breadcrumb Integrations → Add-Ons → Site Manager, with its own tab row: Overview, Manage Updates, Auto Updates, History.

This Overview page is the real command center. It shows account-wide stats, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, and, underneath, a Manage Applications table listing every app already enrolled.

To bring in more, I clicked Add Apps to Site Manager in the top right of that table. That opened a two-step wizard:

1. Select Application(s): a checklist of every WordPress app on my account not yet enrolled, with a Select All option and a search field.

A note above the list explained that it excludes staging apps, apps on stopped servers, and any app already running the older SafeUpdates add-on. I checked the app I wanted and clicked Select Plan.

2. Select your Plan: Basic and Pro shown side by side again, this time confirming how many applications I’d selected and the total monthly cost for that batch. I chose Pro and clicked Enable Site Manager.

The whole flow took under a minute once I was on the wizard screen, and it applied to every app I’d checked in step one at once, no repeating the plan choice per site.

The gap nobody warns you about

Having now enrolled apps through both paths, here’s the finding that changed how I think about this product’s day-to-day upkeep. I added a second WordPress application to a server that already had Site Manager actively managing another app on that same server.

I expected the new app to show up automatically, since it was sitting right next to an app Site Manager already knew about. It didn’t. The account-level dashboard’s “Total Apps on Site Manager” count stayed exactly where it was until I manually walked the new app through onboarding.

This is a design choice, but it’s a design choice with an operational cost:

• For a freelancer with three or four sites, remembering to onboard a new one is trivial.
• For an agency spinning up a new client site every week or two, this becomes a recurring line on somebody’s checklist, permanently.
• Miss it once, and that site sits outside your monitoring, your bulk updates, and your activity logs, invisible to the dashboard that’s supposed to be your single source of truth.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Kunjungi Cloudways

What You’re Actually Paying For

Site Manager splits into a genuinely usable free tier and a Pro tier that unlocks the features an agency would actually build a workflow around.

Basic vs. Pro, feature by feature

Basic is not a stripped-down trial. It includes a real site overview, the ability to manage users, themes, and plugins without touching wp-admin, one-click WordPress single sign-on, Quick Updates, and, notably, the centralized dashboard itself.

Cloudways didn’t gate the core “see all your sites in one place” experience behind a paywall. What’s gated is everything that makes that dashboard trustworthy enough to act on without babysitting it.

Pro is currently free to use during Public Preview regardless of its listed price, which is $3 per app per month, dropping to $2 per app once you cross five applications.

What Pro actually costs as your portfolio grows

That discount threshold is worth doing arithmetic on before assuming Pro scales cheaply:

None of those numbers are unreasonable against what a single broken, unbacked update could cost in client trust, but per-app pricing means the bill grows in a straight line with your portfolio, not in the step-function discounts some competing tools offer at higher tiers.

Three Places to Trigger the Same Update

With enrollment and pricing out of the way, the rest of this review covers what day-to-day use actually looks like, starting with a piece of architecture worth understanding.

This is the part of Site Manager’s design that took the longest to actually work out, and it isn’t explained anywhere in the interface itself.

• An application’s own Overview page still shows its own Manage Updates table, listing the same pending plugin updates you’d see from the account-level dashboard.
• The account-level dashboard’s row-level Actions menu offers its own Manage Updates action, pulling from the same underlying data.
• The Auto Updates tab lets you schedule that same kind of update to run automatically, across one app or every enrolled app at once.

These are three doors into the same room. The per-app view is for someone already working inside that specific site who happens to notice a pending update. The account-level row action is for someone scanning the whole portfolio and deciding to act on one site right now.

The scheduling tab is for removing the human from the loop entirely.

Quick Update Versus Safe Update

Of the three doors just described, this section covers the first two, the per-app view and the account-level row action, since both open the same update mechanism.

Every plan tier offers Quick Update. Applying it takes seconds: the update installs directly to production with no compatibility check and no backup taken first.

Cloudways’ own interface copy is honest about the tradeoff, warning that it “may carry risks if updates aren’t compatible.”

I did not run a Quick Update in this test, so I can’t describe firsthand what a failed one actually looks like on screen. That’s a real gap in this review, and I’d treat any claim about Quick Update’s failure behavior, from me or anyone else who hasn’t triggered one, with appropriate skepticism.

Safe Update is where Pro earns its price, and it’s worth walking through in full because the process is more involved than “backup, then update.”

What a Safe Update run actually looks like

Here’s exactly how I triggered it. From the account-level Overview table under Integrations → Site Manager, I found the row for the app with pending updates and clicked the three-dot Actions menu at the end of that row. It opened four options: WP-Admin, App Overview, Manage Updates, and Manage Plan. I clicked Manage Updates.

That opened a modal listing every plugin with a pending update, four in my case, Breeze, Elementor, Object Cache Pro, and WP ULike, each shown as a checked item with its current version and the version it would update to.

Below the list sat two radio options: Quick Update and Safe Update, each with a one-line description of the tradeoff. I selected Safe Update and clicked Proceed.

Rather than a single progress spinner, the modal that opened next shows a staged checklist that updates in real time.

Staging environment:

• Pre Snapshot
• Fetch Update Packages
• Update each plugin individually
• Post Snapshot
• Purge Cache
• Visual Regression

Production:

• The identical sequence repeats once staging passes, ending in one final cache purge

I started the run at 6:21 pm and it finished at 6:27 pm. Six minutes, for four plugins, across a complete staging-then-production cycle. The modal itself sets the expectation that this “usually takes less than a minute,” which my run overshot by a wide margin.

That gap between the stated estimate and the actual time is worth planning around rather than being surprised by if you’re running Safe Update on a batch of plugins during a maintenance window, budget minutes, not seconds, especially as plugin counts grow.

A success notification confirmed the result, and the moment it finished, the account-level History tab logged it as “On-Demand Successful: Plugins (4)” with a link through to the full detail.

That closing of the loop, watching an action happen and then immediately being able to point to a permanent record of it, is exactly the kind of client-facing proof an agency needs, and SafeUpdates never gave them.

The two settings that decide how forgiving updates are

Both of these live inside the scheduling flow rather than the on-demand update screen, which makes them easy to miss:

• Visual Regression Sensitivity controls how much visual difference between the staging test and production is tolerated before an update aborts to protect your layout. It defaults to the strictest setting available, “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, enabled by default, means a single plugin failing to update does not stop the entire batch. The system sets that one item aside, updates everything else, runs the visual regression check on what succeeded, and pushes those changes live automatically.

Together, these two defaults decide whether an unattended overnight update run wakes you up to one flagged plugin sitting in a queue, or to an entire site stuck mid-update because one incompatible theme brought the whole process to a halt. Worth checking both before trusting any schedule to run unattended.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Kunjungi Cloudways

Scheduling Updates Across an Entire Portfolio at Once

That covers the first two doors. This section covers the third: removing the human from the loop entirely. The Auto Updates tab, reached from the same account-level Site Manager page, is where the “manage many sites like they’re one” pitch either delivers or falls apart. In my case, it delivered.

Here’s exactly how I set it up. From Integrations → Site Manager, I clicked the Auto Updates tab in the top row.

With nothing scheduled yet, the page showed an empty state, “No Auto Updates Schedule,” with a single button: Set Auto Update Schedule.

Clicking it opened a wizard, “Set Auto Update Schedule,” which walked through the following in one pass:

1. Day of Week and Schedule Time: two dropdowns, plus a timezone selector next to the time field. I set Friday, between midnight and 5:59am UTC.
2. Select Application: a checklist of every app already enrolled in Site Manager, with a Select All option, and a note that any existing schedule already set on a selected app would be replaced by this new one. I selected both of my apps and clicked Choose Preferences.

A second screen then opened, “Create Auto Update Schedule,” covering:

3. Configure Update List: three expandable sections, WordPress Core, Plugins, and Themes, each with its own checklist and a running count of how many were selected. Across my two apps, ten plugins and four themes were available to include, and each individual plugin and theme listed exactly how many of my applications actually used it, a small detail that matters enormously once you’re managing dozens of sites and trying to tell which updates are worth testing broadly versus which only touch one site.

4. Update Type: a dropdown offering Quick Update or Safe Update, each with the same description shown on the on-demand modal. Choosing Safe Update revealed two additional controls that only appear for that mode, Visual Regression Sensitivity and Smart Skip for Plugin/Theme Update Failures.

5. Critical Updates: a toggle, off by default, reserved specifically for pushing a security-driven patch outside the normal schedule the moment a vulnerability gets flagged.

Clicking Set AutoUpdate Schedule at the bottom saved it, applied to every app I’d selected in step two, with no need to repeat the configuration once per site.

Activity Logs: The Part That’s Actually About Client Trust

The three doors and the update mechanics behind them cover the how. This last feature covers the proof: a permanent record of what happened, separate from the update process itself.

Here’s exactly how I turned it on.

From that app’s own Site Manager Overview page, the same one you land on after subscribing through Path 1, a card labeled “Activity Logs are Disabled” sits next to the performance ring, with a short description and a single button: Enable Activity Logs.

I clicked it, and the card updated immediately, no confirmation modal, no additional steps. Checking the account-level Manage Applications table straight afterward, under Integrations → Site Manager, the Activity Logs column for that app had already flipped from Disabled to Enabled, without needing to refresh the page.

This feature sits behind Pro, and it exists to answer a question every agency eventually gets asked by a client: who changed what, and when.

Without it, that answer usually lives in a WordPress logging plugin writing to the site’s own database, which bloats over time and offers no protection against tampering. Having that record live outside the WordPress installation itself, inside the hosting layer, is a meaningfully different level of trust for anything client-facing.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Kunjungi Cloudways

Pros and Cons

Who This Is Actually For

With the full feature set, its costs, and its rough edges all on the table, the last question is simply whether it fits your specific portfolio.

The clearest fit is an agency or freelance developer running several, ideally many, WordPress sites that already live entirely inside Cloudways, where a broken update carries a real cost in client trust rather than just personal inconvenience.

The Safe Update workflow and bulk scheduling exist specifically to solve the problem that shows up once you’re past the point where checking each site individually is still reasonable.

It’s a partial fit for anyone with a mixed portfolio. The free Site Manager plugin can bring in external sites for basic monitoring and updates, but the features that make the native dashboard worth paying for, staging-based Safe Update, visual regression, activity logs, stay out of reach until those sites actually move to Cloudways.

It’s simply unnecessary for a single-site owner. The free tier would technically work, but the entire product exists to solve a portfolio-scale problem that a single site never creates.

Conclusion: Worth It, But Only Inside Cloudways

Yes, the site manager is worth adopting, on one condition: your sites already live on Cloudways. Within that boundary, Site Manager delivers what it promises, a real cross-app dashboard, a Safe Update path that backs up before touching production, and bulk scheduling that treats updates as a fleet-wide action instead of a per-login chore.

Outside that boundary, it’s a lighter tool with a clear migration nudge attached. The best fit is an agency consolidating client sites on Cloudways who needs one place to prove what changed and when.

Cloudways

4.6

537 user reviews

Rp198.860 /mo

Harga awal

Kunjungi Cloudways

Rating based on expert review

• Mudah Dipakai
  4.8
• Dukungan
  4.7
• Fitur
  4.5
• Keandalan
  4.8
• Harga
  4.3