Якщо ви підбираєте хостинг для Magento, почну з чесної відповіді, щоб не затягувати: звичайний спільний хостинг для цієї платформи майже не підходить. Він не просто «працює повільно», а в багатьох випадках взагалі не дозволяє її встановити. Реальний вибір тут стоїть між VPS, виділеним сервером або хмарою, і вирішувати це краще до того, як ви оплатите тариф за пару доларів із написом «безлімітно».
Причина не в тому, що «Magento важка» – так можна сказати про що завгодно. Причина конкретніша: Magento вимагає набору окремих серверних сервісів, яких на загальному хостингу зазвичай немає і не буде. Нижче – що це за сервіси, чому провайдер не надає їх на shared-хостингу та як це позначається на вашому бюджеті.
Що таке Magento, якщо коротко
Magento – це не CMS у тому сенсі, в якому нею є WordPress. Це платформа для інтернет-магазинів, важка і розрахована на серйозні каталоги: тисячі товарів, складні знижки, багато складів, багатомовність «з коробки». У 2018 році її придбала Adobe, і відтоді існують дві гілки – безкоштовна Magento Open Source та платна Adobe Commerce (колишня Magento Commerce) з хмарними та корпоративними функціями. Ядро у них спільне, тож усе, що нижче про вимоги до сервера, стосується обох. Є ще Mage-OS – форк спільноти, але це окрема тема.
Актуальна версія на середину 2026 року – 2.4.9, вийшла в травні. Номер версії тут важливий не сам по собі: він тягне за собою перелік вимог, і ці переліки з кожним релізом стають суворішими, а не м’якшими. Те, що рік тому працювало, сьогодні вже може не встановитися.
OpenSearch – ось де закінчується звичайний хостинг
Почну з головного, бо саме цей пункт є каменем спотикання для більшості. Починаючи з версії 2.4, у Magento немає вбудованого пошуку в каталозі на базі MySQL. Зовсім. Пошук товарів, фільтрація за категоріями, підказки в рядку – усе це працює через окремий пошуковий движок. Раніше це був Elasticsearch, тепер – OpenSearch (у версії 2.4.9 потрібна третя версія, а Elasticsearch остаточно виведений з підтримки). Без запущеного та налаштованого пошукового сервісу каталог не працює, а частина сторінок просто не відображається відвідувачеві.
При цьому не працює не лише рядок пошуку, як багато хто очікує. Виходить з ладу й багатошарова навігація – ті самі фільтри «ціна / бренд / розмір» ліворуч від товарів, без яких великий каталог перетворюється на нескінченну стрічку. Для магазину з тисячами позицій це не дрібниця: покупець, який не може відсіяти зайве, найчастіше просто закриває вкладку. Тож OpenSearch – це не «пошук про всяк випадок», а основна частина вітрини.
Тепер той самий пункт з боку хостера. OpenSearch – це окрема Java-служба, яка постійно споживає пам’ять, навіть коли на сайті немає жодного відвідувача. Під неї потрібно виділити близько гігабайта, і цей гігабайт зайнятий завжди, а не лише в той момент, коли хтось шукає товар. На загальному хостингу сотні облікових записів ділять один фізичний сервер, і утримувати для кожного таку «ненажерливу» службу економічно безглуздо: тариф у кілька доларів її навіть близько не окупить. Провайдери не встановлюють OpenSearch не з злісності, а з міркувань економічної доцільності – їм це просто невигідно.
Що при цьому бачить клієнт. Він купує shared-хостинг, розпаковує Magento, доходить до встановлення – і воно вилітає з помилкою про недоступний пошуковий механізм. Далі людина звертається до служби підтримки, де їй ввічливо пояснюють, що на цьому тарифі OpenSearch не передбачено. Кілька років тому такі звернення сипалися валом, і досі це одна з найпоширеніших причин, через яку новачок кидає Magento на другий день. Найнеприємніше тут – те, що дізнаєшся про це вже після оплати, коли гроші списано, а магазин так і не запрацював.
До речі, через цей пункт деякі хостери взагалі не вказують Magento у списку підтримуваних CMS – щоб не збирати заявки, які все одно нічим закрити. Відсутність Magento у списку іноді означає не «ми не вміємо», а «ми чесні».
Апетит до пам’яті: memory_limit і PMEM
Другий бар’єр – пам’ять. У Magento високі вимоги до memory_limit і PMEM – параметра, який обмежує, скільки оперативної пам’яті може спожити один PHP-процес.
Для звичайної роботи магазину зазвичай вистачає 756 МБ – 1 ГБ, але встановлення, компіляція коду та розгортання вимагають підвищити memory_limit щонайменше до 2 ГБ. На загальному хостингу такі значення майже не зустрічаються: там ліміти обмежує CloudLinux, і типовий верхній поріг – 256–512 МБ на процес. Ви зіткнетеся з ним ще на етапі setup:upgrade, задовго до того, як побачите вітрину магазину.
І тут є підступ, про який мовчать вітрини тарифів. Навіть якщо в панелі написано «memory_limit 2048M», це ще не означає, що процес реально стільки отримає: на shared паралельно діє ліміт фізичної пам’яті облікового запису (PMEM), і він зазвичай нижчий. Тобто цифра в налаштуваннях PHP є, а пам’яті під неї – немає. Орієнтуйтеся на меншу з двох цифр, а не на ту, що красивіше виглядає в панелі.
Скільки потрібно самому серверу – це окреме питання. Мінімальні 2 ГБ RAM, які іноді вказують у вимогах, підходять лише для тестового стенду, де ви самостійно клікаєте в адмінці. Робочий магазин із розширеннями, фоновими завданнями та реальним трафіком спокійно вимагає 4–8 ГБ і більше, і тут усе залежить від розміру каталогу та кількості одночасних покупців. Магазин на сто товарів і магазин на сто тисяч – це різні сервери, хоча движок один.
Стаття довга. Пропонуємо зробити паузу та ознайомитися з найкращими українськими хостинг-провайдерами з нашого рейтингу. На кожного з них є детальний аналіз: як проводилося тестування, як справи з аптаймом, швидкістю та підтримкою, які сильні та слабкі сторони. Загляньте в огляди тих, хто вас цікавить, прочитайте відгуки клієнтів.
Magento не встановлюється через FTP
Ще одна відмінність від звичної установки «завантажив архів, розпакував через файловий менеджер». Magento встановлюється й оновлюється через Composer – менеджер PHP-пакетів, який завантажує сотні залежностей з інтернету прямо на сервер. А Composer, у свою чергу, вимагає доступу через SSH і права запускати консольні команди.
На більшості дешевих тарифів SSH або закритий, або обмежений так, що Composer не спрацює: не вистачить ані часу виконання, ані тієї самої пам’яті. Технічно завантажити файли Magento через FTP можна, але далі на вас все одно чекає ручна компіляція, генерація коду і та сама стіна з лімітів. Простіше сформулювати так: якщо хостинг не надає нормального SSH – він не підтримує Magento, що б там не було написано в рекламі тарифу.
CPU, індексація та cron
Припустимо, ви вирішили питання з пам’яттю та пошуком. Наступне, на чому натрапляє магазин на слабкому тарифі, – процесор.
Magento постійно щось перераховує у фоновому режимі: ціни, наявність, індекси каталогу, правила знижок, пов’язані товари. За це відповідає індексація та планувальник cron, який має запускати завдання приблизно раз на хвилину. На нормальному сервері це непомітно. На загальному хостингу, де процесорний час жорстко обмежений, ситуація інша: реіндексація великого каталогу вичерпує виділену квоту CPU за лічені хвилини, процеси починають завершуватися через перевищення ліміту, і магазин то працює, то ні – без жодного зв’язку з тим, скільки на ньому відвідувачів.
З боку моніторингу провайдера такий акаунт виглядає характерно: рівний високий рівень завантаження процесора без явних сплесків трафіку, ніби сайт сам себе навантажує. Він і справді сам себе навантажує – це фонові завдання Magento. На виділених і віртуальних серверах таке трапляється постійно, і перше, на що там звертають увагу при скарзі на гальмування, – чи правильно налаштований cron і чи не запущена реіндексація в режимі «на кожен запит» замість розкладу. Це, до речі, часта помилка під час перенесення магазину: налаштування індексації скидаються, і сервер починає перераховувати каталог по колу.
Redis, Valkey, Varnish – рівні кешу
Щоб Magento не перераховувала одне й те саме по сто разів, поверх неї встановлюють кілька шарів кешу. Redis (або його свіжий форк Valkey, на який движок переходить у нових версіях) зберігає кеш і сесії користувачів у пам’яті. Varnish бере на себе кешування цілих сторінок – видає готові сторінки, взагалі не зачіпаючи PHP.
Формально без них магазин запуститься. На практиці без Varnish час відгуку сервера на робочому каталозі буде таким, що частина покупців покине сторінку раніше, ніж вона дозавантажиться, – і ви навіть не дізнаєтеся, що втратили їх через повільність. Це ті самі «додаткові» сервіси, які на загальному хостингу не надають, а на VPS їх потрібно встановлювати й налаштовувати вручну або обирати хостинг, де стек під Magento вже зібрано й оновлюється провайдером.
Тисячі файлів: і знову про inode
Короткий пункт, про який «люблять» забувати. Встановлення Magento – це десятки тисяч файлів у папці vendor плюс кеш, логи, згенерований код і завантажені зображення товарів. Усе це враховується в inode – ліміті на кількість файлів, а не на їхній обсяг. Магазин легко досягає inode-ліміту загального хостингу, залишаючись при цьому майже порожнім за гігабайтами. Знайома історія: диск зайнятий на десять відсотків, а сайт виводить повідомлення «No space left on device». Це про inode, і Magento – одна з небагатьох CMS, яка одразу досягає цієї межі, ще до того, як ви додали перший товар.
Кому Magento, найімовірніше, не потрібна
Раз вже ми розбираємо вимоги, чесно буде сказати й протилежне. Більшості невеликих магазинів Magento не потрібна – вона вирішує завдання, яких у них немає, і приносить рахунки за хостинг, які їм не по кишені.
Якщо у вас кілька сотень товарів, один склад і звичайна вітрина без складної логіки цін – ви отримаєте ту саму вітрину на набагато легшому движку, який спокійно працює на пристойному віртуальному хостингу. Той самий OpenCart або магазин на WordPress впораються з такими завданнями без OpenSearch, без 2 ГБ пам’яті на розгортання та без виділеного сервера. Magento починає виправдовувати свої високі вимоги там, де кількість товарів сягає тисяч і десятків тисяч, де потрібні складні B2B-сценарії, кілька вітрин на одному ядрі або тонке управління знижками та групами клієнтів. До цього масштабу вона частіше є тягарем, ніж перевагою.
То який хостинг обрати?
Універсальної відповіді немає, і будь-хто, хто називає один конкретний тариф «найкращим для Magento», по суті продає вам цей тариф. Вибір залежить від типу розміщення та від того, на якому етапі ви перебуваєте.
Якщо магазин ще невеликий або це тестовий стенд – підійде VPS від 4 ГБ оперативної пам’яті з root-доступом, на якому ви самі (або підрядник) встановите OpenSearch, Redis і Varnish. Це дешевше, але все адміністрування лягає на ваші плечі, і без фахівця, який вміє обслуговувати сервер, такий варіант швидко перетворюється на джерело нічних пригод. Якщо нікому займатися налаштуванням – обирайте спеціалізований managed-хостинг під Magento, де стек уже зібрано й оновлюється провайдером: платите більше, але не за обладнання, а за те, що не доведеться адмініструвати самостійно. Для великого магазину з сезонними піками розумніше вибрати хмарне рішення, яке розширюється відповідно до навантаження, – переплата за потужності, що простоюють у міжсезоння, окупається однією «чорною п’ятницею», яку сайт переживе, а не вийде з ладу.
Перед оплатою корисно поставити провайдеру кілька прямих запитань, і за відповідями одразу видно, чи працювали там із Magento серйозно. Чи є OpenSearch потрібної версії – і саме запущений, а не «встановимо за заявкою». Чи можна підвищити memory_limit до 2 ГБ на акаунті, а не лише в загальних словах. Чи надає тариф повноцінний SSH для Composer. Чи є Redis і Varnish та як налаштовується cron. Якщо на половину питань відповідають ухильно – це не той хостинг, навіть якщо в описі тарифу гордо написано «підтримка Magento».
Що дійсно варто зробити перед покупкою – не вірити рекламним цифрам. «8 ядер, 16 ГБ, безліміт» на папері та реальна продуктивність під Magento – це різні речі; як відрізнити одне від іншого, ми детально розбираємо в методології рейтингу. А щоб зрозуміти, який тариф дає більше за ті самі гроші саме під ваше завдання, є індекс цінності тарифу та підбірник – вони якраз враховують, що магазину потрібен не найдешевший сервер, а адекватний його навантаженню.
Найнеприємніше в цьому виборі – те, що помилка коштує не грошей, а продажів. Магазин, який виходить з ладу по суботах під навантаженням, мовчки втрачає замовлення: покупець не пише в службу підтримки, він просто переходить до конкурента, а ви дізнаєтеся про це зі звіту наприкінці місяця, а не з сповіщення в ту ж секунду.
Оновлення: чому це не просто натискання кнопки
Останнє, про що майже не попереджають на початку. Magento оновлюється не так, як WordPress – «натиснув і готово». Кожен реліз піднімає планку: 2.4.9 вимагає PHP 8.4 або 8.5, тоді як ще недавно вистачало 8.1, а версії PHP 8.1 і 8.2 офіційно вже не підтримуються взагалі.
Складність полягає навіть не в самому ядрі, а в розширеннях: сторонні модулі повинні мати версію, сумісну з новим PHP та новою Magento, інакше після оновлення магазин вийде з ладу – і найчастіше це станеться саме на касі, де ви це помітите останнім. Плюс регулярні патчі безпеки, які Adobe випускає окремими бюлетенями і які потрібно встановлювати, бо інтернет-магазин із платіжними даними – ласина для зловмисників. Усе це – ще один аргумент проти найдешевшого хостингу: на ньому ви, найімовірніше, застрягнете на старій версії PHP і старій Magento, а це прямий шлях до вразливостей, які давно усунуто в усіх інших. А про те, що бекап – це не захист, на магазині з чужими грошима забувати не варто подвійно.
Джерела
- Adobe Commerce – склад пакетів та залежності Magento Open Source 2.4.9 (офіційна документація)
- Adobe Commerce – посібники з експлуатації та системні вимоги
- OpenSearch – офіційний сайт проєкту
- Composer – офіційний сайт менеджера пакетів PHP
- PHP – актуальні версії, що підтримуються
Часті запитання щодо Magento
Чи можна встановити Magento на звичайний віртуальний хостинг?
У більшості випадків – ні. Magento вимагає окремого пошукового движка OpenSearch, memory_limit до 2 ГБ на деплой та доступ через SSH – всього цього на загальному хостингу зазвичай не надають. Технічно завантажити файли можна, але інсталяція найчастіше завершується невдачею ще на етапі setup:upgrade. Реальний вибір для Magento – VPS, виділений сервер або спеціалізована хмарна платформа.
Чому Magento вимагає OpenSearch і що буде без нього?
Починаючи з версії 2.4 у Magento немає вбудованого пошуку по каталогу на базі MySQL. Пошук товарів, підказки та багатошарова навігація з фільтрами працюють лише через окремий механізм – раніше це був Elasticsearch, тепер – OpenSearch. Без запущеного пошукового сервісу каталог не працює, а частина сторінок не відображається. Тому наявність OpenSearch – перше, що потрібно перевіряти у хостингу.
Скільки пам’яті (memory_limit) потрібно Magento?
Для роботи магазину зазвичай вистачає 756 МБ – 1 ГБ, але встановлення, компіляція та розгортання вимагають підвищення memory_limit щонайменше до 2 ГБ. На загальному хостингу такі значення майже не зустрічаються: типовий ліміт там становить 256–512 МБ. І навіть якщо в панелі вказано 2048 МБ, реальний ліміт обмежується фізичною пам’яттю облікового запису (PMEM), яка зазвичай менша.
Скільки оперативної пам’яті потрібно серверу під Magento?
Мінімальні 2 ГБ RAM підходять лише для тестового середовища, де ви самостійно виконуєте дії в адмінці. Робочий магазин із розширеннями, фоновими завданнями та реальним трафіком потребує 4–8 ГБ і більше. Точна цифра залежить від розміру каталогу та кількості одночасних покупців.
Яка версія PHP потрібна для Magento 2.4.9?
Версія 2.4.9 вимагає PHP 8.4 або 8.5. Старіші версії PHP 8.1 та 8.2 офіційно вже не підтримуються. Перед оновленням Magento спочатку перевіряють, чи сервер дійсно надає потрібну версію PHP, а не просто «вміє» її за запитом до служби підтримки.
Чи можна встановити Magento через FTP без SSH та Composer?
Повноцінно – ні. Magento встановлюється та оновлюється через Composer, а він вимагає доступу через SSH і права запускати консольні команди. Завантажити файли через FTP можна, але далі на вас чекає ручна компіляція та стіна з лімітів. Якщо хостинг не надає нормального SSH, вважайте, що він не підтримує Magento.
Навіщо Magento потрібен cron?
Magento постійно перераховує у фоновому режимі ціни, наявність товарів, індекси та правила знижок – за це відповідає планувальник cron, який повинен запускатися приблизно раз на хвилину. Без коректно налаштованого cron індекси застарівають, листи не надсилаються, а частина функцій магазину перестає працювати. На загальному хостингу cron часто обмежують за частотою або за процесорним часом.
Що таке Redis/Valkey та Varnish і чи є вони обов’язковими?
Redis (або його форк Valkey) зберігає кеш і сесії в пам’яті, а Varnish відповідає за кешування цілих сторінок. Формально магазин запуститься і без них, але на робочому каталозі час відгуку буде занадто великим, і частина покупців покине сторінку. На VPS ці сервіси встановлюють вручну або обирають хостинг, де стек під Magento вже зібрано.
Чи досягає Magento ліміту inode?
Так, і досить легко. Встановлення Magento – це десятки тисяч файлів у папці vendor плюс кеш, логи та зображення товарів, а inode враховує саме кількість файлів, а не їхній обсяг. Магазин може зайняти всього кілька відсотків диска і при цьому досягти ліміту inode загального хостингу з помилкою «No space left on device».
Чим Magento Open Source відрізняється від Adobe Commerce?
Magento Open Source – безкоштовна версія, Adobe Commerce (колишня Magento Commerce) – платна, з хмарними та корпоративними функціями. Ядро в них спільне, тому вимоги до хостингу однакові. Для невеликого та середнього магазину зазвичай обирають Open Source.
Який хостинг вибрати для Magento – VPS, виділений сервер чи хмару?
Універсальної відповіді немає. Для невеликого або тестового магазину підійде VPS від 4 ГБ оперативної пам’яті, де ви самі встановлюєте OpenSearch, Redis і Varnish. Якщо адмініструвати сервер нікому – обирають managed-хостинг під Magento з готовим стеком, а для великого магазину з сезонними піками розумніше вибрати хмару, яка розширюється відповідно до навантаження.
Чому оновлення Magento – це не просто «натиснути кнопку»?
Кожен реліз підвищує планку вимог: 2.4.9 вимагає PHP 8.4/8.5, тоді як нещодавно вистачало 8.1. Головна складність навіть не в ядрі, а в сторонніх розширеннях, які повинні мати версію, сумісну з новою версією Magento та новим PHP, інакше після оновлення магазин перестане працювати. Плюс регулярні патчі безпеки від Adobe, які обов’язково потрібно встановлювати.