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

MAATRIX

Airtable удобен, пока не упираешься в лимит записей на бесплатном плане или не начинаешь считать, сколько стоит платная подписка для команды из десяти человек. Baserow решает ту же задачу — таблицы с формами, представлениями, API и связями между записями — но крутится на вашем сервере, без ограничений по числу строк и без ежемесячной платы за каждого пользователя. Ниже — рабочая установка на VPS через Docker, с доменом, SSL-сертификатом и настройкой под реальную нагрузку.

Что такое Baserow и когда он оправдан

Baserow — open-source no-code платформа для работы с базами данных в табличном виде: интерфейс как в Airtable или Google Таблицах, но под капотом обычная PostgreSQL. Есть представления (grid, kanban, calendar, gallery), формы для сбора данных, связи между таблицами, REST API и вебхуки из коробки.

Self-hosted вариант имеет смысл, если:

• команда работает с чувствительными данными и держать их у стороннего провайдера не хочется;
• число записей растёт быстрее, чем позволяет бесплатный тариф Airtable (обычно это происходит быстрее, чем кажется на старте);
• нужен полный доступ к API без квот запросов в минуту;
• хочется интегрировать Baserow с n8n или собственными скриптами без ограничений внешнего сервиса.

Минусы тоже есть: экосистема автоматизаций у Baserow скромнее, чем у Airtable, а часть продвинутых функций (SSO, аудит-лог, расширенные права) доступна только в платной Enterprise-версии, даже если вы её самостоятельно хостите. Для команды до 20-30 человек с типовыми задачами (CRM-таблицы, база контента, трекер задач) community-версии обычно достаточно.

Требования к серверу

Baserow состоит из нескольких контейнеров: backend (Django), worker для фоновых задач, web-frontend, PostgreSQL и Redis. Для комфортной работы небольшой команды хватает скромного VPS:

Если база разрастётся до сотен тысяч записей и десятков активных пользователей, стоит закладывать 4 vCPU и 8 ГБ RAM с запасом — PostgreSQL и worker Baserow при активной работе с формулами и представлениями заметно едят память.

Дальше исхожу из того, что у вас уже есть сервер с Ubuntu 24.04, вы зашли по SSH под пользователем с правами sudo, а домен (или хотя бы поддомен) указывает на IP сервера A-записью.

Установка Docker и подготовка окружения

Baserow официально распространяется как готовый Docker-образ, и это самый простой путь развёртывания — вручную собирать Django-приложение с нуля смысла нет.

Ставим Docker Engine и плагин Compose:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Создаём рабочую директорию и каталог для постоянных данных:

sudo mkdir -p /opt/baserow/data
sudo chown -R $USER:$USER /opt/baserow
cd /opt/baserow

В /opt/baserow/data Baserow будет хранить всё: PostgreSQL, загруженные файлы, Redis-данные. Это то, что попадёт в бэкап.

Docker Compose файл

Официальный образ baserow/baserow — это all-in-one контейнер, который внутри себя поднимает backend, frontend, worker, Postgres и Redis через supervisor. Это самый быстрый способ начать, но для продакшена лучше вынести Postgres в отдельный сервис — так проще делать бэкапы средствами самой БД и не зависеть от внутренней разметки контейнера.

Ниже — конфигурация с внешней PostgreSQL, которая ведёт себя предсказуемее на боевом сервере:

# docker-compose.yml
services:
  db:
    image: postgres:15-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: baserow
      POSTGRES_USER: baserow
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U baserow"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - ./data/redis:/data

  baserow:
    image: baserow/baserow:1.29
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    environment:
      BASEROW_PUBLIC_URL: "https://baserow.example.com"
      DATABASE_HOST: db
      DATABASE_NAME: baserow
      DATABASE_USER: baserow
      DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
      DATABASE_PORT: 5432
      REDIS_HOST: redis
      SECRET_KEY: ${SECRET_KEY}
      BASEROW_AMOUNT_OF_WORKERS: 2
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./data/media:/baserow/media

Обратите внимание: порт 8080 привязан к 127.0.0.1 — наружу контейнер не смотрит, весь внешний трафик пойдёт через Nginx, который поставим ниже.

Рядом создаём .env с секретами:

cat > .env <<'EOF'
POSTGRES_PASSWORD=замените_на_длинный_случайный_пароль
SECRET_KEY=замените_на_случайную_строку_50_символов
EOF
chmod 600 .env

Сгенерировать случайные значения проще всего так:

openssl rand -base64 32   # для POSTGRES_PASSWORD
openssl rand -base64 48   # для SECRET_KEY

Замените плейсхолдеры в .env реальными значениями и укажите свой домен в BASEROW_PUBLIC_URL — это важно, Baserow использует это значение для формирования ссылок в письмах и для загрузки файлов через API.

Поднимаем стек:

