Розгортання Baserow на

Що ми налаштовуємо і навіщо

У цьому посібнику ми зосередимося на розгортанні Baserow — потужної та гнучкої open-source платформи для створення no-code баз даних. Baserow дозволяє користувачам створювати та керувати реляційними базами даних без написання жодного рядка коду, пропонуючи інтуїтивно зрозумілий інтерфейс, що нагадує електронні таблиці, але з функціональністю повноцінної бази даних. Це ідеальне рішення для команд, яким потрібно швидко структурувати дані, автоматизувати робочі процеси та створювати прості програми.

У підсумку ви отримаєте повністю функціонуючий екземпляр Baserow, доступний за власним доменним ім'ям із захищеним HTTPS-з'єднанням. Ви зможете створювати бази даних, таблиці, налаштовувати поля, подання, формули та API-інтерфейси, надаючи доступ своїй команді або клієнтам. Усі дані зберігатимуться на вашому власному сервері, забезпечуючи максимальний контроль та конфіденційність.

Альтернативи: Cloud-managed vs. Self-hosted

На ринку існує безліч no-code баз даних, таких як Airtable, NocoDB, SeaTable та Google Sheets з розширеннями. Вони поділяються на дві основні категорії:

• Cloud-managed рішення: Це SaaS-платформи, де провайдер керує всією інфраструктурою. Вони зручні, не вимагають технічних знань для розгортання, але ви залежите від провайдера в питаннях безпеки, масштабування, ціноутворення та володіння даними. Приклади включають Airtable, Smartsheet.
• Self-hosted рішення: Такі як Baserow, дозволяють вам встановити програмне забезпечення на ваш власний сервер (VPS або dedicated). Це дає повний контроль над даними, безпекою, продуктивністю та кастомізацією. Ви не прив'язані до цінової політики одного провайдера і можете адаптувати систему під свої потреби.

Ми обираємо self-hosted Baserow на VPS з кількох причин:

• Повний контроль над даними: Ваші дані залишаються на вашому сервері, що критично важливо для конфіденційних проєктів, відповідності GDPR та інших регуляцій.
• Економічна ефективність: При помірному використанні та правильному налаштуванні, утримання VPS часто обходиться дешевше, ніж підписки на cloud-managed сервіси, особливо в міру зростання команди або обсягу даних.
• Гнучкість та кастомізація: Можливість тонкого налаштування сервера та самого Baserow під специфічні вимоги, інтеграція з іншими self-hosted сервісами.
• Незалежність: Ви не залежите від змін у політиці, цінах або функціоналі стороннього провайдера.

Який VPS-конфіг потрібен для цього завдання

Вимоги до VPS для Baserow можуть сильно відрізнятися залежно від кількості користувачів, обсягу даних, складності баз та інтенсивності використання API. Однак для початкового розгортання та невеликих команд (до 5-10 активних користувачів) можна орієнтуватися на наступні мінімальні та рекомендовані характеристики.

Мінімальні вимоги (для тестування або дуже невеликих команд)

• CPU: 1-2 ядра (Intel Xeon E3/E5 або AMD EPYC). Baserow — це Python-додаток, який може бути досить вимогливим до CPU при складних запитах.
• RAM: 2 ГБ. Baserow, PostgreSQL та Redis разом можуть споживати значний обсяг ОЗП. 2 ГБ — це абсолютний мінімум, при якому система може працювати повільно або стикатися з нестачею пам'яті при пікових навантаженнях.
• Диск: 40 ГБ SSD. SSD критично важливий для продуктивності бази даних. 40 ГБ вистачить для операційної системи, Docker-образів та невеликого обсягу даних.
• Мережа: 100 Мбіт/с. Для більшості завдань цього достатньо.

Рекомендований VPS-план для невеликих та середніх команд (до 20-30 активних користувачів)

Для комфортної роботи та можливості зростання рекомендуються наступні характеристики:

