Керування хостингом зазвичай перериває розробку. Ви пишете код в редакторі, відкриваєте панель хостингу, щоб створити сайт, перемикаєтеся на термінал, щоб запакувати або запушити проєкт, повертаєтеся до панелі, щоб перевірити розгортання, і відкриваєте ще більше інструментів, коли потрібно зайнятися DNS, журналами або ресурсами сервера.

Hostinger Connector зменшує це перемикання контексту. Він підключає сервіси Hostinger до AI-інструментів для кодування через Model Context Protocol (MCP), дозволяючи вам попросити AI-асистента перевірити або керувати підтримуваними хостинговими ресурсами, не виходячи з редактора.

Звучить зручно. Але це також піднімає важливіше питання: Чи можна довіряти AI-асистенту виконання реальних хостингових завдань точно?

Щоб це з’ясувати, я протестував Hostinger Connector із VS Code та GitHub Copilot на реальному обліковому записі Hostinger. Я використав невеликий Express.js-додаток під назвою PulseWatch і пройшов шлях від встановлення до живого розгортання. Я також протестував повторні розгортання, журнали збірок, логи та відновлення після того, як навмисно зламав команду запуску застосунку.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger

Переваги та недоліки Hostinger Connector

Оцінювання

Ось як я оцінив Hostinger Connector за тими напрямами, які найважливіші для розробника, що вирішує, чи варто ним користуватися: вартість, спектр функцій, щоденна зручність, точність виконання реальних завдань і підтримка, яка є за ним, коли щось іде не так. Кожна оцінка відображає те, що я фактично виявив під час тестування, а не сторінку з маркетингу.

Плани та ціни Hostinger Connector

Hostinger Connector не продається як окремий продукт. Hostinger зазначає, що Connector входить безкоштовно до кожного плану, а отже, немає окремої щомісячної плати за Connector, яку потрібно було б додавати до рахунку за хостинг.

Однак «безкоштовно» потребує контексту. Connector керує ресурсами Hostinger; він не замінює їх. Вам усе одно потрібен відповідний хостинг, cloud, VPS, домен, email або інший сервіс Hostinger для завдань, які ви хочете через нього виконувати.

На момент цього огляду на сторінці Connector були виділені Business Web Hosting і Cloud Startup.

Ціни були показані до застосування податків. Акційні ціни та тариф на продовження можуть змінюватися, тож перевіряйте актуальну суму при оформленні замість того, щоб судити про план лише за рекламованою місячною цифрою.

Ціновий висновок: Не купуйте вищий план лише для доступу до Connector. Обирайте план відповідно до кількості вебсайтів і вебзастосунків, які вам потрібні, ресурсів, яких вони потребують, і рівня підтримки, який ви хочете отримати. Connector — це включений рівень керування, а не основний продукт, який тут оцінюється.

Hostinger рекламує 30-денну гарантію повернення коштів для відповідних покупок хостингу. Окремої політики відшкодування Connector немає, оскільки Connector не має окремої плати.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger

Функції

• Розгортання Node.js-застосунків
• Розгортання PHP та HTML
• Керування WordPress-сайтами
• Робочі процеси Website Builder і Horizons
• Розгортання, пов’язані з GitHub
• Підключення та організація доменів
• Перевірка та оновлення DNS
• SSL і діагностика вебсайтів
• Керування базами даних
• Налаштування та адміністрування VPS
• Розгортання Docker-проєктів
• Моніторинг CPU та пам’яті
• Перевірка пропускної здатності та диска
• Перезапуск сервісів і контейнерів
• Сканування на шкідливе ПЗ
• Відновлення резервних копій
• Налаштування email-кампаній
• Перевірка розгортань і збірок

Точні дії, доступні через систему, залежать від сервісів Hostinger у вашому обліковому записі та інструментів, відкритих для підключеного AI-клієнта.

Hostinger також документує обмеження швидкості. Згідно з FAQ Connector, значення за замовчуванням становить 60 запитів на хвилину та 1,000 запитів на годину, а інформація про ліміти повертається в заголовках відповіді.

Такі ліміти цілком достатні для інтерактивного використання, хоча автоматизовані або дуже повторювані робочі процеси все одно мають уникати зайвих дублюючих викликів.

