Устанавливаем SuiteCRM 8.8 на VPS с нуля: Ubuntu 24.04, PHP 8.3, MariaDB, русификация

Требования к серверу: практика, а не минималки

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом компаний до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и внедряем клиентам open-source CRM. SuiteCRM — форк SugarCRM Community Edition от британской компании SalesAgility, распространяется под лицензией AGPLv3, скачивается с suitecrm.com. Это статья-регламент: ровно тот порядок действий, по которому моя команда разворачивает SuiteCRM 8 на чистом VPS и сдаёт клиенту работающую русскоязычную систему. Все команды — реальные, я не выдумываю их для красоты.

Сначала честно про версии, потому что в заголовке стоит «8.8», а серия про неё. На момент, когда я пишу эту статью, актуальна уже ветка 8.9.x — последний релиз 8.9.2 вышел 13 января 2026 года. Ветка 8.8 в своё время принесла поддержку PHP 8.3 и обновлённый Angular 18, ветка 8.10.x добавила PHP 8.4. Практический вывод простой: ставьте самый свежий стабильный релиз ветки 8.x — процесс развёртывания идентичен для всей ветки, команды те же, отличаются только номера в имени архива. Я не утверждаю, что 8.8 — самая новая; я показываю процесс на примере ветки, а вы берёте актуальный на день установки релиз.

Официальный минимум и наши рабочие цифры

Официально SuiteCRM 8 запускается на скромном железе — 2 vCPU и 4 ГБ памяти на бумаге хватает. Но SuiteCRM 8 заметно тяжелее той же EspoCRM: под капотом Angular-фронтенд (каталог public/) поверх легаси-ядра седьмой ветки (доступ через /legacy), а это два приложения в одном. Поэтому под реальный отдел продаж мы берём с запасом:

Диск считайте с прицелом на вложения: коммерческие предложения, сканы договоров, письма с приложениями за год активной работы отдела спокойно набирают десятки гигабайт. Дешевле сразу взять SSD побольше, чем через полгода мигрировать на новый тариф.

Совместимость версий: сверяйтесь с матрицей

Ветка 8.x развивается быстро, и требования к PHP меняются от релиза к релизу. Ключевые вехи: начиная с 8.7 сброшена поддержка PHP 7.4, версия 8.8 добавила PHP 8.3, а 8.10.x — PHP 8.4. То есть на ветке 8.8/8.9 рабочая пара — PHP 8.2 или 8.3. Не полагайтесь на мою память или чужие статьи: перед установкой откройте официальную матрицу совместимости docs.suitecrm.com/8.x/admin/compatibility-matrix/ и сверьте PHP, СУБД и веб-сервер под конкретный релиз, который скачиваете.

Почему не shared-хостинг

Вопрос всплывает на каждой второй встрече: «а можно поставить на обычный хостинг за 200 рублей?». Технически иногда да, практически — нет, и вот почему. На shared-хостинге вы не управляете версией PHP и набором расширений, не можете поднять memory_limit до нужных значений, у вас нет доступа к системному cron под нужным пользователем, а CLI-инсталлятор bin/console требует shell-доступа, которого на шареде обычно нет. SuiteCRM 8 с его Angular-сборкой и легаси-роутингом на шаред-хостинге либо не встанет, либо будет работать на грани таймаутов. Только VPS или выделенный сервер — это позиция и вендора, и наша.

Подготовка площадки: ОС, стек и база данных

Разворачиваем на Ubuntu 24.04 LTS: долгоживущий релиз с поддержкой до 2029 года, в штатных репозиториях лежит PHP 8.3 — ровно то, что нужно ветке 8.8/8.9. Никаких сторонних PPA и сборки из исходников не понадобится.

Базовая гигиена сервера

До установки CRM приводим свежий VPS в порядок. Обновляем систему, включаем файрвол, ставим fail2ban против перебора паролей и автообновления безопасности:

apt update && apt upgrade -y
apt install -y ufw fail2ban unattended-upgrades
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
dpkg-reconfigure -plow unattended-upgrades

Открываем наружу только SSH, HTTP и HTTPS. Порт СУБД снаружи не публикуем никогда — база слушает localhost. fail2ban с дефолтным jail для sshd закрывает самую частую атаку по серверу, торчащему в интернет, — брутфорс SSH.

Ставим стек: PHP 8.3, MariaDB, nginx

Весь стек прилетает из штатных репозиториев Ubuntu 24.04 одной командой. SuiteCRM требователен к набору расширений PHP — перечисляю их явно, чтобы инсталлятор не споткнулся на проверке окружения:

apt install -y nginx mariadb-server \
  php8.3-cli php8.3-fpm php8.3-mysql php8.3-gd php8.3-zip \
  php8.3-imap php8.3-ldap php8.3-curl php8.3-intl \
  php8.3-mbstring php8.3-xml php8.3-bcmath unzip

