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

MAATRIX

Если вы уже держите данные в PostgreSQL или MySQL, но команде нужен интерфейс уровня Airtable — фильтры, канбан, формы, галерея — не обязательно тащить данные в облачный SaaS. NocoDB превращает любую SQL-базу в такой интерфейс, разворачивается одним docker-compose.yml и остаётся полностью у вас на сервере. Ниже — рабочий конфиг, который можно скопировать и запустить, плюс нюансы, которые обычно всплывают уже после первого деплоя.

Что такое NocoDB и когда он оправдан

NocoDB — open-source надстройка над реляционной базой: она читает схему таблиц и на лету строит вокруг них веб-интерфейс с представлениями (грид, канбан, календарь, галерея, формы), правами доступа, API (REST и GraphQL) и вебхуками. Технически это не отдельная СУБД — данные всегда лежат в обычном PostgreSQL, MySQL, SQL Server или SQLite, а NocoDB просто читает и пишет туда через свой слой метаданных.

Это принципиально отличает его от Airtable и Baserow: вы не мигрируете данные в проприетарный формат, а даёте no-code интерфейс поверх базы, которая и так у вас есть или будет жить своей жизнью — с ней могут одновременно работать бэкенд-приложение, аналитика на Metabase и NocoDB для нетехнической команды.

Типичные сценарии:

• CRM или трекер заявок для отдела, у которого нет времени ждать бэкенд-разработчика;
• внутренняя админка над существующей базой продакшен-приложения (с осторожностью — см. раздел про права);
• быстрые формы сбора данных с автоматическим попаданием в таблицу;
• замена Google Sheets/Airtable там, где данные не должны покидать периметр компании.

Если нужна база данных, а не готовый интерфейс — прочитайте про установку PostgreSQL на VPS: NocoDB в проде почти всегда работает в связке именно с ней.

Минимальный docker-compose.yml

Самый простой вариант — NocoDB со встроенной SQLite для хранения метаданных (не путать с данными таблиц, они всё равно останутся в подключаемой внешней базе, если вы её укажете, либо в той же SQLite для теста):

version: "3.8"

services:
  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      NC_PUBLIC_URL: "https://nocodb.example.com"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  nocodb_data:

Этого достаточно для теста на localhost. Но для продакшена почти всегда нужна отдельная PostgreSQL — и для хранения метаданных NocoDB (тогда рестарт контейнера не риск потерять права/вьюхи), и как основная база с рабочими таблицами.

Продакшен-конфиг: NocoDB + PostgreSQL + Redis

Полный стек с внешней базой для метаданных и Redis для кеша/очередей (Redis не обязателен, но заметно ускоряет работу с большими таблицами):

version: "3.8"

services:
  nocodb-db:
    image: postgres:16-alpine
    container_name: nocodb-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: ${NC_DB_PASSWORD}
      POSTGRES_DB: nocodb_meta
    volumes:
      - nocodb_pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U nocodb -d nocodb_meta"]
      interval: 10s
      timeout: 5s
      retries: 5

  nocodb-redis:
    image: redis:7-alpine
    container_name: nocodb-redis
    restart: unless-stopped
    command: redis-server --requirepass ${NC_REDIS_PASSWORD}
    volumes:
      - nocodb_redis_data:/data

  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    depends_on:
      nocodb-db:
        condition: service_healthy
      nocodb-redis:
        condition: service_started
    ports:
      - "8080:8080"
    environment:
      NC_DB: "pg://nocodb-db:5432?u=nocodb&p=${NC_DB_PASSWORD}&d=nocodb_meta"
      NC_REDIS_URL: "redis://:${NC_REDIS_PASSWORD}@nocodb-redis:6379/0"
      NC_PUBLIC_URL: "https://nocodb.example.com"
      NC_DISABLE_TELE: "true"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  nocodb_pg_data:
  nocodb_redis_data:
  nocodb_data:

Секреты выносим в .env рядом с файлом:

NC_DB_PASSWORD=сложный_пароль_без_спецсимволов_amp
NC_REDIS_PASSWORD=другой_сложный_пароль

Важный нюанс: пароль в NC_DB передаётся строкой в connection string, поэтому символы &, ?, #, / в нём лучше не использовать — они ломают парсинг URL. Проще сгенерировать пароль без спецсимволов: openssl rand -hex 24.

Поднимаем:

docker compose up -d
docker compose logs -f nocodb

Первый старт создаёт схему метаданных в nocodb_meta — это может занять 15-30 секунд, дождитесь строки App: Server started в логах, прежде чем открывать интерфейс.

Подключение существующей базы с данными

Ключевая механика NocoDB: база метаданных (где хранится сам NocoDB) может быть отдельной от базы с рабочими данными. После первого входа в веб-интерфейс (по адресу сервера на порту 8080) создаётся аккаунт администратора, а затем через Data Sources → New Data Source подключается любая внешняя PostgreSQL/MySQL.

Если ваша рабочая база тоже в Docker и в той же сети — указывайте имя сервиса как хост:

