Разработчик берёт привычный Ubuntu VPS — тот же дистрибутив, на котором в компании крутится весь остальной стек, — и на середине установки коробочного Битрикс24 упирается в то, что официальный установщик окружения эту ОС вообще не знает. Установка коробочного Битрикс24 на Ubuntu VPS технически возможна, но это не «скачал скрипт — запустил» история, как для CentOS-семейства: весь веб-стек собирается руками, и дальше его тоже обслуживаете вы, а не мастер BitrixEnv. Ниже — пошаговая инструкция для разработчика, который уже работал с Linux-сервером по SSH и готов взять на себя ручную сборку окружения ради того, чтобы остаться на Ubuntu.
Если ручная сборка стека не самоцель, есть более короткий путь — развернуть портал на облачном сервере со штатным окружением вендора, мы разбирали его в статье про сервер для коробочного Битрикс24.
Статья не про то, что Ubuntu «хуже» для коробки — портал на ней работает ничем не хуже, чем на AlmaLinux. Разница только в том, кто собирает и потом чинит инфраструктуру: автоматика вендора или вы сами.
Что понадобится перед началом
- VPS с Ubuntu 22.04 LTS или 24.04 LTS, архитектура x86_64, root-доступ по SSH. Более старые релизы брать не стоит — они снимаются с поддержки Canonical раньше, чем истечёт жизненный цикл портала.
- Домен с доступом к DNS-записям. На голом IP портал запустится, но без валидного SSL не будет работать часть звонков и мобильного приложения.
- Лицензия «1С-Битрикс24» (коробочная редакция) или готовность поставить 30-дневную демо-версию — ставится тем же способом, ключ вводится позже.
- SSH-клиент и базовые навыки администрирования Linux: тут придётся руками ставить пакеты, а не тыкать пункты меню.
- Понимание, что официальной поддержки Ubuntu у окружения нет. Если жёсткой причины держать именно Ubuntu нет — честно: возьмите AlmaLinux 9 или Rocky Linux 9 и разверните окружение штатным BitrixEnv, вы сэкономите себе несколько часов и избавитесь от самостоятельного обслуживания стека.
Отдельно — про разницу продуктов. «1С-Битрикс: Управление сайтом» (обычный сайт-движок) прекрасно ставится на Ubuntu стандартным способом: nginx/Apache, PHP, MySQL — без всяких оговорок, официальные требования к окружению там не завязаны на конкретную ОС, это обычное PHP-приложение. Проблема именно с Коробкой: коробке нужен push-сервер, очереди сообщений и модуль поиска, а всё это на CentOS-семействе разворачивает и связывает между собой BitrixEnv. На Ubuntu аналогичной автоматики нет — эту часть собираем вручную, и именно она отличает установку коробки от установки обычного сайта на том же движке.
Установка коробочного Битрикс24 на Ubuntu VPS: разбираем по шагам
Шаг 1. Выбираем версию Ubuntu и считаем ресурсы
Заявленный вендором минимум по памяти и диску — это порог, при котором мастер установки вообще стартует, а не конфигурация для реальной работы:
push-сервер держит открытое соединение на каждого залогиненного сотрудника, MySQL/MariaDB ест память под буферный пул, поиск периодически переиндексируется в фоне.
Рабочий ориентир по нашим проектам:
- до 10 сотрудников — 2 ядра, 6 ГБ RAM, 40 ГБ NVMe;
- 10–25 сотрудников — 4 ядра, 8 ГБ RAM, 80 ГБ;
- 25–50 сотрудников — 6–8 ядер, 16 ГБ RAM, 100+ ГБ.
Ubuntu 22.04 LTS получает стандартные обновления безопасности до апреля 2027 года, 24.04 LTS — до апреля 2029-го (с подпиской Ubuntu Pro срок продлевается ещё на пять лет). Для нового проекта берите 24.04 — дольше проживёт без миграции на новый релиз.
Частота процессора здесь важнее числа ядер: PHP при сборке страницы портала выполняется в один поток, и на 3+ ГГц страница рендерится заметно быстрее, чем на слабом двухъядернике с той же суммарной мощностью. Берите тариф, где явно указана частота, а не только количество vCPU.
Диск считайте с запасом на файлы: коробка хранит документы, вложения в чатах, записи звонков и полную историю изменений CRM в базе. Расширение диска на боевом сервере — операция штатная, но с простоем и снапшотом «на всякий случай», лучше заложить объём один раз, чем делать это на живом портале.
Частая ошибка на этом шаге — считать ресурсы по числу купленных лицензий, а не по числу реально работающих в портале людей. Лицензия на 50 сотрудников при 15 активных не требует сервера на 50.
Шаг 2. Готовим сервер: обновления, часовой пояс, swap, файрвол
# Подключаемся по SSH
ssh root@ВАШ_IP
# Обновляем систему до актуального состояния
apt update && apt upgrade -y
# Выставляем часовой пояс — иначе даты в задачах и календаре разъедутся
timedatectl set-timezone Europe/Moscow
На машинах с 4–8 ГБ памяти файл подкачки спасает от того, что OOM-killer убивает MySQL в момент фоновой переиндексации:
# Создаём swap-файл на 4 ГБ
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
# Прописываем в fstab, чтобы swap подключался после перезагрузки
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Файрвол на Ubuntu обычно настраивают через UFW:
# Открываем SSH и веб — 80/443 достаточно, весь трафик, включая push-сервер,
# идёт через nginx на этих же портах (конфигурация — в шаге 3)
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
Наружу открываем только 80 и 443 — push-сервер (модуль мгновенных уведомлений) слушает локальный порт, наружу его не публикуем, а проксируем через тот же nginx отдельным location'ом, это разберём в шаге 3-4. Отдельные порты 8893/8894 нужны только для устаревшей версии push-сервера на nginx-push-stream-module, актуальная Node.js-версия работает через обычный HTTP(S) с апгрейдом до WebSocket.
Если у провайдера есть отдельный файрвол на уровне панели управления — открывайте порты и там тоже. Частая ошибка: настроить только UFW внутри сервера и забыть про фильтр в панели хостера (или наоборот), трафик режет любой из двух.
Шаг 3. Ставим веб-сервер, PHP и базу данных вручную
Здесь и начинается разница с CentOS-путём: вместо одного скрипта BitrixEnv собираем стек пакетами из репозиториев Ubuntu. Стек собираем под требования вендора по версиям PHP и базы данных — их нужно свериться перед установкой, потому что список поддерживаемых версий меняется от релиза к релизу.
# Ставим nginx фронтендом и Apache бэкендом — портал рассчитывает
# на .htaccess и mod_rewrite, которые нативно понимает только Apache
apt install -y nginx apache2
# Переключаем Apache на mpm_prefork — с mod_php он не уживается с event/worker
a2dismod mpm_event
a2enmod mpm_prefork rewrite
# Apache слушает только локально, наружу отдаёт nginx
sed -i 's/Listen 80/Listen 127.0.0.1:8080/' /etc/apache2/ports.conf
Ни в 22.04 (там по умолчанию PHP 8.1), ни в 24.04 (там по умолчанию PHP 8.3) нужного нам PHP 8.2 в стандартном репозитории нет — придётся подключить стороннюю PPA:
# Подключаем PPA Ondřej Surý — оттуда ставится нужная версия PHP
# на любой актуальной Ubuntu, стандартный репозиторий её не содержит
add-apt-repository -y ppa:ondrej/php
apt update
# Ставим PHP 8.2, модуль для Apache и расширения, которые требует Битрикс24
apt install -y php8.2 libapache2-mod-php8.2 php8.2-gd php8.2-mbstring php8.2-mysqli \
php8.2-curl php8.2-opcache php8.2-zip php8.2-xml php8.2-ldap php8.2-bcmath php8.2-intl
Ставить сразу PHP 8.3 из стандартного репозитория 24.04 не советуем: прежде чем брать самую свежую версию, сверьтесь с таблицей совместимости на сайте вендора для вашей редакции продукта — поддержка новых версий PHP у вендора традиционно отстаёт от релиза самого PHP на несколько месяцев. PHP 8.2 через PPA — самый предсказуемый вариант что на 22.04, что на 24.04.
Вариант с Apache-бэкендом — не единственный. Часть команд ставит связку nginx + PHP-FPM без Apache вообще, это проще в администрировании и экономит немного памяти. Но тогда придётся вручную переписывать правила из .htaccess в конфиг nginx — портал активно использует mod_rewrite и htaccess-директивы, которые nginx нативно не читает. Мы для коробки чаще берём связку с Apache именно поэтому: меньше риска потерять правило при очередном обновлении продукта.
Раз Apache теперь слушает только 127.0.0.1:8080, снаружи его никто не видит — нужен конфиг nginx, который принимает внешний трафик на 80/443 и передаёт его на Apache. Без этого шага сайт физически не откроется, даже если Apache и PHP настроены правильно:
# /etc/nginx/sites-available/bitrix24
server {
listen 80 default_server;
server_name portal.company.ru; # замените на свой домен, default_server ловит и обращения по голому IP
client_max_body_size 512M; # коробка регулярно получает файлы крупнее дефолтного лимита nginx в 1M
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 300; # экспорт отчётов и импорт из 1С — не самые быстрые операции
}
# WebSocket-канал push-сервера — сам процесс слушает только локально (шаг 4),
# наружу его не публикуем, всё идёт через тот же nginx на 80/443
location /bitrix/services/pull/ {
proxy_pass http://127.0.0.1:8895;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
# Включаем конфиг и убираем дефолтный сайт nginx, чтобы он не перехватывал запросы
ln -s /etc/nginx/sites-available/bitrix24 /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t && systemctl reload nginx
Порт 8895 для push-сервера — ориентировочный, реальный порт задаётся в его собственном конфиге на шаге 4; сверяйте оба места, если что-то не совпадёт — location в nginx будет проксировать в пустоту, и чат с уведомлениями молча не заработают.
# Ставим MariaDB — даёт совместимый с MySQL протокол
apt install -y mariadb-server
# Отключаем строгий режим InnoDB и фиксируем это в конфиге,
# а не только в рантайме, иначе настройка слетит после перезапуска
echo -e "[mysqld]\nsql_mode=NO_ENGINE_SUBSTITUTION" > /etc/mysql/mariadb.conf.d/60-bitrix.cnf
systemctl restart mariadb
# Создаём базу и пользователя для портала
mysql -e "CREATE DATABASE bitrix24 CHARACTER SET utf8mb4;"
mysql -e "CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'ПАРОЛЬ_БАЗЫ';"
mysql -e "GRANT ALL PRIVILEGES ON bitrix24.* TO 'bitrix'@'localhost';"
Если вендор требует именно MySQL Server 8.0 «в чистом виде» (например, для гарантий техподдержки), ставьте его из репозитория Oracle вместо MariaDB — команды похожие, разница только в подключаемом репозитории.
Шаг 4. Настраиваем memcached, Redis и push-сервер
# Кеш и очереди сессий
apt install -y memcached redis-server
# Node.js для push-сервера — версия из штатного репозитория Ubuntu
# обычно устаревшая, берём LTS-ветку через NodeSource
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
Push-сервер («Push & Pull» — модуль мгновенных уведомлений, чата и звонков) на CentOS-семействе разворачивает и регистрирует как systemd-сервис BitrixEnv автоматически. На Ubuntu аналогичной автоматики нет: пакет ставится вручную, а автозапуск и перезапуск при падении нужно настроить своим systemd-юнитом. Процесс должен слушать локальный порт (в конфиге nginx из шага 3 это 127.0.0.1:8895 — держите порт одинаковым в обоих местах) и наружу напрямую не торчать: весь внешний трафик идёт через nginx на 80/443, включая WebSocket-апгрейд. Это самая нестандартизированная часть установки — тестируйте её на некритичном контуре перед боевым запуском, детали отличаются между версиями продукта.
Без этого модуля портал будет работать, но живая лента, чат и уведомления в реальном времени — нет: клиент откатится на периодический опрос сервера, и сотрудники начнут жаловаться, что сообщения приходят с задержкой.
Шаг 5. Разворачиваем дистрибутив Коробки
# Готовим директорию сайта и права
mkdir -p /var/www/bitrix
cd /var/www/bitrix
wget -O bitrixsetup.php ССЫЛКА_СО_СТРАНИЦЫ_ЗАГРУЗКИ
chown -R www-data:www-data /var/www/bitrix
Файл bitrixsetup.php берётся со страницы загрузки коробочного Битрикс24 на сайте 1c-bitrix.ru — там же, где оформляется демо-версия. Открываем в браузере http://ВАШ_IP/bitrixsetup.php, ждём распаковку архива и попадаем в мастер установки.
Здесь важно не перепутать редакцию: выбираем именно «1С-Битрикс24», а не «1С-Битрикс: Управление сайтом» — это разные продукты с разным составом модулей, и после установки редакцию не меняют без переезда на новый дистрибутив.
В мастере два ключевых экрана. Первый — параметры базы: в отличие от BitrixEnv, где реквизиты подставляются автоматически, здесь реквизиты БД вводите руками — те, что задали на шаге 3. Второй — создание администратора портала: этот логин потом нельзя удалить, заводите его на общий ящик компании, а не на личную почту сотрудника.
[ФОТО: экран мастера установки Битрикс24 с параметрами подключения к базе данных]
Шаг 6. Домен, SSL и планировщик агентов
DNS: A-запись домена на IP сервера, проверяем через nslookup portal.company.ru. Дальше — сертификат, вручную через certbot, потому что шаблонов BitrixEnv для nginx здесь нет:
# Ставим certbot с плагином nginx и выпускаем сертификат
apt install -y certbot python3-certbot-nginx
certbot --nginx -d portal.company.ru
После смены адреса с IP на домен зайдите в настройки главного модуля и поправьте там адрес сайта — иначе ссылки в письмах-уведомлениях будут вести на старый IP.
Агенты портала (фоновые задачи: рассылки, бизнес-процессы, чистка логов) без BitrixEnv не запускаются автоматически — нужен свой cron:
# Добавляем задачу планировщика агентов от имени пользователя веб-сервера
crontab -u www-data -e
# строка внутри crontab:
# * * * * * /usr/bin/php -f /var/www/bitrix/bitrix/modules/main/tools/cron_events.php >/dev/null 2>&1
В «Настройки» → «Производительность» → «Проверка системы» портал честно покажет предупреждение о нестандартном серверном окружении — это ожидаемо для установки без BitrixEnv и не мешает работе, но означает, что при проблемах с окружением вендор может отказать в поддержке именно этой части стека.
Частые ошибки и как их избежать
Мастер установки ругается на версию PHP. Возникает, когда в системе стоит PHP ниже 8.2 (типично для более старых репозиториев) или не хватает расширений из шага 3. Решение: проверить php -v и php -m до запуска bitrixsetup.php, а не после третьей попытки установки.
Агенты не выполняются, письма и бизнес-процессы зависают. Причина почти всегда одна — забыли отключить строгий режим InnoDB, и часть внутренних запросов портала падает молча, без явной ошибки на экране. Решение: проверить SHOW VARIABLES LIKE 'sql_mode'; и убедиться, что настройка сохранена в конфиге, а не только применена вручную через консоль.
Чат и уведомления работают с задержкой в минуту. Диагноз — push-сервер не поднят, не пережил перезапуск сервера, либо его порт разошёлся с тем, что указан в location nginx. Проверяется командой ss -tlnp | grep 8895 (порт локального процесса) и логами nginx на предмет ошибок проксирования по /bitrix/services/pull/.
Письма с портала попадают в спам. Свежий IP облачного сервера не имеет ни SPF, ни DKIM, ни репутации у почтовых провайдеров. Решение — не отправлять почту напрямую с сервера, а подключить внешний SMTP в настройках главного модуля.
После обновления пакетов Apache портал отдаёт 500-ю ошибку. apt upgrade иногда возвращает Apache на mpm_event по умолчанию, если модуль был переустановлен вместе с зависимостями, — а mod_php с event/worker не работает. Решение: после любого крупного обновления системы проверять apache2ctl -M | grep mpm и держать это в чек-листе, а не полагаться, что настройка сохранится сама.
Из практики А2
Чаще всего к установке на Ubuntu приходят не потому, что искали именно этот путь, а потому что вся остальная инфраструктура компании уже там: Kubernetes, мониторинг, CI-раннеры — и заводить один сервер на AlmaLinux ради коробки в компании не хотят из соображений унификации парка. Это нормальная причина, мы такие проекты делаем.
На одном из них дважды словили одну и ту же проблему после переноса — агенты портала переставали выполняться через пару недель без единой ошибки в логах Apache. Причина оказалась в MariaDB: при обновлении пакета через apt upgrade конфиг из /etc/mysql/mariadb.conf.d/ подхватывался не всегда, а строгий режим InnoDB в этой версии пакета снова включался по умолчанию. После этого мы стали держать sql_mode отдельным файлом с проверкой в мониторинге, а не полагаться на то, что настройка выставлена один раз и навсегда.
Второе наблюдение — про push-сервер, он ломается почти всегда одинаково: систему обновили, Node.js перезапустился с другой версией зависимостей, сервис не поднялся сам, потому что не был оформлен как systemd-юнит с Restart=always. На CentOS-семействе с BitrixEnv эта проблема не возникает вообще — там перезапуск встроен в окружение. На Ubuntu это ваша зона ответственности, и про неё стоит помнить с первого дня, а не узнавать о ней от разгневанных пользователей чата.
Если жёсткой причины именно для Ubuntu нет — честно говорим клиентам: берите AlmaLinux 9 или Rocky Linux 9 и штатный BitrixEnv, обслуживание выйдет в разы дешевле по времени разработчика. Ubuntu для Коробки — оправданный выбор ровно тогда, когда унификация инфраструктуры важнее для бизнеса, чем экономия часов на пусконаладке одного сервера.
Итог
После шести шагов у вас работающий коробочный Битрикс24 на Ubuntu VPS: собранный вручную стек nginx + Apache + PHP 8.2 + MariaDB, push-сервер на Node.js, домен с валидным сертификатом и cron для фоновых агентов. Это рабочая, но неофициальная конфигурация — обслуживание стека и совместимость с будущими обновлениями продукта лежат на вас, а не на BitrixEnv. Если застряли на каком-то шаге — опишите ситуацию в комментарии или напишите нам напрямую.