Зручність використання

1. Встановлення та автентифікація

Перш ніж я міг оцінити, чи Hostinger Connector добре розгортає та керує хостингом, мені потрібно було зрозуміти, що взагалі потрібно для запуску.

Інструмент, створений для того, щоб залишатися всередині редактора, швидко втрачає привабливість, якщо налаштування вимагає редагування конфіг-файлів, генерації API-токенів або повторної автентифікації. Цей розділ охоплює лише налаштування. Практичне тестування завдань іде відразу після нього.

Встановлення розширення

Я встановив Hostinger Connector з VS Code Marketplace. Він з’явився як перший результат, коли я шукав “Hostinger”, у полі видавця був Hostinger Official, і він установився з першої спроби менш ніж за дві хвилини.

Останній рядок вартий застереження. П’ять зірок звучать сильно, але вибірка з двох відгуків майже нічого не каже мені про типову взаємодію користувачів. Я не став би спиратися на це число в тексті огляду.

Одна передумова мене здивувала: Hostinger Connector надає інструменти Hostinger, але йому потрібен уже активний AI-агент у редакторі, щоб фактично викликати їх.

Саме розширення не має з ким спілкуватися самостійно. У VS Code таким агентом є GitHub Copilot Chat, оскільки саме він наразі є AI-інтерфейсом, який VS Code відкриває для викликів MCP-інструментів. У мене Copilot уже був активований, тож це не сповільнило роботу, але читачам варто знати, що Connector корисний лише настільки, наскільки корисний AI-агент, який стоїть за ним.

Без встановленого та авторизованого агента немає до чого під’єднуватися.

Встановлення не вимагало:

• API-ключа
• Токена, скопійованого з hPanel
• Ручного редагування MCP-файлу конфігурації
• Локально збережених облікових даних
• Користувацької команди сервера

Встановлення самого розширення було однією з найпростіших частин усього тесту. Єдина справжня особливість — це залежність, яку Hostinger не подає на перший план: розширенню потрібен активний AI-агент у вашому редакторі, інакше воно нічого не зробить.

Після встановлення розширення наступне питання було в тому, чи так само просто буде підключити його до реального облікового запису.

Підключення облікового запису

Підключення облікового запису відбувалося через OAuth за допомогою кнопки “1-Click Connect”. VS Code відкрив сторінку авторизації Hostinger у браузері, виявив мою наявну сесію Hostinger і попросив мене схвалити доступ для того, що називалося hostinger-mcp.

Після того, як я натиснув Allow, мене повернуло до VS Code з повідомленням “Connected via OAuth”.

Екран авторизації повідомив, що Connector може керувати вебсайтами, хостингом, доменами, підписками та іншими сервісами Hostinger.

Це список категорій, а не детальний перелік дозволів по пунктах. Мені хотілося б більшої деталізації тут, адже “керувати підписками” і “керувати вебсайтами” — це дуже різні рівні ризику.

Що дало мені трохи більше контролю — це окрема панель у розширенні, яка перелічувала всі категорії інструментів і дозволяла вмикати або вимикати кожну окремо:

Це 199 інструментів загалом, із 125 увімкненими за замовчуванням. Я залишив Ecommerce і VPS вимкненими, доки не був готовий протестувати їх безпосередньо, і розширення поважало цю межу протягом усього тестування.

Це саме та деталь безпеки, яка не відображається на маркетинговій сторінці Hostinger, але має значення для всіх, хто вирішує, скільки доступу до облікового запису передати AI-асистенту. Я б назвав це справжньою перевагою.

Від’єднання облікового запису доступне з тієї ж панелі, без потреби змінювати пароль Hostinger або шукати збережений токен.

Авторизація була швидкою і не вимагала керування токеном з мого боку, але екран дозволів є широким, а не детальним. Контролі категорій інструментів у самому розширенні краще обмежують реальний ризик, ніж екран OAuth.

Підтримувані редактори

Hostinger вказує підтримку таких клієнтів, зібраних із власного екрана початкового налаштування розширення:

Я використовував VS Code із GitHub Copilot як основне середовище тестування.

