Hostinger побудував Web Apps Hosting навколо простого меседжу: запуште свій код із GitHub, ZIP-файл або свого AI coding agent, і отримайте живий production-застосунок приблизно за хвилину, без сервера, яким вам потрібно керувати. Я хотів зрозуміти, наскільки це відповідає дійсності, коли ви самі натискаєте deploy, тож ось що я з’ясував.

Розгортайте Web Apps швидше з Hostinger

Розгортайте сучасні web apps на Hostinger з автоматичними збірками, керованою інфраструктурою, глобальною CDN, SSL, інструментами безпеки та 30-денною гарантією повернення коштів.

Hostinger

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

Розподіл оцінки

Щоб оцінити Hostinger’s Web Apps Hosting, я застосував методологію оцінювання HostAdvice, той самий стандартизований підхід, який використовується в кожному огляді на сайті, тож оцінки залишаються прив’язаними до реального тестування, а не до маркетингових формулювань. Ось як він отримав бали за кожним параметром.

Розгорніть свої web apps без DevOps-метушні

Розгортайте сучасні web applications на повністю керованому хостингу з автоматизованими deploy, керованим SSL, глобальною CDN і вбудованими інструментами безпеки.

Hostinger

Плани та ціни

Hostinger продає Web Apps Hosting у двох тарифах, Business і Cloud Startup, обидва створені спеціально для розгортання Node.js та сучасних JavaScript-застосунків, а не для традиційного створення сайтів.

Cloud Startup, тариф, який я тестував, удвічі збільшує кількість застосунків і ядер CPU порівняно з Business, а обидва плани включають безкоштовний домен, безкоштовну бізнес-пошту та керований SSL на перший рік прямо в оформлення замовлення.

Кілька речей, які варто знати перед замовленням:

• Гарантія повернення коштів: Web Apps Hosting підпадає під стандартні умови повернення коштів Hostinger, це чітке 30-денне вікно від дати покупки. Це значно простіше, ніж для VPS-планів Hostinger, де діє додатковий 180-денний період очікування між запитами на повернення. Тут такого періоду очікування немає.
• Безкоштовний пробний період: Я не знайшов окремого безкоштовного пробного періоду. Вашим періодом оцінки є 30-денна гарантія повернення коштів.
• Способи оплати: Під час оформлення замовлення за замовчуванням відображалася оплата карткою, з логотипами Visa, Mastercard, Amex і Discover, а також із можливістю додати інший спосіб оплати під час оформлення.
• Що включено в пакет: Безкоштовний домен на один рік, безкоштовні поштові скриньки на один рік і керований SSL включені без додаткової плати понад вартість плану, тож цінник досить близький до реальної вартості запуску повноцінного, захищеного deploy.
• Єдине допродажне доповнення: Hostinger Reach, додаток для email-маркетингу, з’являється в кошику як окремий виділений блок із окремою щомісячною ціною. Його легко пропустити, і він не входить до пакета та не вибраний за замовчуванням.

Якщо ви скасуєте план Web Apps Hosting протягом 30 днів, політика повернення коштів Hostinger підтверджує, що він підпадає під стандартні умови, а не під список винятків, тож просте скасування в цей проміжок має право на повернення коштів без додаткових умов, які застосовуються до VPS або доменних покупок.

Функції

• Автовизначення фреймворку та версії Node
• Інструменти для створення керованої MySQL-бази даних
• Глобальна CDN увімкнена за замовчуванням
• У комплекті WAF і захист від DDoS
• Щоденні та on-demand резервні копії
• Сканер шкідливого ПЗ та сканування вразливостей
• Інтеграція з GitHub з auto-deploy
• Безкоштовний домен, email і SSL
• SSH-доступ для просунутих користувачів

Від коду до живого застосунку з Hostinger

Підключіть свій GitHub-репозиторій або завантажте свій проєкт і запустіть його онлайн із керованою інфраструктурою, автоматичними deploy і щоденними резервними копіями.

Hostinger

Продуктивність

Оскільки Web Apps Hosting повністю керований, ви ніколи не отримуєте shell-доступ до сервера, тож немає CPU, RAM чи диска, які можна було б бенчмаркнути безпосередньо так, як у VPS-огляді.

