Odoo на VPS в Docker: разворачиваем ERP-систему за 15 минут
Odoo — это не просто ERP, а целая экосистема: CRM, продажи, склад, бухгалтерия, eCommerce, производство, проекты и учёт — всё в одной системе с модульной архитектурой. Модули ставятся галочками, данные живут в единой базе PostgreSQL, а интерфейс открывается в браузере. Именно поэтому Odoo так популярен у небольших и средних компаний: одна система вместо пяти разрозненных программ. Но когда бизнес растёт, критичным становится не только сам Odoo, а то, где он развёрнут. От хостинга зависят скорость интерфейса, стабильность фоновых задач и безопасность данных. Для большинства компаний, стартапов и разработчиков оптимальное решение — VPS с Docker: выделенные ресурсы, полный контроль, предсказуемая производительность и развёртывание за 15 минут. В этой статье разберём конкретную рабочую схему: официальные контейнеры Odoo и PostgreSQL, том для кастомных модулей, автоматические бэкапы базы, обновление версий, reverse proxy с SSL — и расскажем, какой VPS нужен под Odoo, чтобы он работал быстро и не требовал постоянного вмешательства.
Почему VPS — лучшая площадка для Odoo
Общий хостинг делит процессор и память между десятками сайтов: нагрузка соседа напрямую бьёт по скорости вашей ERP, а лимиты на количество процессов и памяти часто не указаны в тарифе. VPS даёт выделенные vCPU и RAM, которые не отбираются ни у кого. Для Odoo это критично: PostgreSQL требует стабильной памяти под кэш, а интерфейс должен откликаться мгновенно, иначе сотрудники начинают жаловаться уже на 10-м пользователе. Второе преимущество — root-доступ: вы сами ставите Docker, настраиваете лимиты, swap и сеть, не спрашивая разрешения у хостера. Это важно для Odoo, потому что стандартные настройки PHP-хостинга сюда просто не подходят — нужен полноценный сервер. Третье — масштабирование: начали с 2 vCPU и 4 ГБ, через год добавили ещё 2 vCPU и 4 ГБ — без переезда, одной кнопкой в панели провайдера или командой. Четвёртое — предсказуемость: вы знаете, какие ресурсы доступны, и можете планировать рост, а не гадать, «почему всё тормозит по вечерам». Наконец, VPS дешевле выделенного сервера: вы платите за виртуальную машину, а не за всё железо целиком, при этом получаете тот же уровень контроля.
Odoo в Docker: зачем это нужно
Docker превращает развёртывание из «мануала на 40 шагов» в один файл, который можно хранить в Git. Официальные образы odoo и postgres поддерживаются сообществом и обновляются с каждым релизом: вам не нужно вручную собирать Python, ставить зависимости и настраивать PostgreSQL — всё уже упаковано и проверено. Контейнеры изолированы: версия Python, библиотеки и зависимости Odoo живут внутри образа и не конфликтуют ни с чем на сервере. Обновление — это смена тега образа и перезапуск. Откат — возврат тега. Перенос на другой сервер — docker compose up на новом месте, и вся система поднимается как была. Версионирование окружения — ещё один плюс: docker-compose.yml лежит в Git, и любой разработчик поднимает точную копию прода одной командой, без «а у меня работает». Для Odoo, где версии Python и PostgreSQL жёстко связаны с версией самой системы, это избавляет от целого класса проблем.
Готовый docker-compose за 15 минут
Самый простой рабочий вариант — два сервиса: odoo и postgres, с именованными томами для базы и файлов, политикой рестарта и healthcheck. Создайте файл docker-compose.yml:
```yaml services: odoo: image: odoo:17 depends_on: - db restart: unless-stopped ports: - "8069:8069" volumes: - odoo-data:/var/lib/odoo - ./addons:/mnt/extra-addons environment: - HOST=db - USER=odoo - PASSWORD=odoo
db: image: postgres:16 restart: unless-stopped environment: - POSTGRES_DB=postgres - POSTGRES_USER=odoo - POSTGRES_PASSWORD=odoo volumes: - db-data:/var/lib/postgresql/data
volumes: odoo-data: db-data: ```
Запуск — две команды: docker compose up -d, затем откройте http://ваш-сервер:8069 и пройдите мастер настройки базы. Пара важных деталей. Первая: restart: unless-stopped — контейнеры сами поднимутся после перезагрузки сервера и при падении, это критично для ERP, которую некому поднимать в 3 часа ночи. Вторая: пароль базы в проде обязательно смените и вынесите в файл .env (переменная POSTGRES_PASSWORD подставляется из окружения), а не храните в самом compose. Третья: порт 8069 наружу открывать не обязательно — если впереди стоит reverse proxy, отдавайте трафик через внутреннюю сеть Docker, а наружу откройте только 443. Так Odoo не будет торчать наружу напрямую.
Кастомные модули: том extra-addons
Стандартная поставка Odoo закрывает базовые сценарии, но почти любой бизнес дорабатывает систему: свои модели, отчёты, интеграции с 1С или маркетплейсами. Для этого существует каталог extra-addons — он подключён в compose как ./addons:/mnt/extra-addons. Кладёте модуль в папку addons на сервере (или подтягиваете его из Git-репозитория), включаете каталог в конфиге Odoo:
[options]
addons_path = /mnt/extra-addons
и в приложении Odoo обновляете список модулей: Apps → Update Apps List. Чтобы кастомные модули не потерялись при пересоздании контейнера, держите их в Git и подключайте папку как bind-mount, как в примере выше. Если модулей много — разбейте addons на несколько папок и перечислите их через запятую в addons_path. Помните про права: контейнер Odoo работает от пользователя odoo, поэтому папке addons нужны права на чтение (и на запись, если модули создают файлы). После добавления нового модуля перезапустите контейнер и обновите список приложений — модуль появится в списке и установится как обычный.
Бэкапы базы: pg_dump в cron
База PostgreSQL — это сердце Odoo: все заказы, контакты, настройки, отчёты и история операций. Потеряли базу — потеряли бизнес, поэтому бэкапы обязательны с первого дня, а не «потом». Простейший надёжный способ — pg_dump по расписанию. Скрипт сохраняет дамп с датой в имени, копирует его из контейнера наружу и ротирует старые копии:
#!/bin/bash
BACKUP_DIR=/root/backups/odoo
mkdir -p "$BACKUP_DIR"
STAMP=$(date +%F)
docker exec odoo-db-1 pg_dump -U odoo -d postgres -F c \
-f /tmp/odoo-$STAMP.dump
docker cp odoo-db-1:/tmp/odoo-$STAMP.dump "$BACKUP_DIR/"
docker exec odoo-db-1 rm -f /tmp/odoo-$STAMP.dump
find "$BACKUP_DIR" -name "*.dump" -mtime +14 -delete
Строка в crontab — ежедневно в 03:00, когда нагрузка минимальна:
0 3 * * * /root/backups/odoo-backup.sh
Формат -F c (custom) удобен тем, что pg_restore может выборочно восстанавливать объекты и параллельно. Восстановление: docker exec -i odoo-db-1 pg_restore -U odoo -d postgres --clean /tmp/backup.dump. Важно бэкапить не только базу, но и filestore — файлы вложений лежат в /var/lib/odoo/filestore (том odoo-data): без них в документах будут битые картинки. Проще всего бэкапить том целиком (tar или снапшот). Держите копии на отдельном диске или скачивайте в объектное хранилище: если сервер умрёт целиком, локальная копия на нём же не спасёт. И проверяйте восстановление хотя бы раз в месяц — дамп, который ни разу не разворачивали, считается «подозрительным».
Обновление и миграция между версиями
Odoo выходит с мажорными версиями ежегодно (16, 17, 18), и каждая мажорная версия требует миграции базы: просто заменить тег образа нельзя — структура данных меняется, и старые записи нужно конвертировать. Основные правила миграции: перед обновлением обязателен полный бэкап базы и файлов; миграция делается на копии, а не на проде — сначала поднимите новую версию рядом и проверьте; после обновления прогоните тесты ключевых сценариев (создание заказа, печать документов, отчёты). Odoo официально предоставляет репозиторий odoo-upgrade с утилитами для апгрейда; для сложных баз с большим количеством кастомных модулей лучше закладывать услуги сертифицированных партнёров Odoo — экономия на миграции оборачивается неделей простоя. Минорные обновления внутри версии (17.0 → 17.0.1) безопасны: достаточно сменить тег образа и перезапустить контейнер. Перед любым обновлением делайте снапшот VPS или полный дамп — откат всегда должен быть возможен одной командой. Кастомные модули проверяйте на совместимость с новой версией заранее: самый частый сбой при миграции — модуль, написанный под старый API.
Reverse proxy и SSL: Caddy или Traefik
Оставлять Odoo на голом http://ip:8069 небезопасно: пароли администратора и данные клиентов передаются открыто, а браузеры помечают сайт как небезопасный. Правильная схема — reverse proxy впереди контейнеров: он терминирует HTTPS, выпускает сертификаты автоматически и скрывает внутренние порты. Самый простой вариант — Caddy: сертификаты Let's Encrypt выпускаются автоматически при первом запросе, обновляются сами. Файл Caddyfile:
erp.example.com {
reverse_proxy odoo:8069
}
Caddy работает в той же Docker-сети, что и Odoo, и обращается к сервису по имени контейнера. Traefik даёт то же самое с динамическим конфигом через метки Docker: вы добавляете labels к сервису odoo, и Traefik сам создаёт маршрут и выпускает сертификат. Выбор между ними — дело вкуса: Caddy проще для одного сервиса, Traefik удобнее, когда впереди несколько приложений. Оба варианта полностью бесплатны. Ещё два штриха для продакшена: укажите в конфиге Odoo параметр web.base.url с вашим доменом (erp.example.com), иначе в письмах и ссылках будет внутренний адрес; а если используете LiveChat — откройте longpolling-порт 8072 в контейнере и пробросьте его в proxy, иначе чат не будет получать сообщения в реальном времени.
Какой VPS нужен для Odoo: CPU и RAM
Odoo требователен к памяти: PostgreSQL кэширует данные, а Python-воркеры держат состояние запросов. Минимальная конфигурация для тестов и 1–5 пользователей — 2 vCPU и 4 ГБ RAM; комфортно для 10–25 пользователей — 4 vCPU и 8 ГБ; для 50+ пользователей, тяжёлых отчётов или одновременной работы с большими базами — от 8 vCPU и 16 ГБ с NVMe-диском. Диск критичен: PostgreSQL работает тем быстрее, чем быстрее хранилище, поэтому NVMe вместо HDD даёт ощутимую разницу уже на старте, особенно при генерации отчётов и поиске по большим таблицам. Обязательно настройте swap (2–4 ГБ) — он спасает от внезапных OOM-kill, когда PostgreSQL резко разрастается. Планируйте запас: Odoo растёт с количеством модулей и пользователей, а добавлять память на VPS можно без переустановки — просто увеличить тариф. Сравнить тарифы и конфигурации разных провайдеров, отфильтровав по количеству ядер, объёму RAM и типу диска, можно в каталоге ServerScan — там собраны актуальные VPS-тарифы с ценами от множества хостинг-провайдеров.
Развёртывание за 15 минут: пошагово
- Выберите VPS: 2 vCPU, 4 ГБ RAM, NVMe, Ubuntu 22.04 или 24.04 (подборка тарифов — в каталоге ServerScan).
- Установите Docker и compose-плагин: curl -fsSL get.docker.com | sh.
- Создайте папку odoo, положите туда docker-compose.yml и Caddyfile из примеров выше.
- Запустите: docker compose up -d, проверьте логи: docker compose logs -f.
- Откройте erp.example.com, создайте базу через мастер установки Odoo.
- Настройте скрипт бэкапа и добавьте его в cron.
- Смените пароли по умолчанию: POSTGRES_PASSWORD в .env, мастер-пароль Odoo в конфиге.
- Настройте мониторинг: docker stats для быстрого взгляда, uptime-бот или панель на ваш вкус.
На этом базовая ERP-система работает. Дальше — модули, пользователи и интеграции.
Вопросы и ответы
Какой минимальный VPS нужен для Odoo?
Для теста и небольшой команды до 5 человек достаточно 2 vCPU и 4 ГБ RAM с NVMe-диском и swap на 2–4 ГБ. Это стандартный бюджетный VPS, которого хватает и на Odoo, и на PostgreSQL в контейнерах. Для продакшена с 10+ пользователями берите 4 vCPU и 8 ГБ и следите за свободной памятью.
Можно ли перенести существующий Odoo на VPS с Docker?
Да. Перенос сводится к дампу базы (pg_dump -F c), копированию каталога addons и filestore (лежит в /var/lib/odoo/filestore), развёртыванию compose на новом сервере и восстановлению базы (pg_restore). Версия Odoo должна совпадать, иначе нужна миграция. Подробная последовательность описана в официальной документации Odoo и в статьях сообщества.
Дорого ли обойдётся VPS под Odoo?
Дешевле, чем выделенный сервер или SaaS-подписка Odoo на длинной дистанции: вы платите только за ресурсы и управляете всем сами. Бюджетные тарифы с 2 vCPU и 4 ГБ есть у большинства провайдеров — сравните цены, условия и тип диска в каталоге ServerScan, там же удобно фильтровать по RAM и ядрам.
Итог
Odoo на VPS в Docker — это сочетание контроля и простоты: официальные образы, один compose-файл, автоматические бэкапы, HTTPS из коробки и честное масштабирование. 15 минут на развёртывание, а дальше система работает и обновляется без сюрпризов. Главное — не экономить на бэкапах и диске: PostgreSQL с NVMe, swap и ежедневный pg_dump окупаются в первый же инцидент. Подберите подходящий VPS по CPU и RAM в каталоге ServerScan, разверните по этому гайду — и ваша ERP будет работать быстро и предсказуемо.
_Статья обновлена 23.08.2026 по материалам каталога ServerScan._