Налаштування показало мені, що Connector легко запустити. Воно ще нічого не сказало про те, чи справді він добре виконує роботу після підключення, а це складніше питання, до якого я перейшов далі.

2. Hostinger Connector у дії

Встановити та підключити розширення — це легка частина. Насправді важливо, чи добре воно виконує реальну хостингову роботу, тож я створив невеликий Express.js-застосунок під назвою PulseWatch і прогнав Connector через той самий шлях, який пройшов би розробник після встановлення: перевірити обліковий запис, знайти ціль розгортання, розгорнути проєкт, оновити його, переглянути результати та відновитися після навмисно створеної мною помилки.

PulseWatch був навмисно простим: Express-сервер, домашня сторінка, стартовий скрипт package.json і /api/health endpoint, що повертає JSON. Цей health endpoint згодом виявився важливим.

Хостингова платформа може повідомляти про завершену збірку, навіть коли застосунок не запускається. Живий endpoint дав мені незалежний спосіб перевірити, чи розгорнутий процес справді відповідає, а не просто довіряти значку статусу.

Читання даних облікового запису

Я почав із запитів лише для читання, перш ніж дозволяти асистенту наближатися до живих змін. Якби він не міг точно описати мій обліковий запис, у мене було б мало причин довіряти йому розгортання, DNS або VPS-дії.

Інструмент перелічення вебсайтів Connector повернув п’ять сайтів:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Мій обліковий запис насправді містив більше. hPanel показував вебсайти, розподілені між планами Premium, Business і Growth, включно з WordPress-сайтами, PHP/HTML-сайтами, проєктами Website Builder і кількома тимчасовими доменами.

На окремому запиті про мої активні хостингові плани асистент сказав, що в мене “one active hosting plan”. hPanel показував три: Premium, Growth і Business.

Справедливо буде сказати, що коли я вказав на розбіжність, він виправився, чітко відокремив те, що перевірив, від того, що припустив, і не повторив хибне твердження.

Це кращий спосіб помилки, ніж вперте наполягання, але це означає, що першу відповідь на запитання про весь обліковий запис не варто сприймати як безумовну істину.

Читання доступу спрацювало, але перша відповідь на будь-яке запитання про весь обліковий запис була неповною. Після заперечення він виправився, і це важливо, але мені не слід було змушувати його виправлятися.

Ця прогалина у видимості облікового запису виявилася передвісником більшої проблеми. Справжнім тестом того, чи це має значення, стало те, коли я попросив Connector знайти вебсайт, про який його не попереджали за назвою.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger

Пошук цілі розгортання

Ось тут тестування показало найбільше. Я попросив асистента ідентифікувати щойно створений Node.js-сайт, не називаючи його домен, і не торкаючись жодного наявного сайту.

Вибір цілі — це базова вимога безпеки для інструменту, який може діяти в живому обліковому записі, тож я хотів подивитися, як він поводиться в умовах невизначеності, а не коли відповідь очевидна.

Ось що сталося, по порядку:

Коренева проблема: два IDs, які він використав, були resource IDs домену, а не hosting order IDs. Він ніколи не підтвердив цю різницю перед тим, як викликати інструмент створення живого вебсайту з їх використанням.

Коли я попросив його пояснити себе, асистент зрештою дав точний опис: у нього весь час був доступний працюючий інструмент переліку вебсайтів, але він не викликав його знову після того, як я створив новий сайт через hPanel, тому заповнив прогалину неперевіреним доменом замість того, щоб оновити свої дані.

Коли я прямо попросив його повторно запустити цей інструмент переліку та перевірити, чи з’явився новий запис, він замість цього викликав три не пов’язані між собою інструменти пошуку розгортань і повідомив, що “no new website appeared”, хоча висновок, який випливав із фактичних викликів, не міг би цього підтримати.

Усе це не створило жодного зайвого вебсайту в моєму обліковому записі. Невдалі виклики нічого не залишили після себе. Але цей патерн варто назвати прямо. Маючи неповні дані, асистент заповнив прогалину правдоподібним припущенням, сприйняв слабкий сигнал як сильний доказ і діяв на живому обліковому записі до того, як це припущення було перевірено.