Що можна виміряти, так це швидкість завантаження і відповіді самого розгорнутого застосунку з реальних локацій по всьому світу. Я тестував це з чотирьох окремих ракурсів: GTmetrix із двох континентів, глобальну перевірку стабільності на понад 50 точках і вбудований інструмент швидкості Hostinger як для desktop, так і для mobile.

Застосунок під час тестування — це розгортання Next.js, описане в розділі Ease of Use нижче, доступне за адресою ivory-llama-856835.hostingersite.com, яке працює на плані Cloud Startup (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), із CDN, увімкненою за замовчуванням.

1. GTmetrix, протестовано з двох континентів

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

Обидва запуски дали ідеальні 100% як за Performance, так і за Structure, із нульовим layout shift і нульовим blocking time в обох локаціях, тобто нічого на сторінці не конкурувало за увагу браузера і не стрибало під час завантаження.

Справді цікава деталь полягає в тому, що Frankfurt насправді випередив Chicago за всіма часовими метриками, хоча я навмисно обрав для цього застосунку сервер у США. Цей результат має сенс лише з урахуванням CDN.

Коли CDN активна, як тут було за замовчуванням, ваш відвідувач не обов’язково звертається безпосередньо до origin-сервера.

Він звертається до найближчого edge-вузла кешу, тож європейська тестова точка може виявитися швидшою за американську, навіть якщо сам сервер розташований у США. Це реальне, практичне підтвердження того, що CDN Hostinger, увімкнена за замовчуванням, справді працює, а не просто висить як маркетинговий пункт.

2. Глобальна стабільність (Check-Host)

Я запустив HTTP-перевірку за живою URL-адресою з кожної контрольної точки, яку пропонує Check-Host, 54 локації на шести континентах. Повна картина така:

Кожна успішна перевірка повертала чистий 200 OK, без помилок, без часткових збоїв, без неочікуваних редиректів.

Час відповіді чітко показав, як працює кешування CDN у реальних відстанях:

Європейські контрольні точки стабільно повертали найшвидші значення, кілька — менш ніж за 50 мілісекунд, тоді як контрольні точки, фізично найдалі від будь-якого edge-вузла, Tokyo, Singapore, Ho Chi Minh City, усе одно повертали коректні 200 відповіді, просто повільніше, у діапазоні від 0.3 до 0.8 секунди.

Це очікувана картина для deploy із CDN: швидко поблизу edge-вузлів, але все ще повністю працездатно на далекій відстані від них.

Чотири тайм-аути, Kazakhstan, Romania і два з чотирьох російських контрольних пунктів, я б не читав як проблему інфраструктури Hostinger.

Інші контрольні точки в тих самих країнах спрацьовували успішно (Saint Petersburg повернувся чисто за 0.063s, тоді як два Moscow timed out), що вказує на регіональне мережеве фільтрування на боці самих контрольних точок, а не на щось неправильне в розгорнутому застосунку.

3. Власний інструмент швидкості Hostinger, Desktop і Mobile

Hostinger запускає власний Page Speed test прямо в панелі застосунку, тож я порівняв його показники з незалежними результатами GTmetrix, а не покладався на будь-який із них окремо.

Обидва типи пристроїв отримали ідеальні 100, а desktop-показники близько відповідають тому, що незалежно виміряв GTmetrix, і це головне, навіщо запускати обидва тести. Два різні інструменти, дві різні методології, і вони погоджуються між собою.

Mobile виявився повільнішим за всіма часовими метриками, як і очікується на моделюванні повільнішого з’єднання та слабшого процесора, але все одно достатньо швидким, щоб оцінка 100 відображала справді сильну реальну mobile-продуктивність, а не просто поблажливу шкалу оцінювання.

Одне невідповідність у самому інструменті. Хоча оцінка чисто 100 на обох пристроях, Diagnostics panel нижче все одно позначає кілька пунктів буквально з 0 score, network dependency tree, document request latency і avoiding multiple redirects, а також два пункти з оцінкою 50, unused JavaScript і legacy JavaScript.

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