• CPU: 2-4 ядра (сучасний Intel Xeon або AMD EPYC).
• RAM: 4-8 ГБ. Це забезпечить стабільну роботу Baserow, PostgreSQL, Redis та операційної системи навіть при активному використанні.
• Диск: 80-160 ГБ SSD. Це дасть достатньо місця для ОС, усіх компонентів Baserow, значного обсягу даних та резервних копій.
• Мережа: 1 Гбіт/с. Висока пропускна здатність забезпечить швидке завантаження даних та чуйність інтерфейсу.

Ви можете знайти VPS із зазначеними характеристиками, щоб орендувати сервер, який відповідає цим вимогам.

Коли потрібен Dedicated Server, а не VPS

Dedicated server (виділений сервер) стає необхідним, коли:

• Дуже високе навантаження: Тисячі активних користувачів, величезні обсяги даних (терабайти) або дуже інтенсивні операції з базою даних.
• Суворі вимоги до продуктивності: Потрібна максимальна та передбачувана продуктивність без "сусідства" з іншими клієнтами на одному фізичному сервері.
• Специфічні апаратні вимоги: Потрібні особливі конфігурації RAID, спеціалізовані GPU або інші апаратні компоненти, недоступні на VPS.
• Відповідність регуляторним вимогам: Деякі галузі вимагають повного фізичного розділення та контролю над обладнанням.

Для більшості завдань Baserow на початкових та середніх етапах VPS буде більш ніж достатньо та економічно вигідніше.

Локація: на що впливає

Вибір локації VPS важливий з кількох причин:

• Затримка (Latency): Чим ближче сервер до вашої цільової аудиторії або до вас, тим нижча затримка та швидша відповідь. Якщо ваша команда знаходиться в Європі, вибирайте європейський дата-центр.
• Законодавство про дані: Різні країни мають різні закони про конфіденційність даних (наприклад, GDPR в ЄС). Вибір локації може вплинути на юридичні аспекти зберігання та обробки інформації.
• Доступність мережі: Деякі регіони можуть мати кращу зв'язність з певними частинами світу.

Завжди вибирайте локацію, яка географічно ближче до основних користувачів вашого Baserow-інстансу.

Підготовка сервера

Після отримання доступу до вашого нового VPS з операційною системою Ubuntu Server 24.04 LTS, насамперед необхідно виконати низку базових налаштувань для підвищення безпеки та зручності керування. Усі команди виконуються від імені користувача root або з використанням sudo.

1. Підключення до сервера по SSH

Використовуйте ваш SSH-клієнт для підключення:

ssh root@ВАШ_IP_АДРЕС_VPS

Введіть пароль, який був наданий вашим провайдером.

2. Оновлення системи

Переконайтеся, що всі пакети на сервері оновлені до останніх версій:

sudo apt update         # Оновлення списку пакетів
sudo apt upgrade -y     # Оновлення встановлених пакетів без запиту підтвердження
sudo apt autoremove -y  # Видалення непотрібних залежностей

3. Створення нового користувача з правами sudo

Працювати під root небезпечно. Створимо нового користувача та надамо йому права sudo:

sudo adduser baserow_admin      # Створення нового користувача
sudo usermod -aG sudo baserow_admin # Додавання користувача до групи sudo

Дотримуйтесь інструкцій для встановлення пароля та інформації про користувача. Після цього вийдіть із сесії root та увійдіть як baserow_admin:

exit
ssh baserow_admin@ВАШ_IP_АДРЕС_VPS

4. Налаштування SSH-ключів (рекомендується)

Для підвищення безпеки та зручності налаштуйте автентифікацію за SSH-ключами. Якщо у вас немає SSH-ключа, згенеруйте його на вашій локальній машині:

ssh-keygen -t rsa -b 4096 # На вашій локальній машині

Потім скопіюйте публічний ключ на сервер:

ssh-copy-id baserow_admin@ВАШ_IP_АДРЕС_VPS # На вашій локальній машині