Це найважливіший висновок у цьому розділі. Connector буде вгадувати ціль і діяти на основі цього припущення замість того, щоб зупинитися й запитати. Тут він безпечно зазнав невдачі, але звичка сприймати слабкий сигнал як доказ — це те, на що слід звернути увагу у власному обліковому записі.

Оскільки Connector не зміг самостійно знайти ціль, у мене залишився лише один варіант: створити ціль самостійно й подивитися, чи щось зміниться.

Завершення налаштування в hPanel

Оскільки Connector не міг надійно знайти нову ціль самостійно, я завершив початкове налаштування вручну через hPanel, щоб побачити, що Hostinger готує до того, як стане можливим розгортання через Connector.

Шлях був такий: Create a new site → Node.js web app → тимчасовий домен → Hostinger автоматично вибрав data center у Великій Британії з розрахованою затримкою 147ms → вибір із трьох способів розгортання.

Той третій екран вартий окремого зауваження. Hostinger пропонує “Build with Hostinger Connector” як спосіб розгортання поряд із GitHub import і manual file upload. Я обрав його, очікуючи, що він завершить налаштування сайту.

Натомість мене перенаправило на сторінку встановлення самого Connector, яке я вже завершив. Це справжня прогалина в онбордингу. Варіант, представлений як нативний шлях через Connector, фактично нічого не provision-ив.

Я повернувся назад і вибрав manual file upload. Hostinger прийняв мій архів проєкту (11.46 KB, із виключеними node_modules ), а екран налаштувань показав точне авто-визначення:

• Framework preset: Express
• Node version: 22.x
• Root directory: ./

Я натиснув Deploy. Воно успішно завершилося, і Hostinger призначив справжній тимчасовий домен: orange-walrus-700988.hostingersite.com. Це інший домен, ніж той, який Connector вигадав раніше. Я відкрив і домашню сторінку, і /api/health вручну та підтвердив, що обидва працюють.

Ручний шлях спрацював без тертя, щойно я перестав чекати, що Connector знайде його сам. Кнопку “Build with Hostinger Connector” на цьому екрані слід виправити або прибрати. Зараз вона обіцяє те, чого не робить.

Тепер існував реальний, підтверджений вебсайт. Наступне питання було в тому, чи поводитиметься Connector інакше, коли матиме щось реальне для пошуку.

Розгортання та оновлення живого застосунку

Коли реальний, підтверджений вебсайт уже існував, я повернувся до Connector і попросив його перевірити саме цей домен. Цього разу він спрацював чисто.

Це підтвердило важливу річ: попередні збої стосувалися пошуку та створення нової цілі, а не здатності Connector працювати з Node.js-сайтом, коли такий уже існує.

Далі я протестував функцію, яку Hostinger просуває найактивніше: внести локальну зміну в код і опублікувати її, не відкриваючи hPanel.

Я попросив асистента змінити один рядок тексту на головній сторінці з “Monitor Every Service. Catch Every Issue.” на “Monitor Every Service. Resolve Issues Faster.”

Увесь апдейт зайняв близько однієї хвилини. Асистент одразу після відправлення повідомив про нове розгортання як “pending”, просто тому, що перевірив до того, як Hostinger завершив обробку.

До того моменту, коли я оновив live-сайт самостійно, новий заголовок уже був там.

Отримані ним після цього журнали збірки були конкретними та корисними: 67 package додано, 68 перевірено, жодної вразливості не знайдено, помилок немає.

Для вже наявних сайтів це майже той робочий процес, який обіцяє Hostinger. Відредагувати, перевірити локально, відправити і підтвердити — усе без виходу з редактора, приблизно за одну хвилину. Це найсильніший результат у всьому тесті.

Чисте розгортання ще не каже мені, що щасливий шлях працює. Щоб з’ясувати, що Connector насправді робить під тиском, я навмисно зламав застосунок.

Тестування відновлення після збою

Інструмент заслуговує довіри лише тоді, коли витримує реальний збій, а не просто чисту демонстрацію. Я навмисно зламав застосунок, щоб побачити, чи справді статуси та логи Connector можуть допомогти мені діагностувати проблему.

