Как разместить Baserow на собственном сервере в 2026 году: данные, URL и резервные копии в одном решении

Контейнер Baserow может быть в состоянии green, даже если основная задача пользователей не работает. В случае с Baserow скрытая проблема обычно заключается в том, что публичный URL меняется после того, как пользователи создали ссылки для общего доступа и callback-ссылки. В этом руководстве проверкой готовности считается следующий сценарий: «создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack». Развёртывание строится от этого результата в обратном направлении.

Baserow выполняет в стеке определённую роль: это базы данных в стиле Airtable на основе Postgres и Redis. Поэтому в production важно не то, отвечает ли порт 80 один раз, а то, продолжают ли состояние, зависимости и публичный адрес согласованно работать после перезапуска, обновления и восстановления.

От чего зависит Baserow

Состояние процесса и состояние продукта — разные вещи для Baserow. Порт 80 может отвечать, пока пользовательская операция завершается ошибкой. Для локального запуска требуется достаточно памяти для встроенных Postgres, Redis, backend и workers. Явно задайте жизненный цикл приложения, чтобы перенос Baserow между хостами не приводил к незаметному изменению поведения.

Выполняйте эту проверку готовности после существенных изменений конфигурации: создайте базу данных и представление, импортируйте CSV, отредактируйте строки из двух сессий и загрузите файл перед перезапуском all-in-one stack. Не включайте дорогостоящие внешние проверки в liveness probes, чтобы сбой у провайдера не вызывал цикл перезапусков. При оценке capacity учитывайте встроенные Postgres, Redis, Celery workers, количество строк, размер импорта и число одновременных редакторов — это точнее отражает реальную нагрузку Baserow, чем запросы к страницам.

Базовая конфигурация Baserow в Docker

Следующая команда делает границу контейнера явной, не пытаясь при этом настроить все внешние сервисы.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Перед открытием ingress проверьте итоговые значения окружения, mounts и listener. До публикации убедитесь, что локальное требование выполнено: достаточно памяти для встроенных Postgres, Redis, backend и workers. Успешный запуск считается завершённым, когда вы можете создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack, а не когда docker ps выводит Up.

Домены, proxy headers и порт 80

Опубликуйте для Baserow один HTTPS-хостнейм, а необработанный порт 80 оставьте закрытым извне. Установите BASEROW_PUBLIC_URL равным точному внешнему origin. Это не позволит браузерам и API-клиентам узнать о двух конкурирующих адресах.

Из чистого клиента выполните проверенную операцию и изучите первый запрос, завершившийся ошибкой. Если проблема связана с DNS или TLS, воспользуйтесь руководством по custom domain. Считайте ситуацию «публичный URL меняется после того, как пользователи создали ссылки для общего доступа и callback-ссылки» отдельной диагностикой приложения после подтверждения корректности маршрута.

Резервное копирование состояния, которое Baserow не может воссоздать

Определите recovery point и recovery time для Baserow с учётом всего дерева /baserow/data и периодических logical database exports. Подключите /baserow/data до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы доказать фактическую постоянность этого пути. Named volume решает задачу сохранения данных при redeploy, но не защищает от компрометации или потери сервера.

Подготовьте чистое окружение для восстановления, используйте ту же зафиксированную версию приложения и убедитесь, что таблицы, представления, пользователи, automations и файлы восстановлены из полной резервной копии /baserow/data. Зафиксируйте команды, исправления владельцев и затраченное время. Руководство по резервному копированию задаёт полезный стандарт: резервной копии доверяют после восстановления, а не после загрузки.

Не предоставляйте Baserow доступ ко всему хосту

Моделируйте угрозы с учётом действий Baserow, а не только его формы входа. В данном случае главная ошибка — использовать all-in-one image без плана резервного копирования встроенных сервисов. Установите следующие границы: при необходимости отключите регистрацию, сохраните SECRET_KEY и ограничьте публичные представления общего доступа только предназначенными для публикации данными.

Сгенерируйте SECRET_KEY один раз, храните его вне Git и сохраните вместе с recovery manifest, поскольку его изменение может сделать недействительным зашифрованное или подписанное состояние приложения. Не устраняйте ошибку прав, запуская контейнер от имени root или выполняя широкое монтирование хоста. Resource limits также относятся к security design, если пользователи могут создавать нагрузку на встроенные Postgres, Redis, Celery workers, количество строк, размер импорта и число одновременных редакторов.