Окремо, “helpful links”, які Hostinger показує поруч із цими діагностичними пунктами, усі написані для WordPress, “Speed up WordPress in 9 easy steps,” “How to optimize images for your WordPress site”, хоча тут Node.js-застосунок без будь-якого WordPress у стеку. Це залишок від спільного шаблону діагностики, а не контент, створений для цього продукту.

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

Керований web app hosting від Hostinger

Зосередьтеся на створенні застосунку, а Hostinger подбає про розгортання, інфраструктуру, безпеку, SSL, резервні копії та глобальну доставку.

Hostinger

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

Я протестував Hostinger’s Web Apps Hosting від landing page до оформлення замовлення, а потім із нового акаунта до повністю живого, робочого Node.js deploy.

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

1. Реєстрація

Я почав зі сторінки Web Apps Hosting, де головний заклик до дії — Start deploying.

Натискання на неї не відкриває форму реєстрації. Воно одразу прокручує вас униз до розділу з цінами, тож перше реальне рішення — який план купити, а не які дані акаунта вводити.

Поруч стояли два плани:

Я обрав Cloud Startup через удвічі більшу кількість застосунків і запас CPU порівняно з початковим тарифом. Одна невелика неузгодженість, на яку варто звернути увагу: сторінка з цінами називає його “Cloud Startup”, але коли він потрапляє в кошик, той самий план підписаний як “Startup plan.” Це не функціональна проблема, а просто розбіжність у назві між двома екранами в одному й тому самому процесі оформлення.

Сам кошик був чистим. У ньому було вказано 48-month term, економію, безкоштовний домен на рік і безкоштовні поштові скриньки, а також пропонувалося одне допродажне доповнення — Hostinger Reach email marketing — у власному виділеному блоці, а не вибране за замовчуванням.

Я пропустив його й натиснув Continue без зайвих кроків.

Якщо ви новий користувач, а не вже існуючий, checkout вставляє тут крок створення акаунта перед тим, як ви дійдете до сторінки платіжної адреси та оплати.

Далі ви додаєте платіжну адресу, вибираєте спосіб оплати, картка, PayPal або інші варіанти, і підтверджуєте. Я отримав email із підтвердженням покупки за кілька миттєвостей після натискання Submit payment, а потім потрапив прямо в hPanel, де план уже був підготовлений.

Що я подумав: Оформлення замовлення коротке, а допродажне доповнення легко відхилити без пошуків прихованого skip link. Розбіжність у назві плану між сторінкою цін і кошиком — дрібниця, але саме такі деталі змушують першого покупця зупинитися й перепровірити, чи він обрав правильний тариф.

2. Панель керування

Після проходження оплати ви потрапляєте в hPanel, власну панель керування Hostinger, яку компанія побудувала для керування кожним продуктом, що продає, а не сторінку, створену спеціально під ваш новий Web App.

Сторінка, на яку ви потрапляєте першою, — Home, і вона побудована навколо AI prompt bar угорі: “Hi, [your name]! How can I help you today?” із текстовим полем нижче та шістьма кнопками швидкого доступу: Get domain, Create website, Get email, Migrate site, Get VPS, і Try email marketing.

Прокрутіть далі, і ви знайдете:

• Промоційні плитки функцій для AI Builder, інструмента онлайн-магазину, заявленої безкоштовної бізнес-пошти, AI agents, automation app, а також заявленого безкоштовного домену
• Список завдань, який підштовхує вас до дій зі налаштування, завершення налаштування Reach, отримання безкоштовної пошти, отримання безкоштовного домену
• Your business, список усіх сайтів, застосунків і VPS-інстансів, прив’язаних до вашого акаунта, кожен із власною кнопкою Manage site
• VPS, окрема таблиця нижче, що перелічує будь-які VPS-інстанси за IP-адресою, статусом і датою завершення

Панель Agent також постійно розташована в правому верхньому куті кожної сторінки hPanel, а не лише на Home. Це той самий асистент Kodee, який використовується для підтримки, але тут він поданий як загальний інструмент дій із готовими підказками на кшталт “Deploy my Node.js app” або “Harden VPS updates”, які можна запускати без введення повного запиту.

Home справді корисна, коли ваш застосунок уже існує, усе в Your business веде прямо до нього. Але це не місце, де ви створюєте новий Web App або знаходите кнопку Setup. Для цього потрібно пройти іншим шляхом через бічне меню:

