Что такое MODX-хостинг и почему «обычный тариф» не всегда подходит
Под «MODX хостингом» обычно подразумевают не отдельный «волшебный» тариф, а корректно собранное окружение:
быстрый диск (NVMe), стабильные ресурсы CPU/RAM, современный стек PHP (желательно 8.1+), правильная связка веб-сервера и PHP-обработчика (Nginx/Apache + PHP-FPM),
а также кеширование (OPcache и, по возможности, Redis). MODX умеет быть очень быстрым, но при дефиците ресурсов и без базовой оптимизации
начинает «упираться» в дисковые операции, медленную БД, отсутствие кеша и неверные правила чПУ.
Признаки «правильного» окружения
- NVMe-диски и нормальная I/O производительность
- PHP-FPM + OPcache (включён и настроен)
- HTTP/2 (а лучше — поддержка HTTP/3 как опция)
- Адекватные лимиты: memory_limit, max_execution_time, upload/post size
- Возможность настроить Nginx/Apache правила для friendly URLs
- Бэкапы и простой откат, доступ к логам (error/access)
Тревожные маркеры
- «Безлимитный» shared без понятных лимитов CPU/RAM и I/O
- Нет OPcache или его нельзя включить
- Закрытые логи, нет SSH (или он критически урезан)
- Старые версии PHP и «нельзя выбрать нужную»
- ЧПУ ломаются при любом обновлении веб-сервера/правил
- Бэкапы «по запросу», без расписания и точки восстановления
Интент запроса «modx хостинг»: что ищут и что важно закрыть на странице
По запросу MODX хостинг интент обычно смешанный: люди хотят и подобрать провайдера, и понять требования, чтобы не ошибиться с тарифом.
Поэтому лучший контент в ТОПе закрывает одновременно «выбор по характеристикам» и «практику эксплуатации»: чПУ, кеши, миграция, безопасность, апдейты.
Ниже мы даём структурированный путь выбора — от сценария проекта к конкретным параметрам хостинга.
Сценарий
Лендинг / корпоративный / каталог / магазин / мультисайт.
Ресурсы
vCPU/RAM/I/O, изоляция и предсказуемость под нагрузкой.
Стек
PHP-FPM, OPcache, Redis, Nginx/Apache, HTTP/2/3.
Риски
Бэкапы, обновления, WAF, изоляция, контроль доступа.
Кому подходит MODX-хостинг и кому лучше выбрать альтернативу
Подходит
- Сайты с нестандартной структурой: сложные посадочные, корпоративные, порталы
- Проекты, где важна гибкость: кастомные компоненты, интеграции, нестандартные поля
- Каталоги и контент-платформы с продуманным кешированием
- Мультисайты и несколько проектов в одном окружении (особенно на VPS)
Может не подойти
- Если нужен «магазин из коробки» без разработки и поддержки
- Если бюджет не включает администрирование и обновления
- Если проект живёт на «минимальных тарифах» и не допускает роста ресурсов
- Если команда не планирует следить за безопасностью (MODX этого не прощает)
Если вы выбираете платформу под сайт в целом (а не только под MODX), посмотрите наш раздел:
Хостинг для сайта.
Типовые сценарии: какой хостинг нужен под разные проекты на MODX
| Сценарий |
Рекомендованный тип |
Стартовые ресурсы |
Что критично |
| Лендинг / визитка |
Shared (качественный) или бюджетный VPS |
1–2 vCPU / 2–4 GB RAM |
OPcache, быстрый диск, корректные чПУ |
| Корпоративный сайт |
VPS/VDS |
2 vCPU / 4 GB RAM |
PHP-FPM, бэкапы, логи, безопасность |
| Каталог / контент-проект |
VPS/VDS (NVMe) |
2–4 vCPU / 4–8 GB RAM |
Redis, тюнинг БД, CDN/кеш статики |
| Интернет-магазин на MODX |
VPS/VDS или Managed VPS |
4 vCPU / 8 GB RAM |
Изоляция, защита, мониторинг, стабильная БД |
| Высокая нагрузка / несколько сайтов |
VPS/VDS (выше класс) или выделенный |
8+ vCPU / 16–32 GB RAM |
Горизонтальное масштабирование, CDN, отдельные роли |
Рост без миграции
Выбирайте провайдера, где апгрейд CPU/RAM/диска делается быстро и без «пересборки сервера».
Управляемость
Если нет DevOps-ресурса, смотрите Managed VPS: меньше рисков и проще поддержка.
Экономика
Иногда «дороже на 300–500 ₽» экономит недели на исправлении проблем и падениях конверсии.
Что обязательно проверить у хостинга для MODX: чек-лист перед оплатой
Техническое окружение
- PHP: доступность 8.1+ (желательно) и переключение версий
- PHP-FPM и возможность править параметры (хотя бы через панель)
- OPcache включён, без «запрета на оптимизацию»
- Redis как опция (или хотя бы стабильный кеш на файловой системе)
- База данных: MySQL/MariaDB с предсказуемой производительностью
- SSL (Let’s Encrypt) и автопродление
Операционные моменты
- Плановые бэкапы + ручные точки восстановления
- Доступ к логам веб-сервера и PHP (без «пишите в поддержку»)
- Понятные лимиты CPU/RAM/I/O на shared (или честный VPS)
- Антивирус/сканер файлов и базовая защита от брутфорса
- Техподдержка, которая понимает разницу MODX 2 и MODX 3
- Возможность развернуть staging (тестовую копию) без боли
Практика рейтинга: если провайдер не даёт логов/бэкапов/понятных лимитов — проблемы обычно проявятся не сразу, а в момент роста трафика или обновления.
Частые ошибки при выборе MODX-хостинга
Ориентироваться на «безлимит»
Безлимит чаще означает скрытые лимиты. Для MODX важнее предсказуемость CPU/RAM/I/O, чем «сколько угодно сайтов» на тарифе.
Игнорировать OPcache
MODX выигрывает от OPcache заметно: меньше компиляции PHP, быстрее отклик, стабильнее админка под нагрузкой.
Путать «shared для теста» и «shared для бизнеса»
Для живого проекта (особенно с заявками/продажами) лучше VPS/VDS: изоляция и контроль настроек окупаются.
Не проверять чПУ и редиректы
Неправильные правила переписи на Nginx/Apache ломают friendly URLs, создают дубли и «съедают» индексацию и конверсию.
Мини-проверка перед запуском
✔ Протестировать админку (login, manager, сохранение ресурса)
✔ Пройтись по чПУ + проверить 301/404
✔ Проверить скорость TTFB и пики нагрузки
✔ Убедиться, что бэкапы реально восстанавливаются
Shared или VPS/VDS для MODX: быстрый выбор без лишней философии
Когда достаточно shared
- Небольшой сайт без пиков трафика и тяжёлых интеграций
- Есть возможность включить OPcache и выбрать актуальный PHP
- Важна экономия, а риск миграции приемлем
Когда лучше VPS/VDS
- Коммерческий проект: заявки, продажи, SEO-трафик
- Каталог/магазин/портал, много шаблонов и сниппетов
- Нужны Redis, тонкая настройка Nginx/Apache и безопасность
- Планируется рост и требуется предсказуемость
Практичное правило: если MODX — ключевая платформа бизнеса, лучше сразу выбирать VPS/VDS с NVMe и понятным SLA, чем «лечить симптомы» на перегруженном shared.
Производительность MODX: что даёт быстрый эффект
Пакет «ускорение за 1 день»
- Включить и настроить OPcache (и перезапускать PHP-FPM при деплое).
- Перевести кеш/сессии в Redis (если доступно).
- Настроить правильную отдачу статики: cache-control, gzip/brotli, WebP/AVIF.
- Подключить CDN для изображений и тяжёлой статики.
- Проверить БД: индексы, медленные запросы, размер таблиц, расписание оптимизации.
Что важно для будущего роста
- Staging-контур для обновлений MODX/Extras
- Мониторинг (нагрузка, диск, 5xx, время ответа)
- Регламент бэкапов + хранение вне сервера
- План апгрейда ресурсов без простоя
Важно
«Быстро» — это не только про CPU. Для MODX часто решает связка: NVMe + PHP-FPM + OPcache + грамотные правила чПУ + нормальная политика кеширования.
Именно это и отличает хостинг, который «просто запускает сайт», от хостинга, который помогает проекту расти.
FAQ: MODX хостинг (MODX Revolution)
Для небольших сайтов подойдёт качественный shared при наличии OPcache и актуального PHP. Для коммерческих проектов, каталогов и магазинов оптимальнее VPS/VDS на NVMe: изоляция ресурсов, гибкая настройка Nginx/Apache, PHP-FPM и возможность подключить Redis.
На практике безопасный ориентир для современных установок — PHP 8.1+ (особенно для MODX 3 и свежих Extras). Для отдельных старых проектов могут требоваться более старые версии, поэтому важно заранее проверить совместимость ядра и дополнений в тестовом контуре.
Типовой старт для VPS: 2 vCPU и 4 GB RAM, NVMe 40–60 GB. Для каталога/магазина разумно начинать с 4 vCPU и 8 GB RAM. Дальше масштабирование зависит от трафика, тяжести шаблонов, кеширования и качества запросов к БД.
Критично: pdo_mysql, mbstring, curl, json, xml/simplexml, gd или imagick, zip/zlib. Из настроек — memory_limit (лучше не ниже 128M), включённый OPcache, достаточные лимиты на загрузку файлов и выполнение скриптов.
Чаще всего причина в правилах переписи на веб-сервере (Nginx/Apache) и порядке обработки статических файлов. Решение — корректные rewrite/try_files, проверка редиректов и единая политика слешей/каноникал. Это стоит проверить ещё до переноса.
OPcache + PHP-FPM, перенос кеша в Redis, оптимизация отдачи статики (кеш-заголовки, Brotli/gzip, WebP/AVIF), подключение CDN, а также работа с «узкими местами» БД (индексы и медленные запросы).
Не обязателен, но очень полезен на нагруженных проектах: ускоряет операции кеша/сессий и снижает нагрузку на диск. Если Redis недоступен, важно хотя бы иметь быстрый диск и корректный файловый кеш.
Сделайте staging-копию, полный бэкап файлов и БД, синхронизируйте /assets/ и ключевые каталоги, понизьте TTL DNS, выполните финальную синхронизацию, переключите DNS и проверьте логи, ответы 4xx/5xx, sitemap и редиректы.
Есть ли доступ к логам и бэкапам? Можно ли включить OPcache? Доступен ли PHP 8.1+ и PHP-FPM? Какие реальные лимиты CPU/RAM/I/O? Есть ли защита от брутфорса и WAF? Как быстро масштабируются ресурсы на VPS?
Если нет времени и компетенций администрировать сервер, управляемый VPS снижает риски: обновления, безопасность, мониторинг и бэкапы обычно включены. Самостоятельный VPS выгоднее по цене и гибкости, но требует регулярной поддержки.