Логи, которые помогают ответить на следующий вопрос

Idle health check мало что говорит о Baserow. Отслеживайте встроенные Postgres, Redis, Celery workers, количество строк, размер импорта и число одновременных редакторов, а затем настраивайте alerts по симптому, который видят пользователи: сбою операции «создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack». Liveness должна оставаться локальной и дешёвой; readiness может сообщать о migrations или initialization, но не должна вызывать restart storm.

Рискованная область обновления заключается в том, что all-in-one image одновременно перемещает несколько сервисов, поэтому migrations базы данных и приложения требуют репетиции на основе snapshot. Прочитайте release notes, создайте snapshot состояния, разверните целевую версию на восстановленной копии и повторите acceptance action. Если публичный URL меняется после того, как пользователи создали ссылки для общего доступа и callback-ссылки, сопоставьте клиентский запрос с первой относящейся к нему записью в логе приложения, а не удаляйте состояние и не добавляйте redirects вслепую.

Пять проверок, которые надёжнее health контейнера

До появления реальных пользователей подготовьте для Baserow release worksheet. В нём должны быть указаны pinned image, порт 80, canonical origin, persistent paths и ответственный за достаточный объём памяти для встроенных Postgres, Redis, backend и workers. Добавьте ожидаемый результат этой операции: создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack.

Используйте worksheet после обычной замены контейнера и после чистого восстановления. Восстановление считается успешным только в том случае, если таблицы, представления, пользователи, automations и файлы возвращены из полной резервной копии /baserow/data. Также соберите короткую resource trace, охватывающую встроенные Postgres, Redis, Celery workers, количество строк, размер импорта и число одновременных редакторов; храните её рядом с release, чтобы будущие изменения capacity сравнивались с той же нагрузкой.

Добавьте один контролируемый сбой: отправьте безвредные данные около ограничения ресурса или формата, связанного с этой границей: публичный URL меняется после того, как пользователи создали ссылки для общего доступа и callback-ссылки. Убедитесь, что Baserow сообщает о проблеме на правильной границе, верните корректное условие и повторно выполните операцию. Это проверяет видимость ошибок, а не только успешный сценарий, и не позволяет внешне работоспособному интерфейсу скрыть неисправный worker, callback или подключение к базе данных.

Подключите Baserow к жизненному циклу Dockup

One-click deployment Baserow в Dockup должен делать замену безопасной: маршрут продолжает указывать на 80, секреты не встраиваются в image, а persistent paths восстанавливаются в новом контейнере. То же развёртывание может работать на compute Dockup или на подключённой машине.

Завершите настройку приложения, подтвердив локальное требование — достаточно памяти для встроенных Postgres, Redis, backend и workers, задав canonical public address и выполнив эту проверку готовности: создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack. Добавьте результат восстановления в runbook до появления реальных пользователей.

Часто задаваемые вопросы

Что нужно Baserow для production deployment?

Направьте контейнер Baserow через порт 80 к одному HTTPS origin. Для локального запуска требуется достаточно памяти для встроенных Postgres, Redis, backend и workers. Не объявляйте Baserow готовым, пока не сможете создать базу данных и представление, импортировать CSV, отредактировать строки из двух сессий и загрузить файл перед перезапуском all-in-one stack.

Какие данные Baserow должны входить в резервную копию?

Сохраняйте /baserow/data и включайте всё дерево /baserow/data вместе с периодическими logical database exports в один recovery manifest. Чистое восстановление Baserow считается успешным только тогда, когда таблицы, представления, пользователи, automations и файлы возвращены из полной резервной копии /baserow/data.

Требуется ли Baserow HTTPS за reverse proxy?

Используйте HTTPS для публичного origin Baserow, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку Baserow: установите BASEROW_PUBLIC_URL равным точному внешнему origin. Для Baserow HTTPS защищает credentials и пользовательский контент при передаче и обеспечивает согласованное поведение клиента, зависящее от origin.

Как тестировать обновление Baserow?

Восстановите текущее состояние Baserow в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание, поскольку all-in-one image одновременно перемещает несколько сервисов, а значит, migrations базы данных и приложения требуют репетиции на основе snapshot. Не удаляйте предыдущий image Baserow, пока не будут понятны границы миграции данных и rollback.