1. Натисніть Websites у лівій бічній панелі
2. Під ним розгортається підменю: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Натисніть Web Apps

Цей клік переносить вас на зовсім інший екран, ніж Home, — той, що організований навколо ваших реальних hosting-планів, а не навколо prompt bar.

Тут кожен ваш план отримує власну картку. У моєму акаунті це означало три картки, розташовані вертикально одна під одною:

Картка Business також уже мала під собою живий застосунок із попереднього тестування, orange-walrus-700988.hostingersite.com, із власними кнопками Tools і Dashboard.

Це саме по собі корисне спостереження. Коли Web App уже існує, його картка додає такий рядок, показуючи живий сайт прямо тут, і саме так виглядатиме ваша картка Cloud Startup після завершення setup.

Оскільки Cloud Startup був планом, який я щойно купив і ще не налаштував, його картка показувала лише кнопку Setup. Саме ця кнопка фактично запускає майстер створення Web App, і вона з’являється лише тут, через Websites → Web Apps, а не на Home, куди ви потрапляєте за замовчуванням.

Що я подумав: hPanel зрозуміла, щойно ви знаходите правильний екран, але у Web Apps Hosting немає очевидного входу з першого кроку. Ви потрапляєте на Home із prompt bar і швидкими ярликами, а не на шлях до створення застосунку, вам потрібно знати, що спочатку слід натиснути Websites, потім Web Apps, і лише після цього з’являється Setup. Це кілька додаткових кліків для продукту, який продається як “live in a minute.” Але коли ви вже там, картки планів чисті й чесно показують статус, а план із уже запущеним застосунком відображає це прямо на картці.

3. Розгортання застосунку

Натискання Setup на картці плану відкрило короткий onboarding flow: Where would you like to start? із трьома варіантами: Create a new site, Migrate an existing site або I hired someone to build my site. Я вибрав Create a new site.

Далі з’явилося How do you want to build your website?, розділене на два варіанти для початківців угорі, Hostinger AI Builder і WordPress + AI, та два варіанти під окремим заголовком “for advanced users” нижче: Node.js web app і PHP/HTML website. Саме вибір Node.js web app фактично переводить вас на сам продукт Web Apps Hosting.

Це важлива структурна примітка для всіх, хто порівнює продукти: Web Apps Hosting не має власного окремого процесу реєстрації.

Це одна гілка в тому ж загальному майстрі створення сайту, який використовується для AI Builder і WordPress.

Я натиснув кружок біля Node.js web app, а потім натиснув Next.

Після цього:

• Екран домену: я вибрав Use temporary domain, а не прив’язував реальний домен, оскільки це був тестовий deploy.

• Екран розташування сервера: Hostinger за замовчуванням вибрав France, найближчий регіон до моєї країни виставлення рахунків, і показав 167ms latency. Прокручування до опції United States показало 364ms, більш ніж удвічі більше.

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

Моя цільова аудиторія для тестового застосунку — користувачі зі США, тож сервер у США справді обслуговуватиме їх швидше, ніж сервер у Франції, незалежно від того, що показувало мені це в моїй локації. Число на екрані показує, як швидко сервер відповідає тесту Hostinger, а не як швидко він відповідатиме людям, які фактично користуватимуться вашим сайтом.

• Екран способу deploy: два основні варіанти, Import Git repository (позначений як Recommended) або Upload your files, плюс блок нижче для розгортання прямо з Claude Code, Cursor або VS Code через Hostinger Connector. Я вибрав Import Git repository і натиснув Connect with GitHub.

Це відкриває справжнє вікно входу в GitHub, якщо ви ще не авторизовані, а потім екран дозволів із назвою Install & Authorize Hostinger, де потрібно вибрати між:

• Встановленням для all repositories що ви володієте, включно з майбутніми, із доступом лише для читання до public repos
• Встановленням лише для only select repositories які ви оберете окремо, та з переліком точних дозволів, які надаються: read access to actions, metadata, and repository hooks, а також read-and-write access to administration, code, and pull requests. Щойно ви натиснете Install & Authorize, GitHub автоматично перенаправить вас назад у hPanel.