Здесь важен каждый пакет. intl и mbstring нужны для корректной работы с кириллицей и локалями — без них русский язык поедет кашей. imap — для входящей почты, ldap — для интеграции с Active Directory, gd — для превью и графики, zip — для Module Loader, через который мы позже поставим русификацию. После установки проверяем версию: php -v должна показать 8.3.

Настройка php.ini под SuiteCRM

Дефолтные лимиты PHP для SuiteCRM малы: инсталлятор и особенно Module Loader упираются в память и время выполнения. Правим оба конфига — для FPM (веб) и для CLI (консольный инсталлятор): /etc/php/8.3/fpm/php.ini и /etc/php/8.3/cli/php.ini:

memory_limit = 512M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
max_input_vars = 5000

memory_limit 512M — это не роскошь: легаси-ядро SuiteCRM при Quick Repair and Rebuild и установке модулей ест память жадно, на 256M русский языковой пакет ставится не всегда. upload_max_filesize и post_max_size работают в паре — ставьте их одинаковыми и под реальный размер вложений клиента. max_input_vars поднимаем, потому что формы настроек SuiteCRM большие, и на дефолтной тысяче часть полей молча теряется. После правки перезапускаем pool: systemctl restart php8.3-fpm.

Создаём базу и пользователя в кодировке utf8mb4

Кодировка строго utf8mb4 — старая трёхбайтовая utf8 в MySQL не хранит эмодзи и часть символов, и первый же нестандартный символ в комментарии менеджера уронит запись. Root приложению не даём — заводим отдельного пользователя с правами только на свою схему:

mariadb -u root
CREATE DATABASE suitecrm CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'suitecrm'@'localhost' IDENTIFIED BY 'СложныйПароль_сюда';
GRANT ALL PRIVILEGES ON suitecrm.* TO 'suitecrm'@'localhost';
FLUSH PRIVILEGES;
EXIT;

MariaDB 10.11 из репозитория Ubuntu 24.04 подходит без доработок. Пароль пользователя базы генерируйте случайным и сразу кладите в менеджер паролей — он понадобится на шаге установки и потом уедет в чек-лист передачи клиенту.

Установка SuiteCRM 8: файлы, права и конфиг nginx

Стек готов, база создана — переходим к самой CRM. Скачиваем свежий релиз ветки 8.x со страницы suitecrm.com/download (там всегда лежит актуальный ZIP), распаковываем в веб-каталог и — внимание — правильно расставляем права. Права на каталоги — грабля номер один при установке SuiteCRM: ошибётесь здесь, и после установки получите белый экран вместо интерфейса.

Скачивание и распаковка

cd /var/www
wget https://suitecrm.com/download/165/suite89/564148/suitecrm-8-9-2.zip -O suitecrm.zip
unzip suitecrm.zip -d suitecrm
cd suitecrm

Точный URL и имя архива берите со страницы загрузки под свою версию — прямые ссылки со временем меняются. Распаковали — сразу расставляем владельца и права. SuiteCRM пишет в свои каталоги во время работы, поэтому владельцем должен быть пользователь веб-сервера www-data:

chown -R www-data:www-data /var/www/suitecrm
cd /var/www/suitecrm
find . -type d -not -perm 2755 -exec chmod 2755 {} \;
find . -type f -not -perm 0644 -exec chmod 0644 {} \;
find ./cache ./custom ./modules ./themes ./upload -type d -exec chmod 2775 {} \;
chmod +x bin/console

Каталоги 644 для файлов и 755 для директорий — базовый минимум; каталогам, в которые SuiteCRM пишет во время работы (cache, custom, modules, themes, upload), даём групповую запись. Без этого веб-инсталлятор либо не пройдёт проверку прав, либо установка завершится, но интерфейс встретит вас белым экраном — легаси-ядро не сможет писать кэш.

CLI-инсталлятор против веб-инсталлятора

SuiteCRM 8 можно установить через браузер, но мы предпочитаем консольный инсталлятор: он не зависит от таймаутов веб-сервера, повторяем его одной командой при пересборке стенда, и он честно возвращает код ошибки в скрипт. Запускаем от имени www-data, чтобы созданные файлы сразу имели правильного владельца:

sudo -u www-data php bin/console suitecrm:app:install \
  --db-username="suitecrm" \
  --db-password="СложныйПароль_сюда" \
  --db-host="127.0.0.1" \
  --db-name="suitecrm" \
  --site-username="admin" \
  --site-password="АдминскийПароль" \
  --site-host="https://crm.example.ru"