Після того, як ви переконалися, що можете увійти за ключем, вимкніть автентифікацію за паролем для root та нового користувача у файлі /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Знайдіть та змініть/додайте наступні рядки:

# Вимкнути вхід для root за паролем (якщо увімкнено)
PermitRootLogin prohibit-password

# Вимкнути вхід за паролем для всіх користувачів (після налаштування SSH-ключів)
PasswordAuthentication no

Перезапустіть SSH-сервіс:

sudo systemctl restart sshd

5. Налаштування Firewall (UFW)

Увімкніть базовий файрвол UFW для захисту сервера. Дозвольте лише необхідні порти:

sudo ufw allow OpenSSH       # Дозволити SSH (порт 22)
sudo ufw allow http          # Дозволити HTTP (порт 80)
sudo ufw allow https         # Дозволити HTTPS (порт 443)
sudo ufw enable              # Увімкнути UFW
sudo ufw status verbose      # Перевірити статус файрвола

Підтвердьте увімкнення файрвола, натиснувши y.

6. Встановлення Fail2Ban

Fail2Ban захищає від атак методом підбору паролів, блокуючи IP-адреси, з яких відбуваються численні невдалі спроби входу:

sudo apt install fail2ban -y    # Встановлення Fail2Ban
sudo systemctl enable fail2ban  # Увімкнення автозапуску
sudo systemctl start fail2ban   # Запуск сервісу

Для базового налаштування можна створити файл /etc/fail2ban/jail.local:

sudo nano /etc/fail2ban/jail.local

І додайте наступний вміст:

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5
banaction = ufw

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Перезапустіть Fail2Ban для застосування змін:

sudo systemctl restart fail2ban

Тепер ваш сервер має базовий захист і готовий до встановлення Baserow.

Встановлення ПЗ — покроково

Baserow буде розгорнуто з використанням Docker та Docker Compose, що є рекомендованим підходом для більшості self-hosted застосунків. Це забезпечує ізоляцію, простоту керування залежностями та легке масштабування.

1. Встановлення Docker Engine

Спочатку встановимо Docker. Ці команди актуальні для Ubuntu 24.04 LTS та забезпечують встановлення останньої стабільної версії Docker CE (припускаємо Docker Engine 25.x або новіше до 2026 року).

# Видалення старих версій Docker (якщо є)
for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; do sudo apt remove $pkg -y; done

# Встановлення необхідних пакетів для роботи з репозиторіями
sudo apt update
sudo apt install ca-certificates curl gnupg -y

# Додавання офіційного GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Додавання репозиторію Docker до Apt
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Оновлення списку пакетів з урахуванням нового репозиторію
sudo apt update

# Встановлення Docker Engine, Docker CLI та Containerd
sudo apt install docker-ce docker-ce-cli containerd.io -y

Після встановлення додайте вашого користувача до групи docker, щоб запускати команди Docker без sudo (потрібне перезавантаження або повторний вхід):

sudo usermod -aG docker baserow_admin # Додавання користувача до групи docker
newgrp docker                          # Застосування змін без перезавантаження

Перевірте, що Docker встановлено коректно:

docker run hello-world # Запуск тестового контейнера

2. Встановлення Docker Compose

Docker Compose зазвичай встановлюється як плагін до Docker (версія 2.x). До 2026 року він буде інтегрований у Docker CLI.

sudo apt install docker-compose-plugin -y # Встановлення Docker Compose як плагіна

Перевірте версію Docker Compose:

docker compose version # Перевірка версії Docker Compose

3. Завантаження конфігурації Baserow Docker Compose

Baserow надає офіційні конфігураційні файли для Docker Compose. Створимо директорію для Baserow та завантажимо їх туди.

mkdir baserow && cd baserow # Створення директорії та перехід до неї
wget https://gitlab.com/baserow/baserow/-/raw/develop/deploy/docker-compose.yml # Завантаження docker-compose.yml (актуально для Baserow 1.25.x)
wget https://gitlab.com/baserow/baserow/-/raw/develop/deploy/.env # Завантаження файлу .env

