SeaTable в Docker Compose: готовый файл

MAATRIX

Airtable красив и удобен, пока не доходит до счёта за десяток мест в команде или до вопроса, где физически лежит база клиентов компании. SeaTable — один из немногих self-hosted инструментов в этой нише, который не упрощает Airtable до примитивной таблицы: связи между таблицами, формулы, представления канбан/календарь/галерея и, что важнее всего, встроенные автоматизации с возможностью писать серверные Python-скрипты — всё это остаётся при переезде на свой сервер. Ниже — рабочий docker-compose.yml, разбор официального install-скрипта SeaTable (он тут не такой, как у Baserow или NocoDB) и нюансы, которые всплывают при бэкапах и обновлении версии.

Что такое SeaTable и чем он отличается от Baserow и NocoDB

SeaTable — немецкий продукт, его делает та же команда, что стоит за файловым синхронизатором Seafile, и архитектурное наследство заметно: данные хранятся не как тонкая обвязка над обычной реляционной таблицей, а в собственном формате DTable, который разработчики и продают как главное преимущество — по их заявлениям, таблицы SeaTable выдерживают значительно больше строк, чем аналоги на классическом Postgres/MySQL-слое. Это ориентир от вендора, а не измеренный бенчмарк — на своих данных и своём железе цифры будут отличаться, проверяйте нагрузочным тестом перед тем, как переносить туда боевой процесс.

Из коробки в SeaTable есть:

• Представления — таблица, канбан, календарь, галерея, а также группировки и фильтры поверх одной базы данных.
• Формулы, lookup и link-колонки — связи между таблицами внутри базы и между разными базами.
• Automation Rules — правила «триггер → условие → действие» прямо в интерфейсе, без выноса в отдельный Zapier/Make.
• Встроенный Python-скриптинг — можно написать серверный скрипт, который дергается по расписанию или по событию и работает с данными базы напрямую, без внешнего API-раннера.
• REST API и официальный Python SDK (seatable-api) — удобно для интеграций и ботов.

Ключевое отличие от Baserow и NocoDB — лицензия. Baserow и NocoDB распространяются под AGPL, их серверный код полностью открыт. SeaTable в этом смысле честнее называть «доступным для self-hosted», а не «open source в классическом смысле»: серверная часть закрыта, community-редакция бесплатна для собственного использования, но часть функций (SSO/LDAP, кластеризация, приоритетная поддержка) продаётся отдельно в Enterprise-тарифе. Условия периодически меняются — перед разворачиванием на продакшен стоит свериться с актуальной лицензией на официальном сайте, а не полагаться на то, что написано в статьях годичной давности.

Официальный способ: install-скрипт, который сам собирает docker-compose.yml

Здесь SeaTable устроен иначе, чем Baserow или NocoDB, где вендор просто публикует готовый docker-compose.yml для копипаста. Официальная документация SeaTable (manual.seatable.io, раздел Server Installation) рекомендует интерактивный bash-скрипт, который сам задаёт вопросы — домен, e-mail администратора, пароль администратора, root-пароль MySQL, часовой пояс — и на основе ответов генерирует docker-compose.yml и сопутствующие конфиги в /opt/seatable-server.

Общий паттерн запуска такой (точную ссылку на актуальную версию скрипта берите из официального руководства — она меняется с выходом новых релизов SeaTable, и вставлять её сюда «на глаз» — плохая идея):

mkdir -p /opt/seatable-server && cd /opt/seatable-server
wget <ссылка-на-install-seatable.sh-из-документации>
chmod +x install-seatable.sh
sudo ./install-seatable.sh

Как и с любым установочным скриптом, который вы получаете через wget/curl и запускаете от root — откройте файл и прочитайте, что он делает, прежде чем выполнять. Это не специфика SeaTable, а общее правило гигиены для инсталляторов любого вендора.

Плюс подхода: скрипт сам выпускает сертификат, поднимает MySQL с нужными правами и меньше шансов ошибиться в переменных вручную. Минус: сложнее держать конфигурацию как код и версионировать в git — до первого запуска вы не увидите итоговый docker-compose.yml.

Ручной docker-compose.yml для тех, кто хочет обойтись без скрипта