Если база снаружи Docker (на другом сервере или у облачного провайдера) — просто укажите публичный или внутренний IP и откройте порт в файрволе только для IP вашего сервера с NocoDB, никогда не для 0.0.0.0/0.

Практический совет: для подключения продакшен-базы создайте отдельного read-write пользователя PostgreSQL с правами только на нужную схему, а не заводите NocoDB под суперпользователем — это не встроенное требование NocoDB, а обычная гигиена доступов, которая один раз спасёт вас от случайного DROP TABLE через интерфейс.

HTTPS через Caddy или Traefik

NocoDB сам по себе HTTP-сервис на порту 8080, TLS он не терминирует — это задача реверс-прокси перед ним. Проще всего добавить Caddy отдельным сервисом в тот же compose-файл:

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - nocodb

volumes:
  caddy_data:
  caddy_config:

И Caddyfile рядом:

nocodb.example.com {
    reverse_proxy nocodb:8080
}

Caddy сам выпустит и продлит сертификат Let's Encrypt при условии, что домен указывает на IP сервера, а порты 80/443 открыты. Подробный разбор автоматического SSL — в статье про установку Caddy на VPS. Если у вас уже есть Traefik для других сервисов на том же хосте — логичнее повесить NocoDB лейблами на него, а не поднимать второй прокси; сравнение подходов есть в статье Traefik или Nginx Proxy Manager.

После этого не забудьте обновить NC_PUBLIC_URL на https:// и перезапустить контейнер nocodb — иначе сгенерированные ссылки на формы и вебхуки будут указывать на http и порт 8080.

Бэкапы: два слоя данных, которые легко перепутать

Здесь частая ошибка — бэкапить только volume nocodb_data, думая, что это спасёт от потери данных. На деле в NocoDB два независимых слоя:

1. Метаданные (структура таблиц, вьюхи, права, автоматизации) — лежат в базе, указанной в NC_DB (в нашем конфиге — nocodb_pg_data), либо в SQLite внутри nocodb_data, если внешнюю базу не подключали.
2. Сами данные — в тех PostgreSQL/MySQL базах, которые вы подключили как Data Source. NocoDB их не копирует и не дублирует, а только предоставляет к ним доступ.

То есть бэкап должен покрывать оба слоя: pg_dump для nocodb_meta и отдельный pg_dump (или дамп MySQL) для каждой подключённой рабочей базы.

# метаданные NocoDB
docker exec nocodb-db pg_dump -U nocodb nocodb_meta > backup_nocodb_meta_$(date +%F).sql

# рабочая база (пример для отдельного контейнера my-postgres)
docker exec my-postgres pg_dump -U app_user app_db > backup_app_db_$(date +%F).sql

Для регулярных автоматических бэкапов с ротацией и выгрузкой во внешнее хранилище есть смысл поставить BorgBackup — конфиг под Docker описан в статье BorgBackup в Docker Compose, а базовая установка — в пошаговой инструкции по BorgBackup.

Обновление версии и типичные грабли

NocoDB развивается быстро, мажорные обновления иногда меняют формат метаданных. Общее правило безопасного апдейта:

# 1. Снять дамп базы метаданных перед обновлением — обязательно
docker exec nocodb-db pg_dump -U nocodb nocodb_meta > pre_update_backup.sql

# 2. Обновить образ
docker compose pull nocodb
docker compose up -d nocodb

# 3. Проверить логи на ошибки миграции
docker compose logs -f nocodb

Частые проблемы после деплоя:

• Контейнер стартует, но интерфейс отдаёт 502 через прокси. Обычно значит, что NocoDB ещё не поднялся (миграция базы идёт дольше обычного при большом числе таблиц) — подождите и смотрите логи, а не перезапускайте контейнер сразу.
• Формы и шеринг-ссылки открываются по http, хотя сайт на https. Проверьте NC_PUBLIC_URL — эта переменная не подхватывается автоматически из заголовков прокси, её нужно задать явно.
• После рестарта пропали все таблицы и вьюхи. Почти всегда значит, что NC_DB не был задан и NocoDB использовал встроенную SQLite внутри контейнера, а volume для неё не был примонтирован (или был перезаписан при пересоздании контейнера без -v). Для прода NC_DB с внешней PostgreSQL обязателен.
• Долгие запросы к таблицам с десятками тысяч строк. Добавьте индексы на колонки, по которым обычно фильтруете и сортируете в NocoDB-вьюхах — сам NocoDB индексов не создаёт, это обычная СУБД под капотом.

Если на сервере уже крутится и NocoDB, и другие Docker-сервисы, полезно почитать про организацию Docker Compose для прода — там разобраны сети, healthchecks и порядок запуска сервисов, которые пригодятся и здесь.

Ресурсы сервера

NocoDB сам по себе легковесен, но реальное потребление зависит от объёма подключённых данных и числа одновременных пользователей:

Эти цифры — ориентир, а не измеренный бенчмарк: реальное потребление зависит от сложности вьюх, количества вебхуков и того, сколько данных гоняется через API. Для теста хватит младшего VPS, для команды лучше сразу закладывать запас по RAM — PostgreSQL и NocoDB вместе на 1 ГБ будут заметно тормозить под нагрузкой.

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