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

MAATRIX

Когда отделу нужен внутренний инструмент — панель для менеджеров, форма заявок, дашборд над базой заказов — можно неделями ждать фронтенд-разработчика, а можно собрать это за вечер в low-code платформе. Budibase — один из немногих open source конструкторов такого класса, который реально ставится на свой сервер целиком, без обязательной привязки к облаку вендора. Дальше — как поднять его на VPS, подключить свою базу данных и не потерять всё при первом же обновлении.

Что такое Budibase и когда он нужен

Budibase — это self-hosted low-code платформа для сборки внутренних приложений: CRUD-панелей, форм, дашбордов, простых воркфлоу с автоматизациями. В отличие от чисто табличных инструментов вроде NocoDB, у Budibase есть полноценный конструктор экранов (drag-and-drop UI builder) поверх данных — то есть вы получаете не только таблицу с API, а готовое приложение с формами, таблицами, кнопками и логикой переходов.

Он умеет работать как со встроенной базой (внутренние таблицы на CouchDB), так и подключаться к внешним источникам — PostgreSQL, MySQL, MS SQL, MongoDB, REST API, Google Sheets, Airtable. Это удобно, если данные уже живут в вашей продакшн-базе и плодить их копию в очередном SaaS не хочется.

Типичные сценарии: внутренняя CRM для отдела продаж, панель поддержки над тикетами, форма приёмки заявок с загрузкой файлов, дашборд для склада. Если нужна публичная витрина с высокой нагрузкой — Budibase не для этого, он рассчитан на внутренние инструменты с ограниченным числом пользователей.

Self-host имеет смысл, когда данные чувствительные (свои клиенты, финансы, персональные данные сотрудников) и вы не хотите заводить их в чужой облачный SaaS, либо когда просто дешевле держать это на своём VPS, чем платить за место в облачном тарифе Budibase.

Требования к серверу и подготовка VPS

Budibase — это не один процесс, а стек из нескольких контейнеров: сервис приложения, воркер для фоновых задач, CouchDB как основное хранилище, Redis для кэша и сессий, MinIO для файлов (вложения, картинки) и внутренний nginx-прокси, который сшивает всё это на одном порту. Из-за этого требования к памяти заметно выше, чем у одиночного контейнера с NocoDB или Appsmith.

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

• 2 vCPU;
• от 4 ГБ RAM (на 2 ГБ CouchDB и Redis будут периодически упираться в память под нагрузкой — это ориентир, у вас может отличаться в зависимости от числа приложений и объёма данных во вложениях);
• от 20 ГБ SSD — под образы, тома CouchDB и MinIO, плюс запас под бэкапы.

Понадобится домен (или поддомен), направленный A-записью на IP сервера — Budibase рассчитан на работу за HTTPS, и часть функций (OAuth-логины, вебхуки) без нормального домена и сертификата работать не будет.

Подготовка Ubuntu 24.04:

apt update && apt upgrade -y
apt install -y curl ufw
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Если Docker ещё не установлен — поставьте его штатным способом, это отдельная тема, разобранная в статье про установку Docker с нуля.

Установка Budibase через Docker Compose

У Budibase есть официальный установочный скрипт, который сам сгенерирует docker-compose.yaml и .env с нужными секретами — это заметно надёжнее, чем собирать конфиг руками, потому что между версиями состав сервисов и переменных менялся.

mkdir -p /opt/budibase && cd /opt/budibase
curl -L https://download.budibase.com/init | bash

Скрипт задаст несколько вопросов в интерактивном режиме: порт (по умолчанию 10000), домен, нужен ли встроенный выпуск SSL-сертификата через Let's Encrypt (можно отказаться, если сертификат и терминацию TLS вы берёте на себя через отдельный reverse-proxy — об этом ниже). После ответов он положит в директорию docker-compose.yaml и .env с уже сгенерированными паролями и ключами.

Если предпочитаете не запускать чужой скрипт с curl | bash на боевом сервере (разумная осторожность) — посмотрите содержимое docker-compose.yaml из официального репозитория Budibase на GitHub, скопируйте его руками и заполните .env сами. Обязательные переменные, которые там должны быть:

BB_ADMIN_USER_EMAIL=admin@example.com
BB_ADMIN_USER_PASSWORD=сложный-пароль
JWT_SECRET=случайная-строка-32+
INTERNAL_API_KEY=случайная-строка
COUCH_DB_PASSWORD=случайная-строка
REDIS_PASSWORD=случайная-строка
MINIO_ACCESS_KEY=случайная-строка
MINIO_SECRET_KEY=случайная-строка
PORT=10000
BUDIBASE_ENVIRONMENT=PRODUCTION

Сгенерировать случайные строки для секретов можно так, чтобы не полагаться на «пароль123»:

openssl rand -base64 32

Дальше — запуск:

cd /opt/budibase
docker compose up -d
docker compose ps

Первый старт занимает пару минут — CouchDB инициализирует свои системные базы, worker-service ждёт, пока поднимется app-service. Логи стоит посмотреть сразу:

