Registré dos aplicaciones de WordPress en Cloudways Site Manager para esta review, una a través de la pantalla de onboarding escondida dentro de la barra lateral de una aplicación, otra mediante el flujo masivo que vive a nivel de cuenta.
A partir de ahí, hice una Safe Update real en cuatro plugins, armé un cronograma compartido de auto-update que cubría ambos sitios, activé el registro de actividad y pasé suficiente tiempo en el dashboard a nivel de cuenta como para entender dónde aparece la misma información en más de un lugar, y por qué eso importa más de lo que parece.
Site Manager reemplazó un add-on anterior de Cloudways llamado SafeUpdates. Entender lo que SafeUpdates no podía hacer explica casi todas las decisiones de diseño del producto actual.
SafeUpdates ejecutaba todo por SSH, lo que generaba un conjunto específico de problemas para cualquiera que manejara más de un par de sitios:
Las agencias que administraban veinte o más instalaciones de WordPress le dijeron a Cloudways, en efecto, que la herramienta funcionaba hasta que dejó de escalar, y escalar era justamente la razón por la que estaban en Cloudways.
Site Manager es la respuesta directa a ese feedback. Ese contexto importa para leer el resto de esta review, porque explica por qué algunas partes del producto se sienten inusualmente maduras para algo que todavía está en Public Preview, y por qué otras partes, como el paso de onboarding que vas a encontrar el primer día, todavía muestran las costuras.
Con ese contexto en lugar, la siguiente pregunta es el alcance: a qué puede llegar esta herramienta. Antes de entrar en onboarding, actualizaciones y programación, conviene ser preciso sobre qué cubre Site Manager y qué no, porque la respuesta honesta es más matizada que un sí o no rotundo.
Todas las aplicaciones disponibles para inscribir en el Site Manager a nivel de cuenta, ya sea a través de la pantalla por aplicación o del wizard masivo bajo Integrations, provenían de un server que ya estaba dentro de mi cuenta de Cloudways.
No había ningún campo para pegar credenciales de una instalación alojada externamente, ni un conector para un sitio que corriera en otro hosting por completo.
El set completo de funciones cubierto en esta review, Safe Update con su staging clone, las pruebas visuales de regresión, los registros de actividad, la programación masiva, todo eso vive dentro de esta capa nativa alojada en Cloudways.
Cloudways también publica un plugin gratuito de WordPress, también llamado Cloudways Site Manager, co-desarrollado con WP Remote.
A diferencia del dashboard nativo, este plugin se instala directamente en un sitio WordPress sin importar dónde esté alojado, lo que significa que puede traer un sitio externo, no alojado en Cloudways, a una versión de la misma vista centralizada.
Igual, es un producto genuinamente distinto del dashboard nativo, y la diferencia entre ambos importa:
| Capability | Native Site Manager (Cloudways-hosted apps) | Site Manager Plugin (any host) |
|---|---|---|
| Centralized dashboard | Yes | Yes |
| Core, plugin, theme updates | Yes | Yes |
| Safe Update (staging clone + visual regression) | Yes | No |
| Server-level caching (Varnish, Redis, Cloudflare) | Yes | No |
| Activity logs | Yes (Pro) | Not equivalent |
| Cost | Free (Basic) / paid (Pro) | Free |
El plugin también desactiva las actualizaciones automáticas propias de WordPress mientras está activo, una decisión deliberada de Cloudways para evitar conflictos durante la gestión remota.
Cloudways es claro en que la ruta del plugin es un paso intermedio más que el destino: si querés el stack completo, backups automáticos, staging con un clic, integración con Cloudflare, caché administrado, la práctica recomendada que se menciona es migrar el sitio externo a Cloudways en lugar de administrarlo de forma remota a largo plazo.
Para una agencia con un portfolio enteramente alojado en Cloudways, nada de esto importa. Para cualquiera que todavía tenga unos cuantos sitios en otro lado, y la mayoría de las agencias con las que hablé a lo largo de los años tiene al menos algunos, el plugin es una opción real para monitoreo y actualizaciones básicas, aunque no reemplaza lo que hace el dashboard nativo.
Con la cuestión del alcance resuelta, la parte práctica arranca acá: inscribir realmente una aplicación WordPress. Cloudways te da dos caminos para entrar al Site Manager nativo, y no son igualmente adecuados para la tarea.
Así fue exactamente como llegué la primera vez. Desde el dashboard principal de Cloudways, hice clic en mi server, y después en la aplicación WordPress que estaba sobre él, lo que te deja en la página Access Details de esa app.
La barra lateral de la izquierda ahí enumera Access Details, Staging Management, Monitoring, Application Security, Domain Management y luego Site Manager, marcado con una etiqueta “New”. Hacer clic ahí me llevó directo a una pantalla titulada “Simplify App Management with Site Manager,” enfocada por completo en esa sola aplicación, con dos tarjetas de plan lado a lado, Basic y Pro.
Hice clic en Get Pro. Ahí fue cuando las cosas se fueron al carajo.
La pantalla cambió a “Subscribing to the Site Manager Plan…” con un mensaje que explicaba que Cloudways estaba instalando el plugin y sincronizando los datos del sitio, y que esto podía llevar unos minutos según el tamaño de la aplicación.
Corrió durante unos dos minutos y después falló, volviendo con una notificación roja: “Please delete existing plugin and install again.” Yo no tenía ninguna instalación previa para borrar, así que el mensaje en sí no me decía qué había salido mal realmente.
Hice clic en Get Pro una segunda vez, en la misma pantalla del plan, sin cambiar nada. Ese intento funcionó. Corrió durante aproximadamente tres minutos y terminó con una notificación verde confirmando que me había suscripto al plan de Site Manager, llevándome a la página Site Manager Overview de la app, con el conteo de plugins, el conteo de themes, un puntaje de performance y una tabla Manage Updates ya completados y listos.
Este es el camino que vale la pena usar en el momento en que tenés más de un sitio para administrar, y acá te explico exactamente cómo lo encontré y lo usé.
Desde el dashboard principal de Cloudways, la navegación de la izquierda tiene una fila de íconos: Home, Flexible, Autonomous, Integrations y Agency Partners. Hice clic en Integrations. Eso abrió un panel de tarjetas, entre ellas Site Manager, marcada como “New”, Application Migration, DNS Made Easy, CookieYes y Equalize Digital Accessibility Checker.
Hacer clic en la tarjeta Site Manager me llevó a una pantalla completamente distinta a la del Camino 1, una que vive bajo la ruta Integrations → Add-Ons → Site Manager, con su propia fila de pestañas: Overview, Manage Updates, Auto Updates, History.
Esta página Overview es el verdadero centro de comando. Muestra estadísticas a nivel de cuenta, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates y, debajo, una tabla Manage Applications que lista cada app ya inscrita.
Para sumar más, hice clic en Add Apps to Site Manager en la esquina superior derecha de esa tabla. Eso abrió un wizard de dos pasos:
Una nota encima de la lista explicaba que excluye las staging apps, las apps en servers detenidos y cualquier app que ya estuviera usando el add-on anterior SafeUpdates. Marqué la app que quería y hice clic en Select Plan.
Todo el flujo llevó menos de un minuto una vez que estuve en la pantalla del wizard, y se aplicó a todas las apps que había marcado en el paso uno de una sola vez, sin repetir la elección del plan por cada sitio.
Habiendo inscrito ahora aplicaciones por ambos caminos, acá va el hallazgo que cambió cómo pienso el mantenimiento diario de este producto. Sumé una segunda aplicación WordPress a un server que ya tenía Site Manager administrando activamente otra app en ese mismo server.
Esperaba que la nueva app apareciera automáticamente, ya que estaba al lado de una app que Site Manager ya conocía. No pasó. El conteo “Total Apps on Site Manager” del dashboard a nivel de cuenta no se movió en absoluto hasta que pasé manualmente la nueva app por el onboarding.
Esto es una decisión de diseño, pero es una decisión de diseño con costo operativo:
Site Manager se divide en un nivel gratuito realmente usable y un nivel Pro que desbloquea las funciones sobre las que una agencia realmente construiría un flujo de trabajo.
| Feature | Basic (Free) | Pro |
|---|---|---|
| Site Overview | Yes | Yes |
| Manage Users, Themes, Plugins | Yes | Yes |
| Quick Updates | Yes | Yes |
| WordPress Single Sign-On | Yes | Yes |
| Centralized Dashboard | Yes | Yes |
| Safe Updates (staging clone + visual regression) | No | Yes |
| Scheduled Auto Updates | No | Yes |
| Site Performance Monitoring | No | Yes |
| Activity Logs | No | Yes |
| Update History | No | Yes |
Basic no es una prueba recortada. Incluye un verdadero resumen del sitio, la capacidad de administrar usuarios, themes y plugins sin tocar wp-admin, WordPress Single Sign-On con un clic y Quick Updates, y, notablemente, el dashboard centralizado en sí mismo.
Cloudways no puso detrás de un paywall la experiencia central de “ver todos tus sitios en un solo lugar”. Lo que sí está bloqueado es todo aquello que hace que ese dashboard sea lo suficientemente confiable como para actuar sobre él sin vigilarlo todo el tiempo.
Pro actualmente se puede usar gratis durante Public Preview sin importar su precio listado, que es $3 por app por mes, bajando a $2 por app una vez que superás cinco aplicaciones.
Ese umbral de descuento vale la pena calcularlo antes de asumir que Pro escala barato:
| Sites managed | Pro cost (sticker price) |
|---|---|
| 3 sites | $9/month |
| 5 sites | $10/month ($2/app) |
| 10 sites | $20/month |
| 25 sites | $50/month |
| 50 sites | $100/month |
Ninguno de esos números es irrazonable frente a lo que podría costar una sola actualización rota y sin backup en confianza de un cliente, pero el pricing por app hace que la factura crezca en línea recta con tu portfolio, no en los saltos de descuento por escalones que ofrecen algunas herramientas competidoras en niveles más altos.
Con la inscripción y el pricing resueltos, el resto de esta review cubre cómo es realmente el uso diario, empezando por una parte de la arquitectura que vale la pena entender.
Esta es la parte del diseño de Site Manager que más me costó entender realmente, y no se explica en ningún lado de la interfaz.
Estas son tres puertas que llevan a la misma sala. La vista por aplicación es para alguien que ya está trabajando dentro de ese sitio específico y de repente ve una actualización pendiente. La acción a nivel de cuenta por fila es para alguien que está revisando todo el portfolio y decide actuar sobre un sitio ahora mismo.
La pestaña de programación es para sacar al humano del circuito por completo.
De las tres puertas recién descriptas, esta sección cubre las dos primeras, la vista por aplicación y la acción por fila a nivel de cuenta, ya que ambas abren el mismo mecanismo de actualización.
Todos los niveles del plan ofrecen Quick Update. Aplicarlo lleva segundos: la actualización se instala directamente en producción sin ninguna verificación de compatibilidad y sin tomar un backup primero.
La propia interfaz de Cloudways es honesta respecto del trade-off, advirtiendo que “may carry risks if updates aren’t compatible.”
No ejecuté un Quick Update en esta prueba, así que no puedo describir de primera mano cómo se ve una falla real en pantalla. Esa es una carencia real de esta review, y trataría cualquier afirmación sobre el comportamiento de falla de Quick Update, mía o de cualquiera que no lo haya activado, con el escepticismo correspondiente.
Safe Update es donde Pro justifica su precio, y vale la pena recorrerlo completo porque el proceso es más elaborado que “backup, then update.”
Así fue exactamente como lo activé. Desde la tabla Overview a nivel de cuenta bajo Integrations → Site Manager, encontré la fila de la app con actualizaciones pendientes y hice clic en el menú de tres puntos Actions al final de esa fila. Se abrieron cuatro opciones: WP-Admin, App Overview, Manage Updates y Manage Plan. Hice clic en Manage Updates.
Eso abrió un modal que lista cada plugin con una actualización pendiente, cuatro en mi caso, Breeze, Elementor, Object Cache Pro y WP Ulike, cada uno mostrado como un ítem marcado con su versión actual y la versión a la que se actualizaría.
Debajo de la lista había dos opciones de radio: Quick Update y Safe Update, cada una con una descripción breve del trade-off. Seleccioné Safe Update y hice clic en Proceed.
En lugar de un único spinner de progreso, el modal que se abrió después muestra una checklist por etapas que se actualiza en tiempo real.
Staging environment:
Production:
Empecé la corrida a las 6:21 pm y terminó a las 6:27 pm. Seis minutos, para cuatro plugins, a través de un ciclo completo de staging y luego producción.
La modalidad en sí establece la expectativa de que esto “usually takes less than a minute,” lo que en mi corrida se extendió bastante más allá de eso.
Ese margen entre el tiempo estimado y el tiempo real vale la pena tenerlo en cuenta en lugar de llevarse una sorpresa si estás ejecutando Safe Update sobre un lote de plugins durante una ventana de mantenimiento: presupuestá minutos, no segundos, especialmente a medida que crece la cantidad de plugins.
Una notificación de éxito confirmó el resultado, y en el momento en que terminó, la pestaña History a nivel de cuenta lo registró como “On-Demand Successful: Plugins (4)” con un link a los detalles completos.
Ese cierre del ciclo, ver cómo ocurre una acción y luego poder señalar de inmediato un registro permanente de ella, es exactamente el tipo de prueba frente al cliente que una agencia necesita, y SafeUpdates nunca se la dio.
Ambos viven dentro del flujo de programación en lugar de la pantalla de actualización bajo demanda, lo que hace que sean fáciles de pasar por alto:
Juntos, estos dos ajustes por defecto determinan si una corrida de actualización desatendida durante la noche te despierta con un plugin marcado en la cola, o con todo un sitio trabado a mitad de actualización porque un tema incompatible hizo caer todo el proceso. Vale la pena revisar ambos antes de confiar en que cualquier cronograma va a correr sin supervisión.
Eso cubre las dos primeras puertas. Esta sección cubre la tercera: sacar al humano del circuito por completo. La pestaña Auto Updates, accesible desde la misma página Site Manager a nivel de cuenta, es donde la promesa de “manejar muchos sitios como si fueran uno” se cumple o se cae. En mi caso, se cumplió.
Así fue exactamente como la configuré. Desde Integrations → Site Manager, hice clic en la pestaña Auto Updates en la fila superior.
Sin nada programado todavía, la página mostraba un estado vacío, “No Auto Updates Schedule,” con un único botón: Set Auto Update Schedule.
Hacer clic ahí abrió un wizard, “Set Auto Update Schedule,” que recorrió lo siguiente de una sola pasada:
Después se abrió una segunda pantalla, “Create Auto Update Schedule,” que cubría:
Hacer clic en Set AutoUpdate Schedule al final guardó todo, aplicado a todas las apps que había seleccionado en el paso dos, sin necesidad de repetir la configuración una vez por sitio.
Las tres puertas y los mecanismos de actualización detrás de ellas cubren el cómo. Esta última función cubre la prueba: un registro permanente de lo que pasó, separado del proceso de actualización en sí.
Así fue exactamente como lo activé.
Desde la propia página Site Manager Overview de esa app, la misma a la que llegás después de suscribirte por el Camino 1, aparece una tarjeta llamada “Activity Logs are Disabled” al lado del anillo de performance, con una breve descripción y un único botón: Enable Activity Logs.
Hice clic, y la tarjeta se actualizó al instante, sin modal de confirmación, sin pasos adicionales. Al revisar enseguida la tabla Manage Applications a nivel de cuenta, bajo Integrations → Site Manager, la columna Activity Logs de esa app ya había pasado de Disabled a Enabled, sin necesidad de refrescar la página.
Esta función está detrás de Pro, y existe para responder una pregunta que toda agencia termina recibiendo de un cliente: quién cambió qué, y cuándo.
Sin esto, esa respuesta suele vivir en un plugin de logging de WordPress escribiendo en la propia base de datos del sitio, lo que la infla con el tiempo y no ofrece protección contra manipulación. Tener ese registro fuera de la instalación de WordPress, dentro de la capa de hosting, es un nivel de confianza sensiblemente distinto para cualquier cosa orientada al cliente.
Con el set de funciones completo, sus costos y sus bordes ásperos sobre la mesa, la última pregunta es simplemente si encaja con tu portfolio específico.
El mejor encaje es una agencia o un desarrollador freelance que administra varios, idealmente muchos, sitios WordPress que ya viven por completo dentro de Cloudways, donde una actualización rota implica un costo real en la confianza del cliente y no solo una molestia personal.
Safe Update y la programación masiva existen precisamente para resolver el problema que aparece una vez que ya pasaste el punto en que revisar cada sitio por separado sigue siendo razonable.
Es un encaje parcial para cualquiera con un portfolio mixto. El plugin gratuito de Site Manager puede incorporar sitios externos para monitoreo y actualizaciones básicas, pero las funciones que hacen que el dashboard nativo valga la pena pagar, Safe Update basado en staging, regresión visual, registros de actividad, quedan fuera de alcance hasta que esos sitios realmente se muden a Cloudways.
Simplemente es innecesario para alguien que tiene un solo sitio. El nivel gratuito técnicamente funcionaría, pero todo el producto existe para resolver un problema a escala de portfolio que un solo sitio nunca genera.
Sí, vale la pena adoptar Site Manager, con una condición: que tus sitios ya vivan en Cloudways. Dentro de ese límite, Site Manager cumple con lo que promete: un dashboard real entre apps, una vía de Safe Update que hace backup antes de tocar producción y una programación masiva que trata las actualizaciones como una acción de flota y no como una tarea por login.
Fuera de ese límite, es una herramienta más liviana con un empujón claro hacia la migración adjunto. El mejor encaje es una agencia que consolida sitios de clientes en Cloudways y necesita un solo lugar para probar qué cambió y cuándo.
| Description | Expert Review |
|---|---|
| Alojamiento de WordPress gestionado con velocidad, seguridad y actualizaciones sin co... | Read Wordpress Hosting Review |
| Alojamiento en la nube flexible y de alto rendimiento con recursos escalables y fiabi... | Read Cloud Hosting Review |
| Alojamiento de correo electrónico seguro y eficiente adaptado a las necesidades de c... | Read Email Hosting Review |
| Alojamiento optimizado de Magento con velocidades rápidas y rendimiento de comercio ... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
Sí. Cloudways Site Manager es un complemento nativo que centraliza las actualizaciones, el monitoreo del rendimiento y los registros de actividad para aplicaciones de WordPress que ya están alojadas dentro de tu cuenta de Cloudways. Un complemento companion gratuito e independiente amplía la supervisión ligera y la capacidad de actualización a sitios de WordPress alojados en cualquier lugar.
No a través del panel nativo probado en esta reseña, que se limita a aplicaciones ya alojadas en Cloudways. Un plugin gratuito, también llamado Cloudways Site Manager y co-desarrollado con WP Remote, puede incorporar sitios externos para el monitoreo y las actualizaciones de core, plugins y temas, aunque sin el clon de staging de Safe Update, las pruebas de regresión visual ni el caché a nivel de servidor.
El plan Basic es gratis e incluye el resumen del sitio, la gestión de usuarios y plugins, y Quick Updates. Pro suma Safe Updates, programación, monitoreo de rendimiento y registros de actividad por US$3 por app al mes, bajando a US$2 a partir de cinco apps o más, y actualmente se puede usar gratis durante la Public Preview.
Quick Update aplica cambios directamente en producción en segundos, sin respaldo ni verificación de compatibilidad. Safe Update crea un clon de staging, verifica la compatibilidad, actualiza cada paquete, ejecuta una prueba de regresión visual y solo lo lleva a producción si esa prueba pasa.
Sí. Las nuevas aplicaciones nunca se inscriben automáticamente, incluso cuando se agregan a un servidor que ya tiene otras aplicaciones de Site Manager en ejecución. Cada sitio necesita su propio paso de incorporación, ya sea individualmente o mediante el asistente masivo en Integrations.
¡Responde algunas preguntas simples y encuentra la solución perfecta para ti!
Iniciar búsqueda de alojamiento