Если вам ближе подход «пишу конфиг сам и храню в репозитории», вот файл, который воспроизводит структуру, которую генерирует официальный установщик: MySQL/MariaDB для реляционных данных, Memcached для сессий и кэша, и основной контейнер приложения.

version: "3.8"

services:
  db:
    image: mariadb:10.11
    container_name: seatable-db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "замените-на-длинный-пароль"
      MYSQL_LOG_CONSOLE: "true"
    volumes:
      - seatable_db:/var/lib/mysql
    command: --default-authentication-plugin=mysql_native_password

  memcached:
    image: memcached:1.6-alpine
    container_name: seatable-memcached
    restart: unless-stopped
    command: memcached -m 256

  seatable:
    image: seatable/seatable:latest
    container_name: seatable
    restart: unless-stopped
    depends_on:
      - db
      - memcached
    environment:
      DB_HOST: db
      DB_ROOT_PASSWD: "замените-на-длинный-пароль"
      TIME_ZONE: "Europe/Moscow"
      SEATABLE_SERVER_HOSTNAME: "seatable.example.com"
      SEATABLE_SERVER_PROTOCOL: "https"
      SEATABLE_ADMIN_EMAIL: "admin@example.com"
      SEATABLE_ADMIN_PASSWORD: "замените-на-длинный-пароль"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - seatable_shared:/shared

volumes:
  seatable_db:
  seatable_shared:

Важная оговорка: тег образа, точные имена переменных окружения и внутренние компоненты SeaTable меняются между релизами заметно чаще, чем у Baserow или NocoDB — этот файл описывает архитектуру, а не гарантированно рабочий конфиг под конкретную версию. Перед продакшен-запуском сверьте актуальный список переменных с официальной документацией и зафиксируйте тег образа конкретной версией вместо latest, чтобы docker compose pull не подсунул вам неожиданное мажорное обновление при пересоздании контейнера.

Переменные окружения, на которые стоит смотреть внимательнее всего

Секреты стоит выносить в отдельный .env рядом с docker-compose.yml, а не хранить прямо в файле — особенно если конфигурацию планируете держать в git.

HTTPS и reverse proxy

Официальный install-скрипт по умолчанию сам занимается выпуском сертификата на домен, который вы ему указали при установке — достаточно, чтобы A-запись домена смотрела на IP сервера и порты 80/443 были свободны.

Если на сервере уже работает Caddy как общий reverse proxy для нескольких сервисов, логичнее не отдавать SeaTable порты 80/443 напрямую, а завести его на внутренний порт и проксировать снаружи:

    ports:
      - "127.0.0.1:8090:80"

seatable.example.com {
    reverse_proxy 127.0.0.1:8090
}

Такая схема удобна, если вы уже держите на одном сервере несколько self-hosted инструментов — например, Baserow или NocoDB для одних команд и SeaTable для других — и не хотите выделять под каждый отдельный IP.

Бэкапы, обновление и перенос на другой сервер

Бэкапить нужно два независимых куска: базу MySQL (структура и метаданные таблиц) и volume /shared, где лежат реальные вложения и файлы DTable.

Дамп базы:

docker compose exec db mysqldump -u root -p seatable > seatable_$(date +%F).sql

Общий подход к автоматизации регулярных дампов MySQL из контейнера — в отдельной статье про бэкап MySQL на VPS, она применима и здесь, разница только в имени контейнера и базы.

С обновлением версии есть нюанс, унаследованный от Seafile: в отличие от Baserow, который прогоняет миграции автоматически при старте нового тега, у продуктов этого семейства при переходе через несколько версий подряд иногда требуется выполнить отдельный upgrade-шаг внутри контейнера, а не просто подменить образ. Перед мажорным обновлением обязательно прочитайте release notes конкретной версии в официальной документации и снимите свежий дамп — если апгрейд-скрипт упадёт на середине, откат к бэкапу будет быстрее, чем разбор частично мигрированной схемы.

Перенос на другой сервер — это перенос обоих volume (seatable_db и seatable_shared) и того же docker-compose.yml с обновлённым SEATABLE_SERVER_HOSTNAME, если домен меняется вместе с сервером.

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