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

MAATRIX

Аналитику в компании обычно просят "просто сделать дашборд" — а в итоге кто-то из разработчиков раз в неделю вручную гоняет SQL-запросы и вставляет скриншоты в презентацию. Metabase закрывает этот разрыв: коллеги без знания SQL строят графики и таблицы сами, а вы один раз поднимаете сервис на своём VPS и подключаете к нему рабочие базы данных. Ниже — рабочая установка через Docker Compose с отдельной базой под сам Metabase, reverse proxy с SSL и первыми шагами по настройке дашбордов.

Что нужно для установки и минимальные требования к серверу

Metabase — это Java-приложение (JAR внутри Docker-образа), и именно JVM определяет требования к памяти, а не объём ваших данных — сами данные остаются в подключаемых базах, Metabase их не копирует к себе.

Для комфортной работы на VPS ориентируйтесь на:

• CPU: 2 vCPU — на старте хватит и 1, но при параллельных дашбордах и алертах Metabase упирается в CPU быстрее, чем в память;
• RAM: 2–4 ГБ. Сам Metabase в простое съедает около 500–800 МБ, но под нагрузкой (несколько сложных вопросов одновременно) стоит держать запас;
• Диск: 20 ГБ более чем достаточно — сам Metabase занимает мало места, основной рост идёт за счёт логов и снапшотов базы метаданных;
• ОС: Ubuntu 24.04 LTS или Debian 12 — везде, где есть Docker.

Это ориентировочные цифры из практики небольших и средних инсталляций — при десятках активных пользователей и тяжёлых запросах вам может понадобиться больше RAM, точный запас лучше смотреть по docker stats после недели реальной работы.

Понадобится VPS с публичным IP, доменное имя (или поддомен) для доступа по HTTPS и установленный Docker с Docker Compose. Если Docker ещё не стоит — сначала разверните его, это отдельная тема.

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

Официальный образ metabase/metabase — самый предсказуемый способ развернуть сервис: не нужно вручную ставить Java, а обновление сводится к смене тега образа.

Создайте рабочую директорию и файл окружения:

mkdir -p /opt/metabase && cd /opt/metabase
cat > .env << 'EOF'
MB_DB_PASSWORD=замените_на_длинный_случайный_пароль
EOF
chmod 600 .env

Файл docker-compose.yml:

services:
  metabase-db:
    image: postgres:16-alpine
    container_name: metabase-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: metabase
      POSTGRES_USER: metabase
      POSTGRES_PASSWORD: ${MB_DB_PASSWORD}
    volumes:
      - metabase-db-data:/var/lib/postgresql/data
    networks:
      - metabase-net

  metabase:
    image: metabase/metabase:latest
    container_name: metabase
    restart: unless-stopped
    depends_on:
      - metabase-db
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: metabase
      MB_DB_PORT: 5432
      MB_DB_USER: metabase
      MB_DB_PASS: ${MB_DB_PASSWORD}
      MB_DB_HOST: metabase-db
      JAVA_TIMEZONE: Europe/Moscow
    ports:
      - "127.0.0.1:3000:3000"
    networks:
      - metabase-net

networks:
  metabase-net:

volumes:
  metabase-db-data:

Обратите внимание на MB_DB_TYPE: postgres — это не подключение к вашим рабочим данным, а база, в которой Metabase хранит собственные метаданные: пользователей, дашборды, сохранённые вопросы, права доступа. По умолчанию образ использует встроенную H2, но для продакшена это плохая идея: H2 — файловая база без нормальной поддержки конкурентного доступа, и при любом сбое контейнера риск повредить единственный файл с вашими дашбордами намного выше, чем с полноценным PostgreSQL. Поднимать её сразу правильно — переносить данные из H2 в PostgreSQL постфактум не так просто и не всегда проходит гладко.

Порт 3000 намеренно пробрасывается только на 127.0.0.1 — наружу сервис будет смотреть через Nginx с SSL, напрямую по HTTP наружу его открывать не стоит.

Запуск:

docker compose up -d
docker compose logs -f metabase

Первый старт занимает 1–2 минуты — JVM инициализирует служебную базу и прогревает Metabase. Как только в логах появится строка вида Metabase Initialization COMPLETE, сервис готов принимать соединения на порту 3000.

Nginx как reverse proxy и SSL-сертификат

Открывать порт 3000 в интернет напрямую не нужно — заведите поддомен, направьте A-запись на IP вашего VPS и настройте Nginx перед Metabase. Это тот же паттерн, что и для большинства веб-приложений на сервере — подробно разбор reverse proxy есть в статье про Nginx как обратный прокси.