docker compose up -d
docker compose logs -f baserow

Первый запуск занимает пару минут — контейнер накатывает миграции базы. Дожидаемся строки о запуске сервера и Ctrl+C для выхода из логов (сам стек продолжит работать в фоне).

Домен, Nginx и SSL

Открывать Baserow напрямую по IP:8080 в 2026 году не стоит — без HTTPS браузеры блокируют часть функциональности (например, доступ к буферу обмена, который Baserow использует для копирования ячеек), да и передавать пароли по HTTP небезопасно.

Ставим Nginx и Certbot:

sudo apt install -y nginx certbot python3-certbot-nginx

Создаём конфиг сайта:

# /etc/nginx/sites-available/baserow
server {
    listen 80;
    server_name baserow.example.com;

    client_max_body_size 200M;

    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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

client_max_body_size 200M важен, если планируете загружать в таблицы файлы и вложения — по умолчанию Nginx режет тело запроса на 1 МБ. Заголовки Upgrade/Connection нужны для WebSocket-соединений — через них Baserow обновляет данные в реальном времени, когда над одной таблицей работают несколько человек.

sudo ln -s /etc/nginx/sites-available/baserow /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d baserow.example.com

Certbot сам пропишет редирект с HTTP на HTTPS и настроит автопродление сертификата. Если процесс выдачи сертификата упирается в ошибку валидации — обычно дело в DNS или файрволе, разбор типичных причин есть в статье про ошибки Let's Encrypt на сервере. Про выбор между Certbot и альтернативами — в материале Certbot или acme.sh.

Если ещё не настраивали DNS для домена с нуля, порядок действий описан в статье про настройку домена и DNS на Ubuntu — общие принципы там применимы и к другим дистрибутивам.

Первый вход и базовая настройка

Открываем https://baserow.example.com — должна открыться форма регистрации первого пользователя. Первый зарегистрированный аккаунт автоматически становится администратором инстанса.

После входа стоит сразу пройтись по базовым настройкам:

• Отключить публичную регистрацию. По умолчанию Baserow позволяет любому желающему зарегистрироваться на вашем инстансе — если это не открытая платформа, отключите это в переменной окружения:

    environment:
      BASEROW_DISABLE_PUBLIC_URL_CHECK: "false"
      DISABLE_ANONYMOUS_PUBLIC_VIEW_WS_CONNECTIONS: "true"

• Настроить SMTP для писем. Приглашения в воркспейс, сброс пароля и уведомления идут через почту — без SMTP они просто не уйдут:

    environment:
      EMAIL_SMTP: "true"
      EMAIL_SMTP_HOST: smtp.yourprovider.com
      EMAIL_SMTP_PORT: 587
      EMAIL_SMTP_USE_TLS: "true"
      EMAIL_SMTP_USER: user@example.com
      EMAIL_SMTP_PASSWORD: ${SMTP_PASSWORD}
      FROM_EMAIL: baserow@example.com

• Создать воркспейсы под команды. В Baserow данные организованы иерархией: воркспейс → база → таблица. Разумно сразу развести отделы или проекты по отдельным воркспейсам, а не сваливать всё в один — это упрощает управление правами доступа.

После изменения переменных окружения контейнер нужно пересоздать: docker compose up -d (Compose сам заметит изменения в .env/файле и пересоздаст только затронутый сервис).

Бэкапы, обновления и мониторинг

Все данные Baserow живут в PostgreSQL и в каталоге media (загруженные файлы, вложения к записям). Бэкапить нужно оба места.

Простой скрипт для дампа базы и архивации media:

#!/bin/bash
# /opt/baserow/backup.sh
set -e
BACKUP_DIR="/opt/baserow/backups"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"

docker compose -f /opt/baserow/docker-compose.yml exec -T db \
  pg_dump -U baserow baserow | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

tar -czf "$BACKUP_DIR/media_$DATE.tar.gz" -C /opt/baserow/data media

find "$BACKUP_DIR" -type f -mtime +14 -delete

Делаем исполняемым и ставим в cron на ежедневный запуск ночью:

chmod +x /opt/baserow/backup.sh
crontab -e
# добавить строку:
0 3 * * * /opt/baserow/backup.sh

Скрипт хранит бэкапы 14 дней локально — для надёжности стоит ещё выгружать архивы на отдельное хранилище (S3-совместимое или другой сервер), чтобы не потерять данные при аварии диска. Если нужна более серьёзная схема с версионированием и дедупликацией, посмотрите в сторону выделенного решения — например, установка BorgBackup на VPS.

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

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

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

За состоянием контейнеров удобно следить командой docker compose ps и docker stats — если worker или backend начинают упираться в память, это будет видно сразу, и тогда есть смысл поднять BASEROW_AMOUNT_OF_WORKERS или добавить серверу RAM.

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