Параметр --site-host критичен: он совпадает с адресом, по которому пользователи будут открывать CRM. Ошибётесь здесь — получите петлю логина и битые ссылки в письмах (разбираю в разделе граблей). Инсталлятор развернёт схему БД, соберёт Angular-фронт и настроит легаси-ядро. Если предпочитаете браузерный путь — просто откройте домен и следуйте мастеру, но лимиты php.ini из прошлого раздела обязаны быть подняты заранее.

Эталонный server-блок nginx

Ключевая особенность SuiteCRM 8 — два контекста в одном сайте. Новый Angular-фронт живёт в каталоге public/ (это корень сайта), а легаси-ядро седьмой ветки доступно по префиксу /legacy. Оба должны корректно маршрутизироваться, иначе половина функций (админка, часть модулей) отвалится с ошибкой 500. Вот блок, который мы кладём в /etc/nginx/sites-available/suitecrm:

server {
    listen 80;
    server_name crm.example.ru;
    root /var/www/suitecrm/public;
    index index.php;
    client_max_body_size 64M;

    # Angular-фронт SuiteCRM 8
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Легаси-ядро седьмой ветки
    location /legacy {
        try_files $uri $uri/ /legacy/index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;
    }

    # Закрываем служебные каталоги от прямого доступа
    location ~* /(cache|custom|modules|vendor|logs)/.*\.(php|log|sql)$ {
        deny all;
    }
    location ~ /\. { deny all; }
}

Обратите внимание: fastcgi_read_timeout 300 совпадает с max_execution_time из php.ini — иначе nginx оборвёт долгую операцию (например, Repair and Rebuild) раньше, чем PHP её доработает. А client_max_body_size 64M должен совпадать с upload_max_filesize, иначе большой файл nginx завернёт с ошибкой 413 ещё на подлёте. Активируем сайт и перезапускаем: ln -s /etc/nginx/sites-available/suitecrm /etc/nginx/sites-enabled/ && nginx -t && systemctl reload nginx.

Первый вход и базовая настройка

Инсталлятор отработал, nginx настроен — открываем https://crm.example.ru и заходим под администратором. Но система в этот момент ещё наполовину мертва: не работает планировщик, не уходит почта. Разбираю обязательные шаги, которые нельзя пропускать.

Планировщик: cron под www-data каждую минуту

Это второй по частоте провал после прав на каталоги. В SuiteCRM на планировщике держится всё фоновое: рассылки, workflow (автоматические процессы), напоминания, забор почты, индексация поиска. Без cron ничего из этого не работает, а система при этом выглядит живой — и клиент неделю недоумевает, почему не уходят письма. Добавляем задание пользователю www-data раз в минуту. В SuiteCRM 8 планировщик вызывается через оба контекста — новый bin/console и легаси cron.php:

crontab -e -u www-data
* * * * * cd /var/www/suitecrm; php -f public/legacy/cron.php > /dev/null 2>&1

Именно раз в минуту и именно под www-data — если запустить под root, тот создаст в cache/ файлы с чужим владельцем, и веб-процесс потом не сможет их перезаписать (это опять белый экран). После добавления зайдите в Admin → Scheduler и убедитесь, что задания получают свежее время последнего запуска, а не «никогда».

SMTP для исходящей почты

Заходим в Admin → Email Settings и прописываем SMTP вашего почтового сервера: хост, порт, шифрование, логин ящика-отправителя. Без этого SuiteCRM не отправит ни приглашение новому пользователю, ни уведомление, ни письмо клиенту из карточки. Сразу жмём кнопку тестовой отправки и проверяем, что письмо дошло и не улетело в спам. Если домен без SPF/DKIM — сначала настройте их, иначе вся исходящая корреспонденция CRM поедет в «нежелательное».

Русификация через Module Loader

SuiteCRM 8 из коробки — англоязычная. Русский язык ставится отдельным языковым пакетом через штатный механизм Module Loader. Мы используем пакет из открытого проекта на GitHub (github.com/likhobory/SuiteCRM-CoreRU) — это наиболее полный русский перевод для ветки 8.x. Ниже — пошагово, как мы это делаем на каждом внедрении.

Пошаговый процесс

1. Скачиваем пакет под свою версию. В репозитории на GitHub в разделе релизов лежат ZIP-архивы под конкретные ветки SuiteCRM. Берём ровно тот, что соответствует установленному релизу 8.x — пакет от несовместимой версии установится криво.
2. Открываем Module Loader. Admin → Module Loader (в SuiteCRM 8 он в легаси-разделе администрирования).
3. Если стоял старый пакет — сначала Uninstall. Обновление языкового пакета «поверх» — частая причина ошибок вида «Undefined index». Правильный порядок: удалить старую версию через Uninstall, только потом ставить новую.
4. Upload и Install. Загружаем ZIP через форму Upload, дожидаемся появления пакета в списке, жмём Install и подтверждаем.
5. Выставляем ru_RU языком по умолчанию. Admin → Locale → язык по умолчанию ru_RU. Теперь новые пользователи получают русский интерфейс сразу.
6. Quick Repair and Rebuild. Admin → Repair → Quick Repair and Rebuild — обязательный финальный шаг. Он пересобирает кэш языковых файлов и метаданных. Без него часть надписей останется английской, а в интерфейсе могут вылезти ошибки «Undefined index».

