Как установить и настроить Odoo на VPS

MAATRIX

Odoo Online удобен, пока не начинаешь считать: подписка растёт с каждым пользователем и модулем, а данные компании — продажи, склад, бухгалтерия — лежат на чужой инфраструктуре. Self-hosted Odoo на своём VPS снимает оба вопроса разом: платите один раз за сервер, а не за каждого сотрудника, и полностью контролируете, где физически находятся данные. Разворачивается это не сложнее, чем любой другой веб-сервис на Linux — ниже пошагово: от чистого сервера до рабочей ERP с HTTPS и продакшн-настройками.

Что нужно перед стартом

Odoo — это Python-приложение поверх PostgreSQL, плюс веб-интерфейс на порту 8069. Ресурсы зависят от нагрузки:

• Минимум для теста/малого бизнеса (1 компания, до 10 одновременных пользователей, пара модулей вроде продаж и склада) — 2 vCPU, 4 ГБ RAM, 40 ГБ SSD.
• Продакшн с несколькими модулями (производство, бухгалтерия, документооборот, десятки пользователей) — от 4 vCPU и 8 ГБ RAM, диск лучше сразу брать с запасом: вложения и документы уходят в filestore на диске, а не только в базу.

Понадобятся: чистый Ubuntu 24.04 LTS (подходит и Debian 12), домен с A-записью на IP сервера — без него не выпустить SSL, и root-доступ по SSH. Дальше все команды — от root или через sudo.

Устанавливаем PostgreSQL и системные зависимости

Обновите систему и поставьте PostgreSQL — единственную поддерживаемую Odoo СУБД — и пакеты, без которых Odoo не соберёт PDF-отчёты и статику фронтенда:

apt update && apt -y upgrade
apt -y install postgresql python3-pip python3-venv python3-dev \
  build-essential libxml2-dev libxslt1-dev libjpeg-dev \
  libpq-dev libldap2-dev libsasl2-dev libffi-dev \
  wkhtmltopdf git node-less npm

wkhtmltopdf отвечает за генерацию PDF (счета, накладные, коммерческие предложения) — без него печатные формы не сформируются. Создайте отдельного системного пользователя, от имени которого будет работать сервис — так процесс Odoo не имеет root-прав и не может случайно испортить систему:

adduser --system --home=/opt/odoo --group odoo

Теперь роль в PostgreSQL с правом создавать базы (Odoo сама создаёт БД под каждую компанию через веб-интерфейс):

su - postgres -c "createuser -s odoo"

Флаг -s даёт суперпользователя PostgreSQL — это стандартная практика для self-hosted Odoo, поскольку установка модулей и создание новых баз идёт от этого имени. Если сервер смотрит наружу несколькими сервисами, разумно ограничить доступ к PostgreSQL только localhost (по умолчанию так и есть в pg_hba.conf) — подробнее о самой настройке PostgreSQL можно посмотреть в отдельном руководстве по установке PostgreSQL на VPS.

Устанавливаем Odoo из официального репозитория

Самый быстрый и наименее хлопотный путь — официальный apt-репозиторий Odoo, который сам решает зависимости и разворачивает системный сервис. Подключите ключ и репозиторий (подставьте нужную ветку вместо 18.0, если работаете с другой версией):

wget -O - https://nightly.odoo.com/odoo.key | \
  gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] \
  https://nightly.odoo.com/18.0/nightly/deb/ ./" \
  > /etc/apt/sources.list.d/odoo.list
apt update
apt -y install odoo

Пакет сам подтянет python-зависимости, создаст пользователя odoo (если его не было), положит конфиг в /etc/odoo/odoo.conf и юнит systemd. По умолчанию сервис слушает 0.0.0.0:8069 — это нормально для тестов, но в продакшне порт наружу закрывать (об этом ниже, в разделе про Nginx и фаервол).

Альтернатива — установка из исходников через git и venv: даёт больше контроля, удобна, если ставите кастомные модули или конкретный минорный коммит:

su - odoo -s /bin/bash
git clone --depth 1 --branch 18.0 https://github.com/odoo/odoo.git /opt/odoo/odoo-server
python3 -m venv /opt/odoo/venv
source /opt/odoo/venv/bin/activate
pip install wheel
pip install -r /opt/odoo/odoo-server/requirements.txt

Для большинства задач пакетной установки из репозитория достаточно — дальше в статье конфиги приводятся под неё, но логика одинакова для обоих вариантов, разница только в путях.

Настраиваем odoo.conf

Откройте /etc/odoo/odoo.conf и приведите ключевые параметры к рабочему виду:

[options]
admin_passwd = замените_на_длинный_случайный_пароль
db_host = localhost
db_port = 5432
db_user = odoo
db_password = False
addons_path = /usr/lib/python3/dist-packages/odoo/addons,/opt/odoo/custom-addons
default_productivity_apps = True
logfile = /var/log/odoo/odoo.log
logrotate = True

