Если вы подбираете хостинг под 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, доходит до установки – и она падает с ошибкой про недоступный search engine. Дальше человек идёт в поддержку, где ему вежливо объясняют, что на этом тарифе 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 за минуты, процессы начинают убиваться по лимиту, и магазин то работает, то нет – без всякой связи с тем, сколько на нём посетителей.
Со стороны мониторинга провайдера такой аккаунт выглядит характерно: ровный высокий 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 ГБ RAM с 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 – актуальные поддерживаемые версии
F.A.Q. по 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 МБ. И даже если в панели стоит 2048M, реальный лимит режет физическая память аккаунта (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 ГБ RAM, где вы сами ставите OpenSearch, Redis и Varnish. Если администрировать сервер некому – берут managed-хостинг под Magento с готовым стеком, а под крупный магазин с сезонными пиками разумнее облако, которое расширяется под нагрузку.
Почему обновление Magento – это не «нажать кнопку»?
Каждый релиз поднимает планку требований: 2.4.9 требует PHP 8.4/8.5, тогда как недавно хватало 8.1. Главная сложность даже не в ядре, а в сторонних расширениях, которые должны иметь версию под новую Magento и новый PHP, иначе после обновления магазин ляжет. Плюс регулярные патчи безопасности от Adobe, которые накатывать нужно обязательно.