Я зареєстрував дві програми WordPress у Cloudways Site Manager для цього огляду: одну через екран під час онбордингу, захований у бічній панелі самої програми, іншу через масовий процес, що знаходиться на рівні облікового запису.
Після цього я провів справжній Safe Update для чотирьох плагінів, створив спільний розклад автоматичних оновлень, що охоплює обидва сайти, увімкнув журналювання активності та провів достатньо часу в панелі керування на рівні облікового запису, щоб зрозуміти, де одна й та сама інформація з’являється в більш ніж одному місці, і чому це важливіше, ніж здається.
Site Manager замінює старіший доповнювач Cloudways під назвою SafeUpdates. Розуміння того, чого не міг SafeUpdates, пояснює майже кожне дизайнерське рішення в поточному продукті.
SafeUpdates працював повністю через SSH, що створювало специфічний набір проблем для тих, хто керує більш ніж кількома сайтами:
Агентства, що керують двадцятьма або більше WordPress-інсталяціями, фактично сказали Cloudways, що інструмент працював, поки не перестав масштабуватися, а масштабування було саме тією причиною, чому вони взагалі працювали з Cloudways.
Site Manager — це прямої відповідь на цей зворотний зв’язок. Цей контекст важливий для читання решти огляду, бо він пояснює, чому деякі частини продукту здаються незвично зрілими для того, що все ще перебуває в Public Preview, і чому інші частини, як-от крок онбордингу, з яким ви зіткнетеся в перший день, усе ще мають шви.
З цим тлом наступне питання — масштаб: що саме цей інструмент може охопити. Перш ніж переходити до онбордингу, оновлень і планування, варто точно визначити, що Site Manager покриває, а що ні, тому що чесна відповідь тут нюансованіша, ніж просте так або ні.
Усі застосунки, доступні для підключення в Site Manager на рівні облікового запису, незалежно від того, через сторінку окремої програми чи через масовий майстер у розділі Integrations, походили з сервера, уже розміщеного в моєму обліковому записі Cloudways.
Не було поля, куди можна вставити облікові дані для зовнішньо розміщеної інсталяції, і не було конектора для сайту, що працює на іншому хостингу.
Увесь набір функцій, описаний у цьому огляді, Safe Update, staging-клон, візуальне регресійне тестування, журнали активності, масове планування — усе це живе всередині цього нативного, розміщеного на Cloudways рівня.
Cloudways також випускає безплатний плагін WordPress, теж під назвою Cloudways Site Manager, розроблений спільно з WP Remote.
На відміну від нативної панелі, цей плагін встановлюється безпосередньо на сайт WordPress незалежно від того, де він розміщений, тобто може додати зовнішній, не-Cloudways сайт до версії того самого централізованого перегляду.
Втім, це справді інший продукт, ніж нативна панель, і різниця між ними має значення:
| Можливість | Нативний Site Manager (застосунки на Cloudways) | Плагін Site Manager (будь-який хостинг) |
|---|---|---|
| Централізована панель керування | Так | Так |
| Оновлення ядра, плагінів, тем | Так | Так |
| Safe Update (staging-клон + візуальна регресія) | Так | Ні |
| Серверне кешування (Varnish, Redis, Cloudflare) | Так | Ні |
| Журнали активності | Так (Pro) | Не еквівалентно |
| Вартість | Безплатно (Basic) / платно (Pro) | Безплатно |
Плагін також вимикає автоматичні оновлення WordPress, поки активний, що є свідомим рішенням Cloudways, аби уникнути конфліктів під час віддаленого керування.
Cloudways відверто каже, що варіант із плагіном — це проміжний крок, а не кінцева точка: якщо вам потрібен повний стек, автоматичні резервні копії, staging у один клік, інтеграція Cloudflare, кероване кешування, рекомендованою практикою є міграція зовнішнього сайту на Cloudways, а не довгострокове віддалене керування ним.
Для агентства з повністю розміщеним на Cloudways портфоліо все це не має значення. Для тих, хто все ще тримає кілька сайтів деінде, а більшість агентств, з якими я спілкувався протягом років, мають принаймні кілька таких сайтів, плагін — це реальний варіант для базового моніторингу та оновлень, але не заміна тому, що робить нативна панель.
Коли питання масштабу вирішене, практична частина починається тут: фактичне підключення WordPress-застосунку. Cloudways дає два способи потрапити до нативного Site Manager, і вони не однаково придатні для цього завдання.
Ось як саме я потрапив туди вперше. З головної панелі Cloudways я натиснув на свій сервер, потім на WordPress-застосунок, що працював на ньому, і це перевело мене на сторінку Access Details цієї програми.
Ліва бічна панель там містить Access Details, Staging Management, Monitoring, Application Security, Domain Management, а потім Site Manager із позначкою “New”. Натискання перевело мене прямо на екран із назвою “Simplify App Management with Site Manager,” який стосується виключно цієї однієї програми, з двома картками планів поруч, Basic і Pro.
Я натиснув Get Pro. Саме тоді все пішло не так.
Екран змінився на “Subscribing to the Site Manager Plan…” із повідомленням, що Cloudways встановлює плагін і синхронізує дані сайту, і що це може зайняти кілька хвилин залежно від розміру застосунку.
Це тривало приблизно дві хвилини, а потім завершилося помилкою, повернувши червоне повідомлення: “Please delete existing plugin and install again.” У мене не було попередньо встановленого плагіна, який треба було б видалити, тож саме повідомлення не пояснювало, що насправді пішло не так.
Я натиснув Get Pro другий раз на тому самому екрані плану, нічого не змінюючи. Ця спроба спрацювала. Вона тривала приблизно три хвилини й завершилася зеленою сповіщенням про успіх, яке підтвердило, що я підписався на план Site Manager, після чого мене перевело на сторінку Site Manager Overview цього застосунку, де вже були заповнені кількість плагінів, кількість тем, показник продуктивності та таблиця Manage Updates.
Це шлях, який варто використовувати щойно у вас є більше ніж один сайт для керування, і ось як саме я його знайшов і використав.
Із головної панелі Cloudways ліворуч є ряд іконок: Home, Flexible, Autonomous, Integrations і Agency Partners. Я натиснув Integrations. Це відкрило панель карток: Site Manager із позначкою “New”, Application Migration, DNS Made Easy, CookieYes та Equalize Digital Accessibility Checker серед інших.
Натискання картки Site Manager перевело мене на зовсім інший екран, ніж Шлях 1, той, що знаходиться під шляхом Integrations → Add-Ons → Site Manager, зі своїм рядом вкладок: Overview, Manage Updates, Auto Updates, History.
Ця сторінка Overview — справжній командний центр. Вона показує загальні показники облікового запису, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, а нижче — таблицю Manage Applications, де перелічено кожен уже підключений застосунок.
Щоб додати ще, я натиснув Add Apps to Site Manager у правому верхньому куті цієї таблиці. Це відкрило двокроковий майстер:
Примітка над списком пояснювала, що він не включає staging-застосунки, застосунки на зупинених серверах і будь-який застосунок, який уже працює зі старішим доповнювачем SafeUpdates. Я позначив потрібний застосунок і натиснув Select Plan.
Увесь процес зайняв менше хвилини, коли я вже був на екрані майстра, і він застосувався до кожного застосунку, який я позначив у кроці один, одразу, без повторного вибору плану для кожного сайту.
Тепер, коли я підключив застосунки обома шляхами, ось висновок, який змінив моє уявлення про щоденне обслуговування цього продукту. Я додав другий WordPress-застосунок на сервер, який уже мав Site Manager, що активно керував іншим застосунком на тому ж сервері.
Я очікував, що новий застосунок з’явиться автоматично, оскільки він стояв просто поруч із тим, який Site Manager уже знав. Але цього не сталося. Лічильник “Total Apps on Site Manager” на панелі рівня облікового запису залишився на тому самому місці, доки я вручну не провів новий застосунок через онбординг.
Це дизайнерське рішення, але дизайнерське рішення з операційною ціною:
Site Manager поділяється на справді корисний безплатний рівень і Pro-рівень, який відкриває функції, навколо яких агентство дійсно будувало б робочий процес.
| Функція | Basic (Безплатно) | Pro |
|---|---|---|
| Site Overview | Так | Так |
| Керування користувачами, темами, плагінами | Так | Так |
| Quick Updates | Так | Так |
| WordPress Single Sign-On | Так | Так |
| Централізована панель керування | Так | Так |
| Safe Updates (staging-клон + регресійне тестування) | Ні | Так |
| Заплановані автоматичні оновлення | Ні | Так |
| Моніторинг продуктивності сайту | Ні | Так |
| Журнали активності | Ні | Так |
| Історія оновлень | Ні | Так |
Basic — це не урізана пробна версія. Вона включає справжній огляд сайту, можливість керувати користувачами, темами й плагінами, не заходячи в wp-admin, одноразовий вхід WordPress Single Sign-On, Quick Updates і, що важливо, саму централізовану панель керування.
Cloudways не сховав базовий досвід “бачити всі свої сайти в одному місці” за платною стіною. За стіною залишили все те, що робить цю панель достатньо надійною, щоб діяти через неї без постійного нагляду.
Pro наразі доступний безплатно під час Public Preview, незалежно від вказаної ціни, яка становить $3 за застосунок на місяць, зменшуючись до $2 за застосунок після перевищення п’яти застосунків.
Цю межу зі знижкою варто порахувати до того, як вважати, що Pro масштабується дешево:
| Керовані сайти | Вартість Pro (стикерна ціна) |
|---|---|
| 3 сайти | $9/month |
| 5 сайтів | $10/month ($2/app) |
| 10 сайтів | $20/month |
| 25 сайтів | $50/month |
| 50 сайтів | $100/month |
Жодна з цих сум не є нерозумною порівняно з тим, скільки може коштувати один зламаний, нестверджений апдейт у втраті довіри клієнта, але ціноутворення за кожен застосунок означає, що рахунок зростає по прямій лінії разом із вашим портфоліо, а не стрибкоподібно, як у деяких конкуруючих інструментів на вищих рівнях.
Після онбордингу та ціноутворення решта цього огляду присвячена тому, як це виглядає у щоденному використанні, починаючи з архітектурного моменту, який варто зрозуміти.
Це частина дизайну Site Manager, на яку я витратив найбільше часу, щоб по-справжньому розібратися, і в інтерфейсі це ніде не пояснюється.
Це троє дверей в одну й ту саму кімнату. Перегляд окремої програми призначений для людини, яка вже працює в межах конкретного сайту й раптом помічає очікуване оновлення. Меню дії на рівні облікового запису — для того, хто переглядає все портфоліо й вирішує діяти щодо одного сайту прямо зараз.
Вкладка планування — для того, щоб прибрати людину з цього циклу взагалі.
Із трьох дверей, описаних щойно, цей розділ охоплює перші дві — перегляд окремої програми та дію з рядка на рівні облікового запису, оскільки обидві відкривають той самий механізм оновлення.
Кожен план включає Quick Update. Застосування займає секунди: оновлення встановлюється безпосередньо на продакшн без перевірки сумісності й без попереднього створення резервної копії.
Власний текст інтерфейсу Cloudways чесно говорить про компроміс, попереджаючи, що він “may carry risks if updates aren’t compatible.”
Я не запускав Quick Update в цьому тесті, тож не можу з власного досвіду описати, як виглядає невдалий випадок на екрані. Це реальна прогалина в цьому огляді, і я б ставився до будь-яких тверджень про поведінку при збої Quick Update, як від мене, так і від будь-кого, хто не запускав його, з належним скепсисом.
Safe Update — це та функція, через яку Pro виправдовує свою ціну, і її варто розглянути повністю, тому що процес складніший, ніж “backup, then update.”
Ось як саме я його запустив. Із таблиці Overview на рівні облікового запису в Integrations → Site Manager я знайшов рядок для застосунку з очікуваними оновленнями й натиснув трикрапкове меню Actions в кінці цього рядка. Відкрилися чотири опції: WP-Admin, App Overview, Manage Updates і Manage Plan. Я натиснув Manage Updates.
Це відкрило модальне вікно зі списком усіх плагінів, для яких є оновлення, у моєму випадку чотирьох: Breeze, Elementor, Object Cache Pro і WP ULike, кожен позначений прапорцем із поточною версією та версією, до якої він оновиться.
Нижче списку було дві радіо-опції: Quick Update і Safe Update, кожна з коротким описом компромісу. Я вибрав Safe Update і натиснув Proceed.
Замість одного індикатора прогресу модальне вікно, що відкрилося далі, показує покроковий чекліст, який оновлюється в реальному часі.
Staging environment:
Production:
Я почав запуск о 6:21 pm, а завершився він о 6:27 pm. Шість хвилин для чотирьох плагінів у повному циклі staging-then-production. Саме в модалі сказано, що це “usually takes less than a minute,” і мій запуск перевищив цю оцінку з великим запасом.
Цю різницю між заявленою оцінкою та фактичним часом варто враховувати в плануванні, а не дивуватися їй, якщо ви запускаєте Safe Update для пакета плагінів у вікно техобслуговування: закладайте хвилини, а не секунди, особливо коли кількість плагінів зростає.
Сповіщення про успіх підтвердило результат, і щойно все завершилося, вкладка History на рівні облікового запису зафіксувала це як “On-Demand Successful: Plugins (4)” із посиланням на повні деталі.
Таке замикання циклу — бачити, як дія відбувається, а потім одразу мати можливість вказати на постійний запис про неї — це саме той тип доказу для клієнта, який потрібен агентству, і SafeUpdates ніколи цього не давав.
Обидва ці параметри знаходяться всередині процесу планування, а не в екрані одноразового оновлення, тому їх легко не помітити:
Разом ці два значення за замовчуванням вирішують, чи прокинетеся ви після нічного запуску оновлень із одним позначеним плагіном у черзі, чи з цілим сайтом, що застряг посеред оновлення через одну несумісну тему. Варто перевірити обидва перед тим, як довіряти будь-якому розкладу без нагляду.
Це охоплює перші двоє дверей. Цей розділ охоплює третє: повне усунення людини з цього процесу. Вкладка Auto Updates, до якої можна дістатися з тієї самої сторінки Site Manager на рівні облікового запису, — це місце, де обіцянка “керувати багатьма сайтами так, ніби це один” або справджується, або розвалюється. У моєму випадку — справдилася.
Ось як саме я її налаштував. З Integrations → Site Manager я натиснув вкладку Auto Updates у верхньому рядку.
Оскільки нічого ще не було заплановано, сторінка показала порожній стан, “No Auto Updates Schedule,” з однією кнопкою: Set Auto Update Schedule.
Натискання відкрило майстер “Set Auto Update Schedule,” який проходив через таке за один цикл:
Потім відкрився другий екран, “Create Auto Update Schedule,” який охоплював:
Натискання Set AutoUpdate Schedule внизу зберегло налаштування, застосувавши його до кожної програми, яку я вибрав на другому кроці, без потреби повторювати конфігурацію для кожного сайту окремо.
Троє дверей і механіка оновлень за ними описують процес. Ця остання функція описує доказ: постійний запис того, що сталося, окремо від самого процесу оновлення.
Ось як саме я її ввімкнув.
На сторінці Site Manager Overview окремої програми, тій самій, на яку ви потрапляєте після підписки через Шлях 1, поруч із круговим індикатором продуктивності є картка з написом “Activity Logs are Disabled”, коротким описом і єдиною кнопкою: Enable Activity Logs.
Я натиснув її, і картка оновилася одразу, без вікна підтвердження, без додаткових кроків. Перевіривши одразу після цього таблицю Manage Applications на рівні облікового запису в Integrations → Site Manager, я побачив, що стовпець Activity Logs для цього застосунку вже змінився з Disabled на Enabled, без потреби оновлювати сторінку.
Ця функція знаходиться за Pro і існує для відповіді на запитання, яке рано чи пізно ставить кожен клієнт агентству: хто що змінив і коли?
Без неї ця відповідь зазвичай живе в плагіні журналювання WordPress, який записує все у власну базу даних сайту, що з часом розростається і не захищає від підробки. Мати цей запис поза самою інсталяцією WordPress, на рівні хостингу, — це значно інший рівень довіри для всього, що пов’язане з клієнтами.
Коли весь набір функцій, його вартість і слабкі місця вже на столі, останнє питання — чи підходить це саме вашому портфоліо.
Найочевидніше це підходить агентству або фриланс-розробнику, який керує кількома, а в ідеалі багатьма WordPress-сайтами, що вже повністю живуть у Cloudways, де зламане оновлення коштує реальної втрати довіри клієнта, а не просто особистої незручності.
Safe Update і масове планування створені саме для того, щоб вирішити проблему, яка з’являється, коли ви вже перейшли межу, за якою перевіряти кожен сайт окремо ще розумно.
Це частково підходить тим, у кого змішане портфоліо. Безплатний плагін Site Manager може підключати зовнішні сайти для базового моніторингу та оновлень, але функції, які роблять нативну панель вартісною, staging-орієнтований Safe Update, візуальна регресія, журнали активності, залишаються недоступними, доки ці сайти не переїдуть на Cloudways.
Для власника одного сайту це просто непотрібно. Безплатний рівень технічно працював би, але весь продукт існує, щоб вирішити задачу масштабу портфоліо, якої один сайт ніколи не створює.
Так, site manager варто впроваджувати, але за однієї умови: ваші сайти вже живуть на Cloudways. У цих межах Site Manager виконує те, що обіцяє: справжню панель для кількох сайтів, шлях Safe Update, який створює резервну копію перед тим, як торкнутися продакшну, і масове планування, що розглядає оновлення як дію для всього флоту, а не як щоденну окрему рутину входу.
Поза цими межами це легший інструмент із чітким натяком на міграцію. Найкраще він підходить агентству, яке консолідує клієнтські сайти в Cloudways і потребує одного місця, щоб доводити, що і коли змінилося.
| План | ЦП | ОЗУ | Трафік | Гарантія | Ціна | |
|---|---|---|---|---|---|---|
| 25GB | 1 ядро | 1 ГБ | 1 ТБ | 0 ₴ | 500 ₴ | Детальніше |
| 50GB | 1 ядро | 2 ГБ | 2 ТБ | 0 ₴ | 1 080 ₴ | Детальніше |
| 80GB | 2 ядра | 4 ГБ | 4 ТБ | 0 ₴ | 2 060 ₴ | Детальніше |
| Description | Expert Review |
|---|---|
| Керований WordPress-хостинг із швидкістю, безпекою... | Read Wordpress Hosting Review |
| Гнучкий, високопродуктивний хмарний хостинг і... | Read Cloud Hosting Review |
| Безпечний та ефективний хостинг електронної п... | Read Email Hosting Review |
| Оптимізований хостинг Magento з високою швидкіст�... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
Так. Cloudways Site Manager — це вбудований додаток, який централізує оновлення, моніторинг продуктивності та журнали активності для WordPress-застосунків, уже розміщених у вашому обліковому записі Cloudways. Окремий безкоштовний супровідний плагін розширює функції легкого моніторингу та оновлення для WordPress-сайтів, розміщених будь-де.
Не через рідну панель керування, протестовану в цьому огляді, оскільки вона обмежена застосунками, уже розміщеними на Cloudways. Безкоштовний плагін, також під назвою Cloudways Site Manager і спільно розроблений із WP Remote, може підключати зовнішні сайти для моніторингу та оновлень ядра, плагінів і тем, але без staging-клону Safe Update, візуального регресійного тестування чи кешування на рівні сервера.
Базовий тариф безкоштовний і охоплює огляд сайту, керування користувачами й плагінами та Швидкі оновлення. Pro додає Безпечні оновлення, планування, моніторинг продуктивності та журнали активності за $3 на застосунок щомісяця, знижуючись до $2 для п’яти або більше застосунків, і наразі є безкоштовним для використання під час Публічного попереднього перегляду.
Швидке оновлення застосовує зміни безпосередньо до продуктивного середовища за лічені секунди без резервного копіювання чи перевірки сумісності. Безпечне оновлення створює клон для staging, перевіряє сумісність, оновлює кожен пакет, запускає візуальний регресійний тест і лише тоді переносить зміни в продуктивне середовище, якщо цей тест успішний.
Так. Нові застосунки ніколи не підключаються автоматично, навіть якщо їх додано на сервер, на якому вже працюють інші застосунки Site Manager. Для кожного сайту потрібен окремий крок початкового налаштування — індивідуально або через масовий майстер у розділі Integrations.
Дайте відповідь на декілька простих питань і знайдіть ідеальне рішення для вас!
Почати пошук хостингу
HostAdvice.com пропонує професійні і незалежні відгуки про веб-хостинги. Наші відгуки є чесними, неупередженими і рівними для всіх учасників.
Ми отримуємо грошову винагороду від компаній, про які пишемо. Винагорода не впливає на характер і лояльність наших відгуків. Так само, це жодним чином не впливає на позиції певних компаній в рейтингах. Винагорода лише покриває витрати на плату рецензентам, купівлю акаунтів і вартість тестів.