Два момента, которые часто упускают на новых установках. Первое — admin_passwd это мастер-пароль управления базами (создание/удаление/бэкап через /web/database/manager), а не пароль администратора компании. Дефолтное значение известно каждому, кто читал документацию Odoo, — не поменяете, и любой найдёт ваш /web/database/manager и снесёт базу. Второе — addons_path должен включать отдельную папку для собственных или сторонних модулей, которую не затронет обновление пакета:

mkdir -p /opt/odoo/custom-addons
chown -R odoo:odoo /opt/odoo/custom-addons /var/log/odoo

После правки конфига перезапустите сервис и проверьте лог на ошибки подключения к БД:

systemctl restart odoo
journalctl -u odoo -n 50 --no-pager

Если всё запустилось без ошибок, Odoo уже отвечает на http://IP_сервера:8069 — но открывать его наружу в таком виде не стоит, дальше закрываем порт и выводим сервис через Nginx с SSL.

Nginx как reverse-proxy и SSL

Ставим Nginx и certbot, если их ещё нет:

apt -y install nginx certbot python3-certbot-nginx

Создайте /etc/nginx/sites-available/odoo.conf. Важные детали именно для Odoo: отдельный location для лонгполлинга (порт 8072, обслуживает live-чат и уведомления в реальном времени), увеличенный proxy_read_timeout (тяжёлые отчёты и импорт больших файлов не укладываются в дефолтные 60 секунд) и кэширование статики:

upstream odoo {
    server 127.0.0.1:8069;
}
upstream odoochat {
    server 127.0.0.1:8072;
}

server {
    listen 80;
    server_name erp.vashdomen.ru;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;

    location /longpolling {
        proxy_pass http://odoochat;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://odoo;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location ~* /web/static/ {
        proxy_cache_valid 200 90m;
        proxy_pass http://odoo;
        add_header Cache-Control "public, max-age=86400";
    }
}

Активируйте конфиг и получите сертификат:

ln -s /etc/nginx/sites-available/odoo.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d erp.vashdomen.ru

Ещё один шаг, который легко забыть: скажите самой Odoo, что она за прокси, иначе в логах и редиректах будет путаница со схемой http/https. В odoo.conf добавьте:

proxy_mode = True

И закройте порт 8069 для внешних подключений — оставьте доступ только через Nginx:

ufw allow 'Nginx Full'
ufw deny 8069

Если фаервол ещё не настраивали, есть отдельный разбор настройки UFW на VPS, а сама логика reverse-proxy на Nginx для других сервисов расписана в статье про Nginx как reverse proxy; там же про частые грабли — если SSL после certbot почему-то не подхватывается, смотрите разбор проблем с Let's Encrypt.

Продакшн: воркеры, память, бэкапы и обновления

Дефолтная конфигурация Odoo однопоточная (workers = 0) — годится для разработки, но в продакшне блокирующий запрос от одного пользователя тормозит всех остальных. Включите мультипроцессный режим — ориентировочная формула из документации Odoo: workers = (число ядер × 2) + 1, плюс отдельный поток под cron-задачи:

workers = 5
max_cron_threads = 1
limit_memory_soft = 671088640
limit_memory_hard = 805306368
limit_time_cpu = 600
limit_time_real = 1200
db_maxconn = 64

Лимиты памяти — «мягкий» и «жёсткий» пороги на один воркер-процесс, при превышении жёсткого Odoo перезапускает воркер, не роняя весь сервис. Значения ориентировочные (примерно 640 МБ / 768 МБ) — на реальной нагрузке с конкретными модулями подберите свои по факту потребления, смотрите htop во время рабочего дня. При 5 воркерах плюс cron-поток серверу нужно закладывать памяти с запасом сверх этих лимитов — отсюда минимум 8 ГБ RAM для продакшна из первого раздела.

Бэкап Odoo — это не только pg_dump базы, но и папка filestore с вложениями (по умолчанию /opt/odoo/.local/share/Odoo/filestore/<имя_базы>), иначе после восстановления база "знает" про документы, которых физически нет на диске:

sudo -u odoo pg_dump -Fc имя_базы > /backup/odoo_$(date +%F).dump
tar -czf /backup/filestore_$(date +%F).tar.gz \
  /opt/odoo/.local/share/Odoo/filestore/имя_базы

Для регулярного и надёжного бэкапа лучше не городить это в cron вручную, а взять готовый инструмент — например, BorgBackup с дедупликацией и шифрованием, добавив в список путей и дамп базы, и filestore.

Обновление модулей после изменения кода или установки новых приложений выполняется без перезапуска веб-сервера, отдельной командой с флагом -u:

sudo -u odoo /usr/bin/odoo -c /etc/odoo/odoo.conf -d имя_базы -u all --stop-after-init

На проде это стоит гонять только после проверки на копии базы — мажорные обновления модулей (особенно после апгрейда версии Odoo) иногда ломают кастомные вьюхи или отчёты, и лучше поймать это на staging, а не на боевых данных.

Частые вопросы