docker compose logs -f app-service

Первая настройка: администратор, приложение, источники данных

Откройте http://IP-сервера:10000 (или домен, если уже настроили прокси). При первом заходе Budibase попросит создать организацию и учётную запись администратора — это тот самый BB_ADMIN_USER_EMAIL/BB_ADMIN_USER_PASSWORD из .env, либо форма регистрации, если вы их не задавали заранее.

После входа вы попадаете в портал, где создаются приложения. Каждое приложение в Budibase — изолированная сущность со своими таблицами, экранами и автоматизациями. Внутри приложения два основных режима:

• Data — источники данных: встроенные таблицы (хранятся в CouchDB) или подключения к внешним базам;
• Design — конструктор экранов: таблицы, формы, графики, кнопки, логика переходов между экранами.

Чтобы подключить внешний PostgreSQL вместо встроенных таблиц: Data → Add data source → PostgreSQL, укажите хост, порт, имя базы, пользователя и пароль. Если ваша база крутится на другом VPS, не забудьте открыть доступ по сети (или лучше — поднять её в приватной сети/VPN, а не светить порт 5432 наружу). Если база PostgreSQL ещё не развёрнута — есть отдельный разбор установки и настройки PostgreSQL на VPS.

Важный нюанс: Budibase при подключении внешней базы читает и пишет напрямую в боевые таблицы. Заведите отдельного пользователя БД с правами только на нужные таблицы, а не подключайте суперпользователя — это ограничит ущерб от случайного массового обновления строк из интерфейса.

Для файлов и картинок в формах используется встроенный MinIO — он поднимается автоматически вместе со стеком, отдельно настраивать S3-бакет не нужно, если вас устраивает локальное хранение на этом же сервере.

Reverse-proxy и HTTPS

Встроенный в Budibase скрипт может сам выпустить сертификат Let's Encrypt, но на практике удобнее и предсказуемее вынести TLS-терминацию на отдельный reverse-proxy перед стеком — так вы одинаково управляете сертификатами для всех сервисов на сервере, а не только для Budibase.

Вариант с Nginx: Budibase слушает 127.0.0.1:10000 (в .env можно указать PORT=10000 без публикации порта наружу — уберите 10000:10000 из секции ports в docker-compose.yaml, оставив проброс только на localhost, либо ограничьте через ufw). Конфиг:

server {
    listen 80;
    server_name budibase.example.com;
    location / {
        proxy_pass http://127.0.0.1:10000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
        client_max_body_size 50m;
    }
}

Заголовки Upgrade/Connection обязательны — часть интерфейса Budibase (живое обновление данных, автоматизации) работает через WebSocket, без них будут разрывы соединения и «зависающий» интерфейс. client_max_body_size стоит поднять, если через формы будут заливать файлы больше 1 МБ по умолчанию.

Дальше — сертификат через certbot штатным образом. Если ещё не настраивали связку Nginx с автоматическим HTTPS — там есть отдельные разборы и по Nginx как reverse-proxy, и по Let's Encrypt. Если предпочитаете автоматизацию сертификатов «из коробки» без ручного certbot — Caddy с авто-SSL закрывает это одной строкой конфига.

Отдельно закройте наружу порт 10000 в файрволе, если вы вынесли его на localhost:

ufw delete allow 10000/tcp

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

Все данные Budibase живут в двух местах: CouchDB (таблицы, приложения, конфигурация) и MinIO (вложения, файлы). Оба — обычные Docker-тома, поэтому бэкап сводится к резервному копированию этих томов целиком, а не к экспорту через интерфейс.

docker compose stop
docker run --rm -v budibase_couchdb:/data -v /opt/backups:/backup \
  alpine tar czf /backup/couchdb-$(date +%F).tar.gz -C /data .
docker run --rm -v budibase_minio:/data -v /opt/backups:/backup \
  alpine tar czf /backup/minio-$(date +%F).tar.gz -C /data .
docker compose start

Имена томов уточните командой docker volume ls | grep budibase — они зависят от того, как называется директория проекта. Для регулярных бэкапов без остановки сервиса разумнее использовать снапшоты тома через инструмент вроде restic или BorgBackup поверх запущенной CouchDB — она переживает бэкап без остановки, риск в основном в согласованности файлов на момент снятия снимка. Если бэкапы ещё не автоматизированы — общий подход описан в статье про BorgBackup на VPS.

Обновление стека:

cd /opt/budibase
docker compose pull
docker compose up -d
docker compose logs -f app-service

При обновлении между минорными версиями Budibase иногда прогоняет миграции CouchDB при первом старте — это видно в логах app-service, дождитесь, пока контейнер перейдёт в healthy, прежде чем считать апдейт завершённым. На боевом сервере разумно сначала накатить обновление на тестовом окружении с копией данных, а не сразу в проде — сохранёнными томами из бэкапа выше это делается быстро.

Частые проблемы на практике:

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