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

MAATRIX

Airtable удобен, пока не упираешься в лимиты бесплатного тарифа или не начинаешь нервничать из-за того, что вся ваша база клиентов лежит на чужом сервере за океаном. Baserow решает обе проблемы: это open-source конструктор баз данных с собственным API, вебхуками и формами, который вы разворачиваете у себя и полностью контролируете. Ниже — рабочий docker-compose.yml, который можно скопировать и запустить за пять минут, плюс версия для прод-нагрузки с вынесенной базой и S3-хранилищем.

Что такое Baserow и зачем разворачивать его самому

Baserow — это таблично-реляционный конструктор: снаружи похож на Airtable или Google Таблицы, внутри — обычный PostgreSQL с прослойкой Django-приложения и REST/Webhook API. Из коробки есть представления (таблица, канбан, календарь, галерея), формы для сбора данных, права доступа на уровне таблиц и строк, автоматизации через вебхуки.

Разница с облачным Airtable принципиальная:

• Данные у вас. Никаких вопросов о том, где физически лежит база клиентов или прайс — она в вашем контейнере на вашем сервере.
• Нет лимитов по строкам и API-запросам — упираетесь только в ресурсы своего сервера.
• Своя аутентификация. Можно завести SSO, ограничить доступ по IP через reverse proxy, встроить в внутреннюю сеть без выхода в интернет вообще.
• API бесплатный и без троттлинга сверх того, что вы сами настроите на уровне nginx/Caddy.

Минус тоже есть: обновления, бэкапы и мониторинг теперь ваша забота, а не забота вендора. Docker Compose снимает большую часть боли с установкой и обновлением — дальше в статье решаем оставшуюся часть: бэкапы, HTTPS и вынос под нагрузку.

Готовый docker-compose.yml для быстрого старта

Для теста, внутреннего инструмента или команды до 15-20 человек достаточно официального all-in-one образа — в нём уже упакованы PostgreSQL, Redis, воркеры и встроенный Caddy для HTTPS. Это самый быстрый путь: один контейнер, один volume.

version: "3.8"

services:
  baserow:
    image: baserow/baserow:1.30.1
    container_name: baserow
    restart: unless-stopped
    environment:
      BASEROW_PUBLIC_URL: "https://baserow.example.com"
      BASEROW_CADDY_ADDRESSES: ":80,:443"
      SECRET_KEY: "замените-на-случайную-строку-минимум-32-символа"
      # Опционально: почта для восстановления пароля и приглашений
      EMAIL_SMTP: "true"
      EMAIL_SMTP_HOST: "smtp.example.com"
      EMAIL_SMTP_PORT: "587"
      EMAIL_SMTP_USER: "baserow@example.com"
      EMAIL_SMTP_PASSWORD: "замените"
      EMAIL_SMTP_USE_TLS: "true"
      FROM_EMAIL: "baserow@example.com"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - baserow_data:/baserow/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/_health/"]
      interval: 30s
      timeout: 10s
      retries: 5

volumes:
  baserow_data:

Важный нюанс: тег образа стоит зафиксировать конкретной версией, а не latest — на момент чтения актуальной может быть уже другая ветка 1.x, проверьте текущий тег на Docker Hub перед запуском, чтобы не поймать сюрприз при автоматическом пересоздании контейнера.

Поднимаем:

mkdir -p ~/baserow && cd ~/baserow
# вставляем docker-compose.yml из примера выше
docker compose up -d
docker compose logs -f baserow

Первый запуск занимает 1-3 минуты — инициализируется встроенная база и применяются миграции. После этого сервис отвечает на BASEROW_PUBLIC_URL, а первая зарегистрированная учётка автоматически становится администратором воркспейса.

Переменные окружения, которые нельзя оставлять по умолчанию

Три вещи обязательны к правке до запуска в продакшен:

Сгенерировать SECRET_KEY можно одной командой и сразу зафиксировать в .env, чтобы не потерять:

openssl rand -base64 32

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

HTTPS через встроенный Caddy или через ваш reverse proxy

Если Baserow — единственный сервис на сервере, встроенный в образ Caddy сам выпустит и обновит Let's Encrypt сертификат: достаточно, чтобы домен из BASEROW_PUBLIC_URL указывал А-записью на IP сервера, а порты 80/443 были свободны и проброшены наружу.

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

    environment:
      BASEROW_PUBLIC_URL: "https://baserow.example.com"
      DISABLE_VOLUME_CHECK: "true"
      BASEROW_CADDY_ADDRESSES: ""   # отключаем встроенный HTTPS
    ports:
      - "127.0.0.1:8080:80"          # слушаем только локально

А на внешнем Caddy добавляете блок:

baserow.example.com {
    reverse_proxy 127.0.0.1:8080
}

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

Прод-конфигурация: внешний PostgreSQL, Redis и S3 для файлов

All-in-one образ отлично подходит для старта, но у него есть узкое место: встроенные Postgres и Redis живут внутри того же контейнера, что и веб-приложение, а значит бэкап, апгрейд версии базы и масштабирование воркеров усложняются. Как только Baserow становится рабочим инструментом с реальными данными и десятками активных пользователей, имеет смысл вынести базу и файловое хранилище наружу — это тот же подход, что описан в общей статье про PostgreSQL на VPS.

version: "3.8"

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: baserow
      POSTGRES_USER: baserow
      POSTGRES_PASSWORD: "замените"
    volumes:
      - baserow_db:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --appendonly yes
    volumes:
      - baserow_redis:/data

  baserow:
    image: baserow/baserow:1.30.1
    restart: unless-stopped
    depends_on:
      - db
      - redis
    environment:
      BASEROW_PUBLIC_URL: "https://baserow.example.com"
      DATABASE_HOST: db
      DATABASE_NAME: baserow
      DATABASE_USER: baserow
      DATABASE_PASSWORD: "замените"
      DATABASE_PORT: "5432"
      REDIS_URL: "redis://redis:6379/0"
      SECRET_KEY: "замените"
      # Файлы и медиа — в S3-совместимое хранилище вместо локального диска
      AWS_ACCESS_KEY_ID: "ключ-minio"
      AWS_SECRET_ACCESS_KEY: "секрет-minio"
      AWS_STORAGE_BUCKET_NAME: "baserow-files"
      AWS_S3_ENDPOINT_URL: "https://s3.example.com"
      AWS_S3_REGION_NAME: "us-east-1"
    volumes:
      - baserow_data:/baserow/data
    ports:
      - "127.0.0.1:8080:80"

volumes:
  baserow_db:
  baserow_redis:
  baserow_data:

Если своего S3 ещё нет, поднять его на том же сервере или на соседнем можно за один compose-файл — см. MinIO в Docker Compose. Вынос файлов в объектное хранилище особенно важен, если пользователи активно прикладывают вложения к таблицам: локальный volume на диске сервера рано или поздно упрётся в место, а S3 масштабируется отдельно и его проще бэкапить инкрементально.

Бэкапы и обновление версии

Бэкапить нужно два независимых куска: базу данных (структура + содержимое таблиц) и файлы вложений (если храните локально, а не в S3).

Дамп PostgreSQL из контейнера:

docker compose exec db pg_dump -U baserow baserow | gzip > baserow_$(date +%F).sql.gz

Восстановление на чистую базу:

gunzip -c baserow_2026-08-20.sql.gz | docker compose exec -T db psql -U baserow baserow

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

Обновление версии — меняем тег образа и пересоздаём контейнер:

docker compose pull baserow
docker compose up -d baserow
docker compose logs -f baserow

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

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