Budibase в Docker Compose: готовый файл

MAATRIX

Budibase — low-code платформа для сборки внутренних приложений: админок, форм, дашбордов и CRUD-панелей поверх своих данных, без месяцев разработки на React и Node. Официальный способ поставить её на свой сервер — Docker Compose, но готовый docker-compose.yml из репозитория Budibase рассчитан на голую установку и не учитывает ни домен с SSL, ни бэкапы, ни лимиты ресурсов. Ниже — рабочий файл, который можно брать и запускать, с пояснением, что в нём отличается от коробочного варианта и почему.

Зачем Budibase на своём сервере, а не в облаке

У Budibase есть облачная версия (budibase.com), но self-hosted вариант даёт три вещи, которых в облаке нет:

• Данные остаются у вас. Если приложение строится над клиентской базой, финансами или внутренними процессами компании — держать это на чужой инфраструктуре часто прямо запрещено политикой безопасности.
• Нет лимитов бесплатного тарифа. Community-версия Budibase (та, что в Docker-образе) бесплатна без ограничений по числу пользователей и приложений — платите только за сервер.
• Полный контроль над интеграциями. Можно подключить внутренние API, базы данных за VPN, LDAP для авторизации — то, что в облачной версии либо недоступно, либо требует платного плана.

Обратная сторона: обновления, бэкапы и мониторинг — ваша забота. Дальше разберём, как закрыть эти вопросы сразу при развёртывании.

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

Budibase — это несколько контейнеров: сам apps-сервис, worker, CouchDB (хранит метаданные приложений) и опционально Redis для кэша сессий. На практике:

Это ориентир, не измеренный бенчмарк — реальное потребление сильно зависит от того, сколько данных вы храните внутри Budibase (встроенная база на CouchDB) и сколько workflow-автоматизаций крутится одновременно. Для теста и небольшой команды хватает VPS с 2 ГБ памяти, для рабочего инстанса лучше закладывать 4 ГБ с запасом.

Систему проверял на Ubuntu 24.04 с уже установленным Docker и Docker Compose plugin — если Docker ещё не стоит, это отдельный шаг до всего остального.

Готовый docker-compose.yml

Вот файл, который отличается от коробочного тем, что: вынесены все секреты в .env, добавлены healthcheck и restart: unless-stopped, ограничены ресурсы контейнеров, и данные CouchDB лежат в именованном volume, а не в анонимном (чтобы не потерять их при docker compose down).

Создайте директорию и файл .env:

mkdir -p /opt/budibase && cd /opt/budibase
nano .env

Содержимое .env:

BUDIBASE_URL=https://apps.example.com
COUCHDB_USER=budibase_admin
COUCHDB_PASSWORD=замените_на_длинный_случайный_пароль
INTERNAL_API_KEY=замените_на_случайную_строку_32_символа
JWT_SECRET=замените_на_случайную_строку_32_символа
MINIO_ACCESS_KEY=budibase_minio
MINIO_SECRET_KEY=замените_на_длинный_случайный_пароль
REDIS_PASSWORD=замените_на_длинный_случайный_пароль

Сгенерировать случайные строки можно так:

openssl rand -hex 24

Теперь сам docker-compose.yml:

version: "3"

services:
  app-service:
    image: budibase/apps
    restart: unless-stopped
    env_file: ./.env
    environment:
      - SELF_HOSTED=1
      - COUCH_DB_URL=http://${COUCHDB_USER}:${COUCHDB_PASSWORD}@couchdb-service:5984
      - REDIS_URL=redis-service:6379
      - REDIS_PASSWORD=${REDIS_PASSWORD}
      - MINIO_URL=http://minio-service:9000
      - MINIO_ACCESS_KEY=${MINIO_ACCESS_KEY}
      - MINIO_SECRET_KEY=${MINIO_SECRET_KEY}
      - INTERNAL_API_KEY=${INTERNAL_API_KEY}
      - JWT_SECRET=${JWT_SECRET}
      - PLATFORM_URL=${BUDIBASE_URL}
    depends_on:
      - couchdb-service
      - redis-service
      - minio-service
    deploy:
      resources:
        limits:
          memory: 1.5g
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:4002/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  worker-service:
    image: budibase/worker
    restart: unless-stopped
    env_file: ./.env
    environment:
      - SELF_HOSTED=1
      - COUCH_DB_URL=http://${COUCHDB_USER}:${COUCHDB_PASSWORD}@couchdb-service:5984
      - REDIS_URL=redis-service:6379
      - REDIS_PASSWORD=${REDIS_PASSWORD}
      - MINIO_URL=http://minio-service:9000
      - MINIO_ACCESS_KEY=${MINIO_ACCESS_KEY}
      - MINIO_SECRET_KEY=${MINIO_SECRET_KEY}
      - INTERNAL_API_KEY=${INTERNAL_API_KEY}
      - JWT_SECRET=${JWT_SECRET}
      - PLATFORM_URL=${BUDIBASE_URL}
    depends_on:
      - couchdb-service
      - redis-service
      - minio-service
    deploy:
      resources:
        limits:
          memory: 1g

  proxy-service:
    image: budibase/proxy
    restart: unless-stopped
    environment:
      - PROXY_RATE_LIMIT_WEBHOOKS_PER_SECOND=10
      - APPS_UPSTREAM_URL=http://app-service:4002
      - WORKER_UPSTREAM_URL=http://worker-service:4003
      - MINIO_UPSTREAM_URL=http://minio-service:9000
      - COUCHDB_UPSTREAM_URL=http://couchdb-service:5984
    ports:
      - "127.0.0.1:10000:10000"
    depends_on:
      - app-service
      - worker-service

  couchdb-service:
    image: budibase/couchdb:v3.5.0
    restart: unless-stopped
    environment:
      - COUCHDB_USER=${COUCHDB_USER}
      - COUCHDB_PASSWORD=${COUCHDB_PASSWORD}
    volumes:
      - couchdb_data:/data
    deploy:
      resources:
        limits:
          memory: 1g

  redis-service:
    image: redis
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}
    volumes:
      - redis_data:/data

  minio-service:
    image: minio/minio
    restart: unless-stopped
    environment:
      - MINIO_ACCESS_KEY=${MINIO_ACCESS_KEY}
      - MINIO_SECRET_KEY=${MINIO_SECRET_KEY}
    command: server /data
    volumes:
      - minio_data:/data