Конфиг /etc/nginx/sites-available/metabase:

server {
    listen 80;
    server_name bi.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;

        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

Увеличенные таймауты не декоративные: тяжёлые аналитические запросы (агрегации по большим таблицам) могут выполняться дольше, чем стандартные 60 секунд Nginx, и без этой настройки браузер получит 504 раньше, чем Metabase успеет ответить.

Активируйте конфиг и получите сертификат:

ln -s /etc/nginx/sites-available/metabase /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d bi.example.com

Certbot сам допишет блок listen 443 ssl и настроит редирект с 80 порта. После этого добавьте в docker-compose.yml переменную MB_SITE_URL: https://bi.example.com — Metabase использует её для формирования ссылок в письмах и алертах, без неё уведомления будут вести на неправильный адрес.

Первый запуск и подключение источника данных

Откройте https://bi.example.com — мастер первичной настройки попросит создать учётную запись администратора, название компании и язык интерфейса. Дальше — самый важный шаг: подключение источника данных (вашей рабочей базы, не путать с базой метаданных Metabase).

Metabase из коробки поддерживает PostgreSQL, MySQL, ClickHouse, BigQuery, Snowflake, MongoDB и ещё десяток источников. Для PostgreSQL данные подключения выглядят так:

Если рабочая база — PostgreSQL на этом же VPS, имеет смысл держать её отдельно от базы метаданных Metabase — например, развернуть её так же, как описано в статье про установку PostgreSQL на VPS, и завести в ней read-only пользователя специально под Metabase:

CREATE ROLE metabase_reader WITH LOGIN PASSWORD 'другой_длинный_пароль';
GRANT CONNECT ON DATABASE production TO metabase_reader;
GRANT USAGE ON SCHEMA public TO metabase_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO metabase_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO metabase_reader;

Отдельный read-only пользователь — не паранойя, а базовая гигиена: даже если кто-то из аналитиков случайно напишет в редакторе вопросов деструктивный SQL, у роли просто не будет прав это выполнить.

Первые дашборды без единой строчки SQL

Ради этого всё и затевалось. После подключения источника Metabase сам просканирует схему базы, определит типы полей (даты, категории, числа) и построит X-ray — автоматический обзор с готовыми графиками по каждой таблице. Это хорошая отправная точка, но обычно вам нужны конкретные метрики, поэтому:

1. New → Question — визуальный конструктор запросов: выбираете таблицу, фильтры, группировку и агрегацию (сумма, среднее, количество) кликами, без SQL.
2. Результат сохраняется как Saved Question и может переиспользоваться в других вопросах — так же, как view в SQL, только собранная визуально.
3. Несколько вопросов собираются в Dashboard — с фильтрами, которые применяются сразу ко всем графикам на странице (например, единый фильтр по дате).
4. Для тех, кто SQL всё же знает, есть SQL editor — иногда быстрее написать запрос напрямую, чем собирать его конструктором, и Metabase не заставляет выбирать что-то одно.

Отдельно стоит настроить Alerts и Dashboard subscriptions — рассылку графика или дашборда на email/в Slack по расписанию. Для писем нужен рабочий SMTP: Admin → Settings → Email — впишите хост, порт, логин и пароль вашего почтового провайдера. Без этого шага алерты будут молча не работать — Metabase не всегда явно подсвечивает, что письма не уходят из-за отсутствия SMTP.

Обновление, бэкап и безопасность

Metabase хранит всё важное (дашборды, вопросы, настройки прав) в базе метаданных — поэтому бэкап сводится к бэкапу PostgreSQL-контейнера metabase-db:

docker exec metabase-db pg_dump -U metabase metabase | gzip > metabase-backup-$(date +%F).sql.gz

Вынесите это в cron и храните бэкапы за пределами сервера — на S3-совместимом хранилище или хотя бы на другом VPS. Восстановление — обратная операция:

gunzip -c metabase-backup-2026-08-20.sql.gz | docker exec -i metabase-db psql -U metabase metabase

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

docker compose pull metabase
docker compose up -d metabase

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

По безопасности — три вещи, которые стоит сделать сразу:

• Firewall: закройте на VPS всё, кроме 22/80/443 — 3000-й порт и так смотрит только на loopback, но проверить стоит; базовая настройка описана в статье про firewall UFW на сервере.
• Права пользователей внутри Metabase: используйте группы (Admin → People → Groups) и ограничивайте доступ к отдельным коллекциям дашбордов и источникам данных — не у каждого пользователя должен быть доступ ко всем базам.
• 2FA для админов: в Admin → Settings → Authentication включите two-factor authentication хотя бы для аккаунтов с правами администратора.

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