Ви потрапляєте на Select Git repository to import, прокручуваний список усіх репозиторіїв, прив’язаних до вашого GitHub-акаунта, кожен зі своєю кнопкою Deploy поруч. Я знайшов тестовий репозиторій, який завантажив раніше, hostadvice-webapps-test, і натиснув Deploy поруч із ним.

Після натискання цієї кнопки до завантаження наступної сторінки минуло близько 30 секунд без жодного індикатора прогресу на екрані, настільки довго, що ви могли б подумати, що клік не спрацював.

Сторінка, яка нарешті завантажується, має назву Review build settings, і вона чітко показує, де саме буде розгорнуто ваш застосунок, перш ніж ви щось підтвердите: “Deploys to ivory-llama-856835.hostingersite.com.” Нижче, без жодного заповнення з вашого боку, уже автоматично визначилися:

Кожен із цих п’яти рядків має власну кнопку Change або Add поруч, тож тут нічого не зафіксовано, якщо визначення щось розпізнає неправильно.

Я натиснув Add поруч із Environment variables і встановив одну пару ключ-значення, щоб підтвердити, що вона справді потім дійде до живого застосунку, потім натиснув Finish у цьому діалозі, а потім натиснув головну кнопку Deploy внизу сторінки.

Спостереження за збіркою

Екран перемикається на вигляд Deploying… із позначеною прогрес-стрічкою, “Deployment from GitHub,” яка рухається у реальних етапах, я бачив, як вона проходить 28%, потім 51%, і йде до завершення. Під прогрес-стрічкою є згортана панель Build logs, і її розгортання показує реальний, живий terminal output у міру появи, а не заглушку-спінер:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Deploy завершено

Коли збірка завершується, ви потрапляєте на екран Deployment completed! із живим мініатюрним прев’ю вашого реального застосунку, який рендериться просто там у картці, поруч із підсумком, що показує назву репозиторію та призначену live URL.

З цієї сторінки можна одразу перейти через Go to dashboard, де ви будете керувати застосунком надалі.

Що я подумав: Автовизначення тут — найсильніша сторона. Framework, branch і Node version усі визначилися правильно без жодного ручного поля, а живий build log робить очікування прозорим, а не непрозорим. Єдине слабке місце — це 30-секундна пауза ще до того, як ви взагалі потрапляєте на екран налаштувань, досить довга, щоб здавалося, ніби щось зависло, перш ніж процес відчутно починається.

4. Підтвердження живого deploy

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

Зі сторінки Deployment completed я перейшов прямо на live URL, ivory-llama-856835.hostingersite.com, а не довірився лише мініатюрному прев’ю в dashboard.

Жива сторінка завантажилася і показала саме те, що було закодовано в застосунку:

• Server build time, живий timestamp, який підтверджує, що сторінка щойно була зібрана, а не віддана зі старого кешу
• Environment variable check, який показує власну змінну, що я встановив під час екрана deploy, і вона правильно підтвердилася на реальному live сайті, а не лише в прев’ю панелі

Потім я натиснув кнопку Ping the API route самого застосунку, яка викликає живий backend endpoint, а не просто рендерить статичний вміст. Він повернув чисту JSON-відповідь:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

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

Робочий API-запит доводить, що під ним справді працює Node.js-сервер і відповідає на реальні запити, тобто саме ту частину “Node.js web app” hosting, яку легко підробити статичним файлом і важко підробити живим серверним timestamp, згенерованим у момент, коли ви натискаєте кнопку.

Що я подумав: Це перевірка, яку я б радив вам робити перед тим, як довіряти будь-якому deploy на цій платформі або на будь-якій подібній. Зелений статус “Completed” і прев’ю-мініатюра кажуть, що збірка завершилася. Перехід на live URL і запуск чогось динамічного, API-виклику, читання з бази даних, будь-чого, що не можна підробити кешованою статичною сторінкою, показує, що сервер справді живий і робить те, що ви на ньому побудували.

5. Керування Web App

Після підтвердження, що live застосунок працює, я повернувся в hPanel і повністю дослідив dashboard самого застосунку, фактичний серверний шар керування цим продуктом, окремий від загальної Home-сторінки hPanel, описаної раніше.