volumes:
  couchdb_data:
  redis_data:
  minio_data:

Ключевое отличие от многих примеров в сети: proxy-service слушает только на 127.0.0.1:10000, а не на всех интерфейсах. Наружу сервис пойдёт через отдельный reverse-proxy с SSL — это безопаснее, чем светить порт 10000 напрямую наружу без шифрования.

Запуск:

docker compose up -d
docker compose ps

Первый старт CouchDB и MinIO занимает 20-40 секунд — если сразу открыть порт 10000, можно увидеть 502, это нормально, подождите и проверьте docker compose logs -f app-service.

Домен и SSL через Caddy

Проще всего отдать Budibase наружу через Caddy — он сам получает и обновляет сертификат Let's Encrypt. Если Caddy ещё не стоит на сервере, поставьте его отдельно (или используйте контейнерный вариант) — подробный разбор автоматического SSL есть в статье про Let's Encrypt на VPS.

Файл /etc/caddy/Caddyfile (или блок в существующем):

apps.example.com {
    reverse_proxy 127.0.0.1:10000
}

Перезапустите Caddy:

sudo systemctl reload caddy

Если вы уже используете Traefik как обратный прокси для других контейнеров на этом сервере — логика та же, только вместо системного Caddy добавляется label-роутинг; общий подход к такой схеме описан в статье про Traefik как reverse proxy для Docker.

Не забудьте, что BUDIBASE_URL в .env должен совпадать с реальным доменом — иначе будут глюки с CORS и редиректами после логина.

Первый запуск и создание организации

Откройте https://apps.example.com в браузере. При первом заходе Budibase попросит создать аккаунт администратора — это локальный аккаунт, никуда не отправляется, хранится в вашей CouchDB. После этого откроется портал, где можно:

• создать первое приложение с нуля или из шаблона;
• подключить внешний источник данных (PostgreSQL, MySQL, MongoDB, REST API, Google Sheets);
• настроить встроенную базу данных приложения (аналог таблиц Airtable).

Для внутренних инструментов чаще всего логичнее не заводить данные внутри Budibase, а подключить существующую PostgreSQL — тогда Budibase остаётся просто слоем интерфейса, а данные и их бэкапы управляются отдельно от low-code платформы. Это снижает риск: если что-то сломается в самом Budibase, данные не пострадают.

Бэкапы: что реально нужно сохранять

В self-hosted Budibase состояние живёт в трёх местах: CouchDB (структура приложений, пользователи, встроенные таблицы), MinIO (загруженные файлы и вложения) и volume Redis (сессии — не критично, эфемерно). Бэкапить нужно первые два.

Простой скрипт для регулярного бэкапа через docker compose exec:

#!/bin/bash
set -e
BACKUP_DIR=/opt/budibase-backups/$(date +%F)
mkdir -p "$BACKUP_DIR"

# CouchDB — экспорт баз через встроенный replicator API проще делать через volume-снапшот
docker run --rm \
  -v budibase_couchdb_data:/data \
  -v "$BACKUP_DIR":/backup \
  alpine tar czf /backup/couchdb_data.tar.gz -C /data .

docker run --rm \
  -v budibase_minio_data:/data \
  -v "$BACKUP_DIR":/backup \
  alpine tar czf /backup/minio_data.tar.gz -C /data .

find /opt/budibase-backups -mindepth 1 -maxdepth 1 -mtime +14 -exec rm -rf {} \;

Имя volume зависит от того, как называется директория проекта (Docker Compose добавляет её как префикс) — проверьте реальное имя через docker volume ls | grep budibase. Поставьте скрипт в cron на ежедневный запуск в тихие часы. Если на сервере уже есть централизованная система бэкапов, стоит посмотреть в сторону BorgBackup в Docker Compose — он умеет дедупликацию и экономит место при ежедневных снапшотах volume’ов.

Восстановление — обратная операция: остановить стек, распаковать архив в volume, поднять снова.

Обновление версии

Budibase обновляется довольно часто. Стандартная процедура:

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

Перед обновлением на проде обязательно снимите бэкап — миграции CouchDB иногда необратимы в обратную сторону, откатиться на старую версию образа после апдейта схемы не всегда получится. Если между вами и мажорным обновлением большой разрыв версий (например, вы стояли на 2.x, а актуальна уже 3.x), читайте release notes на GitHub Budibase — там явно помечают breaking changes.

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