Перед будь-якими змінами асистент створив резервну копію package.json як package.json.bak, що само по собі є гарною практикою.

Потім я попросив його змінити start script із “start”: “node server.js” на “start”: “node missing-server.js”, файлу якого не існує.

Запуск локально підтвердив реальний, відтворюваний збій: Error: Cannot find module ‘…/missing-server.js’.

Я навмисно розгорнув зламану версію, щоб подивитися, що повідомить Hostinger.

Журнали збірки, доступні через Connector, показували успішне встановлення залежностей і більше нічого. Помилка виконання через відсутній модуль у них так і не з’явилася. Розробник, який кинув би лише погляд на зелений значок “completed”, не мав би жодних причин підозрювати, що сайт зламаний.

Відновлення пройшло гладко. Асистент відновив package.json із резервної копії, перевірив застосунок локально, повторно розгорнув його і підтвердив виправлення, звернувшись безпосередньо до live /api/health endpoint замість того, щоб вірити лише статусу розгортання.

Цей endpoint повернув працездатну відповідь, і це був єдиний доказ у всьому тесті, який справді підтвердив, що застосунок запущений.

Це другий важливий висновок. Статус “completed” не є доказом того, що застосунок працює, і власні логи Connector не скажуть вам про це. Саме відновлення працювало добре, щойно я зрозумів, що є проблема, яку треба відновлювати.

Після збою, який статусний значок не міг показати, я захотів дізнатися, де ще впевненість Connector може випереджати його реальні можливості. Наступним тестом були змінні середовища.

Спроба налаштування змінних середовища

Я попросив асистента додати нешкідливу змінну середовища, спочатку підтвердити, що існує окрема можливість Connector для цього, і зупинитися, якщо такої немає.

Він перевірив доступні інструменти, не знайшов окремої дії для керування змінними середовища Node.js і зупинився, не вносячи жодних змін у код чи розгортання.

Це та поведінка, яку я хотів бачити і в інших місцях цього тесту. Зіткнувшись із реальною межею, він зупинився, замість того щоб здогадуватися. Я не робив би висновок, що Hostinger Connector не має підтримки змінних середовища взагалі в своєму наборі інструментів, лише те, що під час цього тесту така дія не була доступна. 

Підсумок тесту відмови та відновлення

Що тест говорить про надійність

Hostinger Connector добре виконував рутинні, детерміновані завдання:

• Читання відомих записів розгортання
• Редагування конкретного файлу
• Запуск локальних команд
• Пакування проєкту
• Розгортання на відомий вебсайт
• Перевірка статусу збірки
• Отримання доступних логів
• Відновлення і повторне розгортання відомої робочої версії

Він був слабшим, коли завдання вимагало інтерпретації неповних даних облікового запису:

• Визначення щойно створеного вебсайту
• Розрізнення доступності домену та існування вебсайту
• Визначення того, чи означає завершена збірка, що застосунок здоровий

Цей патерн корисний, коли вирішуєте, скільки автономії надати асистенту.

Використовуйте ширші запити для низькоризикового перегляду. Використовуйте точні запити та явні вимоги до підтвердження для дій, які змінюють живу інфраструктуру.

Наприклад, замість:

використовуйте:

Другий запит звужує простір для припущень з боку асистента.

Загальний висновок щодо зручності використання

Запустити Hostinger Connector було легко, без звичного тертя під час налаштування, а детальні контроли категорій інструментів дали мені реальний контроль над тим, до чого може торкнутися AI.

Коли вже існував реальний вебсайт із відомим доменом, він добре впорався із завданням: змінити один рядок коду від редагування до живого сайту приблизно за хвилину, із корисними журналами збірки.

Проблема з’явилася раніше в процесі, а не пізніше. Зіткнувшись із новою ціллю, яку він не міг знайти, Connector вигадав домен і почав діяти на ньому, перш ніж перевірити. Він також позначив зламане розгортання як “completed”, хоча застосунок насправді не працював, і в його власних логах не було runtime-помилки. Жодна з цих проблем не робить інструмент ненадійним для вже існуючих сайтів, але обидві означають, що нові розгортання та пост-деплойний статус потребують повторної перевірки перед тим, як їм довіряти.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger

Рівень підтримки

Hostinger будує підтримку навколо live chat і самообслуговування, а не телефонних дзвінків, тому я зосередив тест там, де більшість користувачів насправді опиняться: AI-асистент, вбудований у hPanel, ескалація до людини за ним і база знань, до якої розробник звернеться перед відкриттям чату взагалі.

Канали підтримки

Оскільки live chat — це канал, на який Hostinger спрямовує розробників для всього термінового, і той, який найімовірніше використовуватимуть під час налагодження розгортання, я протестував саме цей шлях, а не надсилав email-тicket.

Live Chat: Kodee та передача людині

Я відкрив live chat через “Ask AI” у hPanel і поставив Kodee запитання з реальною відповіддю, яку можна було дати неправильно: чи гарантує статус завершеної збірки на Node.js-розгортанні, що застосунок справді працює, і де я знайду інші докази.

Перша відповідь Kodee була конкретною і правильною:

“Completed” зазвичай означає, що етап збірки завершився успішно; це не гарантує, що застосунок здоровий після запуску. Щоб виявити неправильну команду запуску або інший runtime-збій, перевірте runtime logs: у hPanel перейдіть до Websites → Dashboard → Deployments за build logs, а потім відкрийте stderr.log у папці nodejs для помилок запуску на кшталт Port already in use або Module not found.

Ця одна відповідь могла б розв’язати ту саму неоднозначність, у яку мій тест на відновлення після збою вперся раніше в цьому огляді. Kodee назвав реальний файл логів, правильну папку й чітко відмежував успішну збірку від працездатності під час запуску.

Однак я також хотів побачити, чи зможу отримати доступ до справжнього живого оператора, тож я сказав Kodee, що хочу підтвердити це безпосередньо зі спеціалістом підтримки.

Але  отримати людину на лінію було складніше, ніж я очікував. Я прямо попросив живого агента й двічі отримав перенаправлення назад до Kodee, кожного разу під приводом, що це швидше, ніж чекати:

Розумію, чому ви цього хочете. Я можу допомогти вам перевірити збірку, start command і runtime logs прямо тут, що зазвичай є найшвидшим способом визначити проблему.

Перш ніж передати спеціалісту. Я можу розв’язати проблему і заощадити вам очікування.

Потрібно було два прямі, чіткі запити, перш ніж Kodee перестав повертати мене до себе. Для запитання, яке я міг би розв’язати сам, таке тертя незначне. Для людини в середині збою, яка хоче поговорити з людиною, це справжнє джерело роздратування.

Те, що сталося далі, не було live handoff у тому сенсі, в якому зазвичай розуміють “connect me with a human”. Kodee прямо пояснив реальну модель:

I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.

Це асинхронний перегляд, а не живе передавання. Kodee залишається інтерфейсом; людина переглядає транскрипт у фоновому режимі, а Kodee передає відповідь, коли вона з’явиться. Ця різниця важлива для читачів, які вирішують, чи ескалювати запит, оскільки “human agent” тут не означає, що нова людина приєднується до вікна чату так, як це було б у більшості live chat-систем.

Я продовжив той самий технічний ланцюжок, поки чекав, і попросив Kodee підтвердити точний шлях до логів і чи stderr.log завжди заповнений. Він сам по собі дав надійну відповідь, правильно зазначивши, що лог може бути порожнім, якщо застосунок ніколи повністю не запустився або записав помилку в інше місце.

Перегляд спеціаліста надійшов приблизно за 3 хвилини, у чаті він був підписаний від імені колеги на ім’я Mayas, і він доповнив відповідь Kodee, а не просто повторив її:

domains/[your-domain]/nodejs/stderr.log — це правильне місце. Воно не завжди створюється або заповнюється. Ви побачите записи там лише тоді, коли застосунок пише в stderr, наприклад, через uncaught exceptions або unhandled rejections. Якщо команда запуску неправильна і процес завершується безшумно, stderr.log може бути порожнім або відсутнім.

Mayas також додав два резервні перевірки, яких не згадував Kodee: перевірку stdout.log на останній вивід перед падінням і пошук відсутнього рядка підтвердження запуску як ознаки того, що застосунок взагалі не стартував.

