Як самостійно розгорнути Baserow у 2026 році: дані, URL-адреси та резервні копії в одному рішенні

Контейнер Baserow може мати статус green, хоча основна операція, важлива для користувачів, не працює. Для Baserow прихована проблема зазвичай полягає в тому, що публічна URL-адреса змінюється після того, як користувачі вже створили посилання для спільного доступу та callback-посилання. У цьому посібнику приймемо як acceptance test таку послідовність: «створити базу даних і view, імпортувати CSV, редагувати рядки у двох сесіях і завантажити файл перед перезапуском all-in-one stack», — а розгортання будуватимемо від цього результату у зворотному напрямку.

Baserow має в стеку конкретну роль: бази даних у стилі Airtable, що працюють на основі Postgres і Redis. Тому production-питання полягає не в тому, чи відповідає порт 80 один раз, а в тому, чи продовжують стан, залежності та публічна адреса узгоджуватися після перезапуску, оновлення та відновлення.

Від чого залежить Baserow

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

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

Базова конфігурація Docker для Baserow

Наведена команда робить межі контейнера видимими, не створюючи вигляду, що вона налаштовує всі зовнішні сервіси.

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, перевірте resolved environment, mounts і listener. Підтвердьте локальну вимогу перед відкриттям доступу: достатній обсяг пам’яті для вбудованих Postgres, Redis, backend і workers. Успішний запуск вважається завершеним тоді, коли ви можете створити базу даних і view, імпортувати CSV, редагувати рядки у двох сесіях і завантажити файл перед перезапуском all-in-one stack, а не тоді, коли docker ps виводить Up.

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

Відкрийте для Baserow один HTTPS-хостнейм, а безпосередній доступ до порту 80 залиште приватним. Встановіть BASEROW_PUBLIC_URL точно відповідно до зовнішнього origin. Це не дасть браузерам та API-клієнтам дізнатися про дві конкуруючі адреси.

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

Резервне копіювання стану, який Baserow не може відтворити

Визначте recovery point і recovery time для Baserow з урахуванням усього дерева /baserow/data та періодичних логічних експортів бази даних. Підключіть /baserow/data до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести, що цей шлях справді має постійне зберігання. Іменований volume вирішує проблему збереження даних під час redeploy, але не захищає від компрометації чи втрати сервера.

Створіть чисте середовище для відновлення, використайте ту саму зафіксовану версію застосунку та переконайтеся, що таблиці, views, користувачі, automations і файли відновлюються з повної резервної копії /baserow/data. Задокументуйте команди, виправлення ownership і тривалість операції. Посібник із резервного копіювання пропонує корисний стандарт: резервна копія вважається надійною після відновлення, а не після завантаження.

Не надавайте Baserow доступ до всього хоста

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

Згенеруйте SECRET_KEY один раз, не зберігайте його в Git і включіть його до recovery manifest, оскільки зміна ключа може зробити недійсним зашифрований або підписаний стан застосунку. Не вирішуйте помилку permission запуском контейнера від імені root або широким монтуванням хоста. Обмеження ресурсів також є частиною security design, якщо користувачі можуть спричинити навантаження на вбудовані Postgres, Redis, Celery workers, кількість рядків, розмір імпорту та кількість одночасних редакторів.

Логи, які допомагають визначити наступне питання

Перевірка стану в режимі простою мало що говорить про Baserow. Відстежуйте вбудовані Postgres, Redis, Celery workers, кількість рядків, розмір імпорту та кількість одночасних редакторів, а сповіщення налаштовуйте на симптом, який бачать користувачі: помилку під час дії «створити базу даних і view, імпортувати CSV, редагувати рядки у двох сесіях і завантажити файл перед перезапуском all-in-one stack». Liveness має бути локальним і недорогим; readiness повинна повідомляти про migrations або initialization, не спричиняючи шторм перезапусків.

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

П’ять перевірок, які надійніші за стан контейнера

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

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

Додайте одну контрольовану помилку: надішліть нешкідливі дані близько до resource або format limit, пов’язаного з цією межею: публічна 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 і виконавши цю acceptance check: створити базу даних і view, імпортувати CSV, відредагувати рядки у двох сесіях і завантажити файл перед перезапуском all-in-one stack. Додайте результат відновлення до runbook до появи реальних користувачів.

Поширені запитання

Що потрібно Baserow для production deployment?

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

Які дані Baserow потрібно включити до резервної копії?

Забезпечте постійне зберігання /baserow/data і включіть усе дерево /baserow/data та періодичні логічні експорти бази даних до того самого recovery manifest. Чисте відновлення Baserow вважається успішним лише тоді, коли таблиці, views, користувачі, automations і файли повернулися з повної резервної копії /baserow/data.

Чи потрібен Baserow HTTPS за reverse proxy?

Використовуйте HTTPS для публічного origin Baserow, а порт 80 залиште у внутрішньому маршруті. Правильно застосуйте налаштування Baserow: встановіть BASEROW_PUBLIC_URL точно відповідно до зовнішнього origin. Для Baserow HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Baserow?

Відновіть поточний стан Baserow в ізольованому розгортанні, застосуйте candidate version і повторіть acceptance transaction. Приділіть особливу увагу тому, що all-in-one image одночасно переміщує кілька сервісів, тому міграції бази даних і застосунку потребують репетиції на основі snapshot. Зберігайте попередній Baserow image, доки не визначите межі міграції даних і rollback.