Огляд панелі. Щойно ви потрапляєте сюди, чотири status badges одразу показують стан системи:

Усі чотири були зеленими за замовчуванням, без потреби вмикати щось вручну. Нижче розташована картка Last deployment, яка підтверджує стан, репозиторій, автора, commit, час deploy, визначений стек і версію Node, усе, що хочеться перевірити з першого погляду без заглиблення в логи.

Автоматичний Page Speed test вже сам запустився для live сайту і повернув 99/100 для Desktop без мого втручання, стоячи поруч із панеллю Essentials із швидкими посиланнями на підключення до бази даних, резервні копії, файловий менеджер, runtime logs і кеш.

Deployments, environment variables та logs. Ці три окремі сторінки охоплюють це:

• Deployments зберігав повний запис про push, автора, branch, commit hash і статус завершення, тобто справжню історію, а не лише останній deploy
• Environment variables коректно показували ту змінну, яку я встановив під час deploy, підтверджуючи, що вона збережена й застосована, а не лише показана один раз під час налаштування і забута
• Runtime logs потоково передавали live серверний вивід у міру появи, стартові рядки Next.js, ready timestamps і поточну кількість issues та errors, які весь час, поки я дивився, дорівнювали нулю і нулю

Безпека. Malware Scanner повернув чистий результат: “Your website is safe,” із однією приміткою, чітко сформульованою, а не захованою у дрібному шрифті: він перевіряє лише файли сайту, а не вміст бази даних, і доступна платна очистка, якщо ви хочете глибшу перевірку, що включає базу даних. Vulnerabilities scan теж повернувся чистим.

Бази даних. Тут маркетинг самого продукту створює реальний розрив, який варто зрозуміти перед покупкою. План рекламує managed MySQL як ключову функцію, але нічого не створюється для вас автоматично.

Розділ Databases відкривається на ручній формі Create a New MySQL Database And Database User, тобто ви самі називаєте і створюєте базу даних, перш ніж ваш застосунок зможе нею скористатися. Я підтвердив це безпосередньо з Kodee, про що йдеться в розділі Support нижче, і відповідь була прямою: managed означає, що Hostinger керує інфраструктурою бази даних на своєму боці, а не те, що база даних створюється для вас у момент запуску застосунку.

Доступ для просунутих користувачів. SSH access є в розділі Advanced, із IP, портом і username, але за замовчуванням має статус Inactive і потребує ручного натискання Enable, перш ніж ви зможете ним користуватися. File Manager пропонує вибір між переглядом лише файлів цього застосунку або всіх файлів у межах усього hosting plan.

Що я подумав: Щоденна панель керування докладна і добре організована. Особливо легко знайти і справді корисні deployment history та security scans, а нуль помилок у runtime log разом із чистим malware scan дали мені реальне відчуття, що застосунок здоровий, а не просто онлайн.

Єдине місце, де інтерфейс трохи переобіцяє, — це розділ бази даних, де “managed MySQL” на сторінці плану звучить так, ніби вона вже чекає на вас у момент запуску застосунку, а на практиці ви отримуєте форму для її ручного створення — просту у використанні, але все ж крок, який ви маєте зробити самі.

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

Створюйте, розгортайте та масштабуйте з Hostinger

Хостіть modern web apps із GitHub integration, managed MySQL, global CDN, unlimited bandwidth і вбудованими інструментами безпеки.

Hostinger

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

Я протестував підтримку Hostinger для Web Apps Hosting через Kodee, AI-асистента, вбудованого в hPanel, а потім переглянув knowledge base, щоб з’ясувати, скільки речей вона покриває без звернення до людей. Kodee з’являється в двох місцях, які варто розрізняти: як Ask AI на публічному маркетинговому сайті та як панель Agent, доступна з будь-якої сторінки всередині hPanel, зокрема безпосередньо на власному dashboard Web App.

1. AI Support (Kodee)

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

Питання 1 перевіряло поведінку при збої deploy і момент застосування змінних середовища — обидві реальні production-проблеми для тих, хто запускає на цій платформі:

If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?

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

Щодо змінних середовища він підтвердив, що їх можна встановити до першого deploy у налаштуваннях deploy, а для вже запущеного застосунку він описав точні три кроки: відкрити Settings і Redeploy, додати або змінити змінні в Environment variables, зберегти й запустити redeploy.