База знань

База знань Hostinger організована за широкими категоріями продуктів: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel і About Hostinger.

Жодна з цих категорій не присвячена Hostinger Connector. Єдиний спосіб знайти потрібну статтю — шукати “Hostinger Connector” безпосередньо, що повернуло п’ять результатів, більшість із яких лише побічно стосувалися теми, зокрема гайд по плагіну для affiliate marketing і загальну статтю про Node.js hosting.

Стаття, яка справді документує налаштування Connector, має назву “How to Set Up Web Hosting MCP on Local IDEs” і знаходиться в Features → General Information.

Пошук за маркетинговою назвою продукту знайшов її, але читач, який переглядає категорії або шукає “MCP” без знання брендингу Hostinger, може легко її пропустити, і невідповідність між маркетинговою назвою та назвою документації варто знати ще до того, як ви почнете шукати.

Сама стаття сильна, якщо її знайти. Востаннє її оновлювали за шість днів до мого тестування, і вона описує:

• Рекомендоване налаштування в один клік через OAuth у розширенні
• Ручний шлях налаштування з API-токеном для IDE, які розширення безпосередньо не підтримує
• Точні шляхи до файлів конфігурації для Mac, Linux і Windows
• Повні приклади JSON-конфігурацій
• Покроковий промпт для перевірки, чи підключення спрацювало
• Які підтримувані клієнти автоматично виявляють підключення, а які потребують ручного внесення конфігурації

Останній пункт збігався з тим, із чим я зіткнувся безпосередньо під час тестування: Devin Desktop виявляється автоматично, тоді як OpenAI Codex потребує ручного способу. Стаття правильно передає цю різницю.

Загальний висновок щодо підтримки

Перша відповідь Kodee на складне технічне запитання була точною й конкретною, і це не те, що вдається кожному AI-асистенту підтримки. Стаття бази знань, яка це підтверджує, є актуальною та деталізованою, коли ви її знайдете, хоча маркетингова назва продукту та назва документа не збігаються, тож пошук надійніший за перегляд категорій.

Слабке місце — шлях ескалації до людини. Kodee двічі повертав мене назад до себе, перш ніж задовольнити прямий запит на людину, і навіть тоді “human agent” означає асинхронний перегляд, переданий через той самий чат, а не live transfer. Коли людина таки подивилася на запит, відповідь була кращою за відповідь Kodee: точнішою і з двома додатковими діагностичними кроками, яких Kodee не запропонував.

Для більшості запитань Kodee сам по собі швидко дасть точну відповідь. Якщо вам справді потрібна людина, щоб підтвердити відповідь, будьте готові попросити більше ніж один раз і будьте готові до короткого очікування відповіді, переданої через чат, а не до живої розмови.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger

Фінальний висновок: чи варто використовувати Hostinger Connector?

Так, для розробників, які вже хостять на Hostinger і хочуть, щоб рутинні розгортання виконувалися прямо з редактора. Налаштування зайняло хвилини, OAuth позбавив потреби в API-ключах, а коли вебсайт уже існував із відомим доменом, Connector відправив live-оновлення приблизно за хвилину з логами як підтвердженням. Власні відповіді Kodee у підтримці були настільки точними, що вирішили реальне технічне питання з першої спроби.

Але проблема — у довірі, а не в зручності. Коли йому дали нову ціль, яку він не міг знайти, Connector вигадав домен і почав діяти на його основі, перш ніж перевірити.

Він також позначив зламане розгортання як “completed”, хоча застосунок насправді не працював, і в його власних логах не було runtime-помилки. Використовуйте його, щоб прискорити роботу із сайтами, які вже існують, перевіряйте все, що він робить на новій цілі, і перевіряйте live-сайт самостійно після будь-якого розгортання, яке має значення.

Hostinger

5.0

2,471 user reviews

80 ₴ /mo

Ціна від

Hostinger

Рейтинг на основі відгуків експертів

• Зручність
  4.9
• Підтримка
  4.9
• Можливості
  4.8
• Надійність
  4.7
• Ціни
  4.5