Честно предупреждаю клиентов об этой зависимости от энтузиаста на этапе выбора системы: языковой пакет — общественный проект, у которого нет SLA. На практике его сопровождают активно и под каждую ветку 8.x пакет выходит, но закладываться на мгновенное обновление перевода в день выхода нового релиза ядра не стоит.

HTTPS и домен: certbot без сюрпризов

CRM с клиентской базой обязана работать только по HTTPS. Выпускаем сертификат Let's Encrypt через certbot с плагином nginx — и здесь есть грабля, на которой мы обожглись в своё время.

apt install -y certbot python3-certbot-nginx
certbot --nginx -d crm.example.ru --redirect --hsts

Флаг --nginx означает, что аутентификация домена (проверка, что домен ваш) идёт через уже работающий nginx. Не используйте --standalone: этот режим поднимает собственный веб-сервер на порту 80, который у вас занят nginx, — выпуск и особенно автопродление провалятся с конфликтом на :80. Именно так один клиентский сервер встретил понедельник с протухшим сертификатом: изначально сертификат выпустили через standalone, и первое автопродление через 60 дней тихо упало.

Флаги --redirect и --hsts настроят редирект с 80 на 443 и добавят заголовок HSTS — браузер сотрудника после первого визита будет ходить в CRM только по шифрованному каналу. Проверяем автопродление заранее, не дожидаясь 90-го дня:

certbot renew --dry-run

Грабли установки: топ-7 из практики

Финальная выжимка — то, с чем мы реально сталкивались на инсталляциях SuiteCRM 8 у клиентов. Каждая строка таблицы — сэкономленные вам часы диагностики. Формат привычный: симптом → причина → лечение.

Общий знаменатель большинства проблем: SuiteCRM 8 — это два приложения (Angular-фронт и легаси-ядро) плюс тяжёлый Module Loader, поэтому две трети граблей — это либо права на каталоги, либо недонастроенный веб-сервер, либо задушенные лимиты PHP. Пройдите разделы про права, nginx и php.ini аккуратно — и большинства строк этой таблицы вы просто не увидите.

Чек-лист передачи клиенту

Перед тем как сдать SuiteCRM клиенту в боевую эксплуатацию, мы прогоняем внутренний чек-лист приёмки. Делюсь рабочей версией из 12 пунктов — прогоните по нему свою инсталляцию, даже если ставили для себя.

1. HTTPS валиден. Замок зелёный, certbot renew --dry-run проходит без ошибок, редирект с 80 на 443 работает.
2. Cron планировщика жив. Admin → Scheduler: у заданий свежее время последнего запуска (минуты назад, не «никогда»).
3. Исходящая почта работает. Тестовое письмо из карточки доходит до адресата и не падает в спам.
4. Русский язык по умолчанию. ru_RU выставлен дефолтом, Quick Repair and Rebuild выполнен, интерфейс русский.
5. Права на каталоги корректны. Владелец www-data, служебные каталоги с групповой записью, логов об ошибках записи нет.
6. Служебные каталоги закрыты. Прямой запрос к конфигу и файлам в cache/, custom/ из браузера даёт отказ, а не содержимое.
7. Часовой пояс и локаль под РФ. Europe/Moscow, формат DD.MM.YYYY, 24 часа, валюта RUB.
8. Бэкап настроен и проверен. Автоматический дамп БД и архив файлов (custom, upload, public/legacy/config.php), развёрнутый на тестовой площадке хотя бы раз.
9. Роли и права заданы. Менеджеры видят свои записи, экспорт данных — только у руководителя.
10. OPcache и лимиты PHP выставлены. Интерфейс отзывчивый, memory_limit 512M, opcache включён.
11. Файрвол и fail2ban активны. ufw открывает только 22/80/443, fail2ban банит перебор.
12. Админ-пароль передан безопасно. Учётка администратора и пароль БД лежат в менеджере паролей клиента, а не в переписке; клиенту передана ссылка на русскую документацию docs.suitecrm.com/ru.

Последний пункт про документацию не формальность: администратору на стороне клиента будет к чему обращаться, а вам меньше однотипных вопросов. На этом развёртывание закончено — у клиента работающая русскоязычная SuiteCRM 8 на собственном сервере, под HTTPS, с живым планировщиком и настроенной почтой. Дальше начинается эксплуатация: обновления, бэкапы, мониторинг — но это уже тема отдельного регламента.