Переконайтеся, що ви завантажуєте актуальні файли з офіційного репозиторію Baserow. Версія develop часто відображає останні стабільні зміни, але для продакшену можна використовувати посилання на конкретні релізи.

4. Налаштування файлу .env

Файл .env містить змінні оточення для конфігурації Baserow, включаючи секрети та налаштування домену. Відкрийте його для редагування:

nano .env # Редагування файлу змінних оточення

Вам потрібно буде змінити наступні параметри (приклади):

• BASEROW_PUBLIC_URL: Це має бути ваш домен, через який буде доступний Baserow (наприклад, https://baserow.yourdomain.com).
• DATABASE_PASSWORD: Згенеруйте складний пароль для бази даних PostgreSQL.
• SECRET_KEY: Згенеруйте складний секретний ключ.

Приклад змін у .env:

# ... інші змінні ...

BASEROW_PUBLIC_URL=https://baserow.yourdomain.com

# Налаштування бази даних PostgreSQL
# ...
DATABASE_PASSWORD=YOUR_STRONG_DATABASE_PASSWORD_HERE
# ...

# Секретний ключ Baserow
SECRET_KEY=YOUR_VERY_LONG_AND_COMPLEX_SECRET_KEY_HERE

# ...

Ви можете згенерувати надійні паролі та секретні ключі, наприклад, за допомогою openssl rand -hex 32 або онлайн-генераторів.

5. Запуск Baserow

Після налаштування файлу .env ви можете запустити Baserow. Docker Compose автоматично завантажить необхідні образи та запустить усі сервіси.

docker compose up -d # Запуск усіх сервісів Baserow у фоновому режимі

Ця команда завантажить Docker-образи (PostgreSQL, Redis, Baserow Web, Baserow Backend, Caddy), створить контейнери та запустить їх. Процес може зайняти кілька хвилин залежно від швидкості вашого інтернет-з'єднання.

6. Перевірка статусу контейнерів

Переконайтеся, що всі контейнери запущені та працюють коректно:

docker compose ps # Перевірка статусу запущених контейнерів

Ви повинні побачити статус Up для всіх сервісів (baserow_backend, baserow_web, caddy, database, redis).

Також можна переглянути логи конкретного сервісу, наприклад, бекенду:

docker compose logs baserow_backend # Перегляд логів бекенду Baserow

На цьому етапі Baserow запущено, але поки що доступний лише за IP-адресою сервера і, можливо, без HTTPS. Наступний крок — налаштування безпечного доступу через домен.

Конфігурація

Після успішного запуску Baserow з Docker Compose необхідно виконати фінальну конфігурацію для забезпечення безпечного та зручного доступу. Це включає налаштування доменного імені, HTTPS та додаткові параметри.

1. Налаштування DNS

Для доступу до Baserow за доменним ім'ям (наприклад, baserow.yourdomain.com) вам необхідно створити A-запис у вашого реєстратора доменних імен. Вкажіть ваш домен (або субдомен) та IP-адресу вашого VPS.

# Приклад запису у вашого реєстратора домену
Type: A
Host: baserow
Value: ВАШ_IP_АДРЕС_VPS

Дочекайтеся оновлення DNS-записів (може зайняти від кількох хвилин до кількох годин).

2. Конфігурація Caddy для HTTPS

Baserow Docker Compose за замовчуванням включає сервіс Caddy, який виступає в ролі зворотного проксі та автоматично керує сертифікатами Let's Encrypt для HTTPS. Налаштування виконується через файл Caddyfile.

За замовчуванням, файл Caddyfile вже налаштований у директорії baserow/caddy. Переконайтеся, що у вашому docker-compose.yml файл Caddyfile монтується в контейнер Caddy:

# Вміст docker-compose.yml (фрагмент для Caddy)
# ...
  caddy:
    image: caddy:2.7.6-alpine # Актуальна версія Caddy на 2026 рік
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - baserow_caddy_data:/data
      - baserow_caddy_config:/config
    depends_on:
      - baserow_web
# ...

Створіть директорію caddy та файл Caddyfile всередині неї, якщо їх немає:

mkdir caddy
nano caddy/Caddyfile

Додайте або переконайтеся, що в caddy/Caddyfile міститься наступне (замініть baserow.yourdomain.com на ваш домен):

{
  # Замініть на ваш email для сповіщень Let's Encrypt
  email [email protected]
}

baserow.yourdomain.com {
  reverse_proxy baserow_web:80
}

Після редагування файлу Caddyfile, якщо ви його змінили, необхідно перезапустити лише сервіс Caddy:

docker compose restart caddy # Перезапуск контейнера Caddy

Caddy автоматично виявить новий домен, запитає сертифікат Let's Encrypt та налаштує HTTPS. Якщо у вас виникнуть проблеми, перевірте логи Caddy:

docker compose logs caddy # Перегляд логів Caddy

3. Перевірка працездатності

Після налаштування DNS та Caddy перевірте доступність Baserow:

• Доступність сайту: Відкрийте ваш домен (https://baserow.yourdomain.com) у браузері. Ви повинні побачити сторінку реєстрації/входу Baserow.
• Перевірка HTTPS: Переконайтеся, що з'єднання захищено (зелений замочок в адресному рядку).
• Пінг домену: Перевірте, що домен резолвиться у правильну IP-адресу.

ping baserow.yourdomain.com

• Healthcheck контейнерів: Переконайтеся, що всі Docker-контейнери працюють без помилок.

docker compose ps
docker compose logs

Якщо Baserow завантажується, ви можете зареєструвати першого користувача (адміністратора) та розпочати роботу з платформою.

4. Додаткові налаштування в .env (за необхідності)

У файлі .env є безліч інших налаштувань, які можуть бути корисними надалі:

• BASEROW_EMAIL_SMTP_HOST, BASEROW_EMAIL_SMTP_PORT тощо: Налаштування SMTP-сервера для надсилання електронної пошти (сповіщення, скидання пароля).
• BASEROW_PUBLIC_BACKEND_URL: Якщо ви використовуєте окремий бекенд, відмінний від основного домену.
• MEDIA_ROOT: Шлях для зберігання файлів користувача. За замовчуванням це том Docker.

Завжди звертайтеся до офіційної документації Baserow для отримання повного списку та опису всіх змінних оточення.

Важливо: Ніколи не зберігайте конфіденційні дані (паролі, ключі API) безпосередньо в коді або в публічно доступних файлах. Файл .env має бути захищений і не повинен потрапляти до систем контролю версій.

Резервне копіювання та обслуговування

Регулярне резервне копіювання та своєчасне обслуговування є критично важливими для будь-якої продакшн-системи. Це гарантує збереження ваших даних та стабільність роботи Baserow.

1. Що резервувати

Для Baserow необхідно резервувати наступні компоненти:

• База даних PostgreSQL: Містить усі структуровані дані, створені в Baserow. Це найважливіший компонент.
• Користувацькі файли (медіа): Усі файли, завантажені користувачами в Baserow (зображення, документи тощо). Вони зберігаються в томі Docker, пов'язаному з сервісом baserow_backend.
• Файли конфігурації: docker-compose.yml та .env. Вони містять налаштування розгортання та секретні ключі, необхідні для відновлення системи.

2. Простий скрипт авторезервного копіювання

Створимо простий скрипт для автоматичного резервного копіювання. Цей скрипт буде дампити базу даних, архівувати медіафайли та зберігати конфігураційні файли. Передбачається, що ви знаходитесь в директорії ~/baserow.

mkdir -p ~/baserow_backups # Створення директорії для резервних копій
nano ~/baserow_backups/backup_baserow.sh

Додайте наступний вміст до файлу backup_baserow.sh. Замініть YOUR_DB_USER та YOUR_DB_PASSWORD на значення з вашого файлу .env:

#!/bin/bash

# Налаштування
BACKUP_DIR="/home/baserow_admin/baserow_backups" # Директорія для зберігання резервних копій
BASEROW_DIR="/home/baserow_admin/baserow"       # Директорія, де знаходиться docker-compose.yml
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Змінні з .env (потрібні для pg_dump)
# Можна прочитати з .env або встановити вручну
# Приклад читання з .env (потребує jq, який можна встановити: sudo apt install jq -y)
# source "$BASEROW_DIR/.env" # Якщо .env простий, без спеціальних символів

# Або задати вручну, якщо в .env складні символи або не хочеться парсити
DB_NAME="baserow"
DB_USER="baserow"
DB_PASSWORD="YOUR_STRONG_DATABASE_PASSWORD_HERE" # Замініть на реальний пароль з .env

# 1. Резервне копіювання бази даних PostgreSQL
echo "Дампування бази даних PostgreSQL..."
docker compose -f "$BASEROW_DIR/docker-compose.yml" exec -T database pg_dump -U "$DB_USER" -d "$DB_NAME" > "$BACKUP_DIR/baserow_db_${TIMESTAMP}.sql"
if [ $? -eq 0 ]; then
    echo "Дамп бази даних успішний: $BACKUP_DIR/baserow_db_${TIMESTAMP}.sql"
else
    echo "Дамп бази даних НЕВДАЛИЙ!"
    exit 1
fi

# 2. Резервне копіювання медіафайлів (Docker volume)
echo "Архівування медіафайлів Baserow..."
# Отримуємо ім'я тому для медіафайлів
MEDIA_VOLUME=$(docker volume ls -q | grep baserow_data) # Передбачається, що ім'я тому містить 'baserow_data'
if [ -z "$MEDIA_VOLUME" ]; then
    echo "Не вдалося знайти том медіафайлів Baserow. Пропускаємо резервне копіювання медіа."
else
    # Створюємо тимчасовий контейнер для копіювання даних
    docker run --rm -v "$MEDIA_VOLUME":/data -v "$BACKUP_DIR":/backup_dest alpine tar -czvf "/backup_dest/baserow_media_${TIMESTAMP}.tar.gz" -C /data .
    if [ $? -eq 0 ]; then
        echo "Архівування медіафайлів успішне: $BACKUP_DIR/baserow_media_${TIMESTAMP}.tar.gz"
    else
        echo "Архівування медіафайлів НЕВДАЛЕ!"
    fi
fi

# 3. Копіювання конфігураційних файлів
echo "Копіювання конфігураційних файлів..."
cp "$BASEROW_DIR/docker-compose.yml" "$BACKUP_DIR/docker-compose_${TIMESTAMP}.yml"
cp "$BASEROW_DIR/.env" "$BACKUP_DIR/.env_${TIMESTAMP}"
echo "Конфігураційні файли скопійовано."

# Видалення старих резервних копій (наприклад, старших за 7 днів)
echo "Видалення старих резервних копій..."
find "$BACKUP_DIR" -type f -name "baserow_db_*.sql" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "baserow_media_*.tar.gz" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "docker-compose_*.yml" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name ".env_*" -mtime +7 -delete
echo "Старі резервні копії видалено."

echo "Резервне копіювання Baserow завершено о $TIMESTAMP"

Зробіть скрипт виконуваним:

chmod +x ~/baserow_backups/backup_baserow.sh # Робимо скрипт виконуваним

3. Планування резервного копіювання за допомогою Cron

Додайте скрипт до Cron для щоденного виконання (наприклад, о 3:00 ночі):

crontab -e # Відкриття crontab для редагування

Додайте наступний рядок в кінець файлу (виберіть редактор nano, якщо запитає):

0 3 * * * /home/baserow_admin/baserow_backups/backup_baserow.sh >> /var/log/baserow_backup.log 2>&1

Цей рядок означає: о 3:00 ночі щодня запускати скрипт, а весь вивід перенаправляти у файл логів /var/log/baserow_backup.log.

4. Куди зберігати резервні копії

Зберігати резервні копії на тому ж сервері, що й продакшн-дані, вкрай ризиковано. Якщо сервер вийде з ладу, ви втратите і дані, і резервні копії. Рекомендується використовувати:

• Зовнішнє S3-сумісне сховище: Такі сервіси, як AWS S3, Backblaze B2, DigitalOcean Spaces. Можна використовувати утиліти на кшталт rclone або s3cmd для автоматичної синхронізації локальних резервних копій з S3.
• Окремий VPS: Недорогий VPS в іншій локації, куди можна копіювати резервні копії по SSH за допомогою rsync.
• Мережеве сховище (NAS): Якщо у вас є власна інфраструктура.

Розширте скрипт резервного копіювання, додавши крок для копіювання файлів на віддалене сховище.

5. Оновлення: Rolling vs. Maintenance Window

Регулярні оновлення Baserow та базового ПЗ важливі для безпеки та отримання нових функцій.

• Оновлення Baserow:

  Для оновлення Baserow до нової версії (наприклад, з 1.24.x до 1.25.x), виконайте наступні кроки:

  1. Зробіть повне резервне копіювання! Це найважливіший крок перед будь-яким оновленням.
  2. Зупиніть Baserow:

     
     cd ~/baserow
     docker compose down
                         

  3. Завантажте нові версії файлів docker-compose.yml та .env (або порівняйте та оновіть поточні):

     
     wget -O docker-compose.yml https://gitlab.com/baserow/baserow/-/raw/develop/deploy/docker-compose.yml
     # Перевірте .env на нові змінні, якщо вони з'явилися в новій версії Baserow
                         

  4. Запустіть Baserow з оновленими образами:

     
     docker compose pull # Завантаження нових образів
     docker compose up -d # Запуск з новими образами та міграцією БД, якщо потрібно
                         

  5. Перевірте логи та працездатність.

  Це потребуватиме короткого maintenance window (зупинки сервісу), оскільки база даних може вимагати міграції. Завжди читайте офіційну документацію щодо оновлення Baserow для конкретної версії.

• Оновлення ОС та Docker:

  Регулярно оновлюйте операційну систему та Docker Engine:

  
  sudo apt update && sudo apt upgrade -y
  sudo systemctl reboot # Перезавантаження для застосування оновлень ядра
              

  Оновлення Docker також можуть вимагати перезапуску контейнерів або навіть всього сервера. Плануйте ці операції в періоди низької активності.

Troubleshooting + FAQ

Навіть при найретельнішому підході можуть виникнути проблеми. Тут ми розглянемо типові сценарії та питання.

Контейнер Baserow не запускається або постійно перезапускається. Що робити?

Що перевірити: Перш за все, подивіться логи проблемного контейнера. Наприклад, для бекенду: docker compose logs baserow_backend. Зверніть увагу на повідомлення про помилки. Часті причини: нестача пам'яті, неправильні змінні оточення в .env (особливо DATABASE_URL, SECRET_KEY, BASEROW_PUBLIC_URL), конфлікти портів, пошкоджені Docker-образи або томи.

Як виправити: Переконайтеся, що VPS має достатньо RAM. Перевірте синтаксис та значення в .env. Якщо є підозра на пошкодження томів, спробуйте зупинити Baserow (docker compose down) і, як крайній захід, видалити томи (docker volume rm baserow_data baserow_caddy_data baserow_caddy_config), а потім запустити заново (втрачаючи дані, якщо вони не зарезервовані!). Іноді допомагає повне перестворення образів: docker compose build --no-cache && docker compose up -d.

Не можу отримати доступ до Baserow за доменним ім'ям, або HTTPS не працює.

Що перевірити: Переконайтеся, що DNS-запис для вашого домену (наприклад, baserow.yourdomain.com) вказує на правильну IP-адресу вашого VPS. Використовуйте ping ваш.домен або dig ваш.домен. Перевірте, що порти 80 і 443 відкриті на вашому VPS (sudo ufw status). Подивіться логи Caddy: docker compose logs caddy на предмет помилок при отриманні сертифіката Let's Encrypt. Переконайтеся, що BASEROW_PUBLIC_URL в .env та домен у caddy/Caddyfile збігаються.

Як виправити: Виправте DNS-запис. Відкрийте порти 80 і 443 в UFW. Якщо Caddy не може отримати сертифікат, можливо, є проблема з DNS-роздільною здатністю, або домен не вказує на ваш сервер. Переконайтеся, що email у Caddyfile коректний.

Baserow працює дуже повільно.

Що перевірити: Використовуйте htop або top на VPS, щоб перевірити завантаження CPU та використання RAM. Повільність часто пов'язана з нестачею ресурсів. Також перевірте логи Baserow на наявність повторюваних помилок, які можуть уповільнювати роботу.

Як виправити: Якщо не вистачає RAM, розгляньте можливість збільшення обсягу пам'яті VPS. Якщо CPU постійно завантажений, можливо, потрібно більше ядер. Оптимізуйте запити в Baserow, уникайте дуже великих таблиць з безліччю зв'язків та складних формул, якщо продуктивність критична. Переконайтеся, що дискова підсистема використовує SSD.

Який VPS-конфіг мінімально підійде для Baserow?

Відповідь: Для тестування або дуже маленької команди (1-2 користувачі) мінімальний конфіг — це 2 ядра CPU, 2 ГБ RAM та 40 ГБ SSD. Однак для стабільної та комфортної роботи з невеликою командою (до 10-15 осіб) рекомендується не менше 2-4 ядер CPU, 4 ГБ RAM та 80 ГБ SSD. SSD-диск є обов'язковим для хорошої продуктивності бази даних.

Що вибрати — VPS чи dedicated для цього завдання?

Відповідь: Для більшості сценаріїв використання Baserow (особисті проєкти, невеликі та середні команди) VPS є оптимальним вибором. Він пропонує достатню продуктивність, гнучкість та економічність. Виділений сервер потрібен лише при дуже високих навантаженнях (сотні активних користувачів, терабайти даних), специфічних апаратних вимогах або суворих регуляторних нормах, що вимагають повного контролю над фізичним обладнанням. Почніть з VPS і масштабуйтеся до dedicated, якщо виникне реальна необхідність.

Як скинути пароль адміністратора Baserow, якщо я його забув?

Що перевірити: Якщо ви налаштували SMTP, ви можете використовувати функцію "Забули пароль" на сторінці входу. Якщо SMTP не налаштований, вам потрібно буде виконати скидання пароля через консоль Docker.

Як виправити: Підключіться до сервера по SSH, перейдіть до директорії Baserow (~/baserow). Потім виконайте команду для скидання пароля користувача із зазначеним email:

docker compose exec baserow_backend python3 manage.py reset_user_password --email [email protected]

Ця команда згенерує тимчасовий пароль, який ви зможете використовувати для входу, а потім змінити його в інтерфейсі Baserow.

Закінчилося місце на диску VPS.

Що перевірити: Використовуйте df -h для перевірки загального використання диска та du -sh /var/lib/docker/volumes/* для перевірки розмірів Docker-томів. Часто місце займають старі Docker-образи, кеш або логи.

Як виправити: Очистіть старі Docker-об'єкти: docker system prune -a (обережно, видаляє всі зупинені контейнери, невикористовувані мережі, образи та томи). Регулярно видаляйте старі резервні копії, особливо локальні. Розгляньте можливість збільшення дискового простору VPS або перенесення резервних копій на зовнішнє сховище.