Питання 2 тиснуло на два прогалини, які я сам знайшов у панелі: формулювання “managed MySQL” у порівнянні з ручною формою створення і SSH, що за замовчуванням неактивний:

This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?

Відповідь Kodee точно підтвердила те, що я вже побачив у інтерфейсі, без пом’якшення формулювань. База даних не створюється автоматично для кожного Web App, “managed” означає, що Hostinger керує сервісом і інфраструктурою бази даних, а створення та налаштування фактичної бази даних — це ваша робота через той самий екран Create a New MySQL Database, а потім самостійне додавання її даних підключення до змінних середовища вашого застосунку.

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

Що я подумав: Обидві відповіді збіглися з тим, що я вже перевірив у панелі вручну, а не суперечили йому чи пом’якшували це, і це ознака того, що support tool справді перевіряє реальний стан продукту, а не повторює скрипт. Жодне з питань не можна було б вирішити, просто вставивши текст із загального FAQ, і Kodee впорався з обома, давши конкретні, структуровані, двочастинні відповіді приблизно за хвилину кожна.

2. База знань

База знань Hostinger відкривається у вигляді сітки категорій, 20 категорій загалом, кожна з яких показує кількість статей. Декілька найбільших: AI Builder має 330 статей, VPS — 276, Email — 127, а Website — 103.

Web Apps Hosting не має власної окремої категорії. Його контент розкидано між Getting Started, hPanel і Website, і це реальний факт для тих, хто очікує окремого центру, як у VPS або Email.

Пошук за “Web Apps” напряму повернув 71 результат на 8 сторінках. Перші результати були сумішшю безпосередньо релевантного та лише віддалено пов’язаного контенту:

• How to deploy apps built with Codex on Hostinger, прямо релевантна
• Hostinger AI Builder: How to create a web app in agentic mode, суміжний, але інший продукт
• How to add a Node.js Web App in Hostinger, прямо релевантна
• How to install Flutter Web on a VPS at Hostinger, зовсім інший продукт
• Кілька статей про спосіб оплати в Website Builder (PayPal, WeChat Pay, BLIK), не пов’язані, окрім наявності слів “web” і “app” десь у тексті

Я відкрив один із перших результатів, How to deploy apps built with Codex on Hostinger, щоб оцінити його глибину. Це виявився докладний, добре структурований покроковий посібник: спершу перелік підтримуваних фреймворків, потім покрокові скріншоти для шляхів GitHub-import і ZIP-upload, розділ про налаштування build settings із прикладами команд, розбір файлової структури після deploy, покроковий майстер підключення бази даних, розділ про vulnerability monitoring і завершальний блок FAQ.

Хоча він поданий саме через Codex, underlying platform та сама, що й у загальному продукті Node.js Web App, тож більша частина матеріалу застосовна безпосередньо.

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

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

Простий hosting для сучасних web apps

Розгортайте React, Next.js, Vue, Node.js та інші сучасні застосунки без керування серверами чи складною інфраструктурою.

Hostinger

Чи рекомендуємо ми Hostinger Web Apps Hosting?

Так. Процес deploy — найсильніша частина цього продукту: правильне автоматичне визначення мого стеку, branch і Node version, реальний build log у стрімі замість спінера, а також живий застосунок, який пройшов усі тести продуктивності, які я йому кинув, з ідеальними GTmetrix score з двох окремих континентів, чистою глобальною перевіркою з 54 точок і збігом 100/100 у власних інструментах Hostinger як на desktop, так і на mobile. Kodee підкріпив це точними, конкретними відповідями на реальні технічні питання, а не загальними скриптовими відповідями.

Недоліки невеликі, але їх варто знати перед покупкою. “Managed MySQL” на сторінці плану звучить так, ніби база вже готова, коли ваш застосунок запускається, а на практиці означає форму ручного створення. Панель також не має окремої точки входу для Web Apps Hosting із головного екрану Home, вам потрібно знати, що спершу слід зайти в Websites.

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

Hostinger

5.0

2,471 user reviews

80 ₴ /mo

Ціна від

Hostinger

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

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