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

MAATRIX

Когда аналитику нужен доступ к базе, а разработчик не хочет каждый раз писать SQL-выборки руками и пересылать CSV в мессенджер, на сцену выходит Redash — открытый инструмент для запросов и дашбордов, который умеет подключаться почти к любой СУБД и превращать SQL-запрос в шарируемую визуализацию. Ниже — рабочая установка на собственном VPS через Docker Compose, с настройкой почты, HTTPS и первыми подключениями к базам.

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

Redash — open-source платформа для BI-запросов: пишете SQL (или используете встроенные коннекторы к Google Sheets, MongoDB, ClickHouse, Elasticsearch и десяткам других источников), получаете таблицу или график, собираете из них дашборд и делитесь ссылкой с коллегами без доступа к самой базе.

Он не заменяет полноценные BI-платформы вроде Metabase или Superset по глубине аналитики, но выигрывает там, где команда состоит из людей, комфортно чувствующих себя в SQL: аналитик пишет запрос — маркетолог смотрит готовый дашборд. Если у вас в команде SQL знает один человек, а остальным нужны конструкторы без кода, стоит присмотреться к Metabase — там ниже порог входа для нетехнических пользователей.

Типичные сценарии для Redash: дашборд метрик продукта поверх PostgreSQL, еженедельные отчёты по продажам из нескольких источников, мониторинг бизнес-показателей рядом с техническим мониторингом на Grafana. Устанавливать его стоит на отдельный VPS — Redash тянет за собой Postgres, Redis и несколько воркеров, и на общем сервере с продакшен-базой это лишняя нагрузка и лишний вектор для ошибок конфигурации.

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

Официальный Docker Compose файл Redash поднимает пять контейнеров: сам сервер, воркер для фоновых задач (запросы, обновление кэша, алерты), scheduler, собственный PostgreSQL для хранения дашбордов и Redis как брокер очередей.

Минимальная конфигурация, с которой Redash работает предсказуемо:

Если Redash будет ходить в вашу продакшен-базу с тяжёлыми аналитическими запросами, закладывайте память отдельно — сам Redash с Postgres и Redis съедает 1.5-2 GB в простое, но пиковые запросы к внешним источникам данных проходят через воркер, а не через сервер, поэтому на самом Redash это сказывается меньше, чем на базе-источнике. Для стабильной работы под нагрузкой лучше сразу брать VPS на 4 vCPU / 8 GB — апгрейд задним числом с остановкой сервисов не всегда удобен.

Установка Docker и подготовка окружения

Redash официально поставляется как набор Docker-образов, и разворачивать его вручную из исходников почти никто не делает — слишком много зависимостей (Python-пакеты, драйверы под конкретные БД, фронтенд-сборка). Ставим Docker Engine и Compose plugin:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

После usermod перелогиньтесь (или выполните newgrp docker), чтобы запускать docker-команды без sudo. Проверьте, что Compose plugin встал вместе с движком:

docker compose version

Создайте рабочую директорию и подтяните официальный docker-compose файл проекта:

mkdir -p /opt/redash && cd /opt/redash
curl -O https://raw.githubusercontent.com/getredash/redash/master/docker-compose.yml
curl -O https://raw.githubusercontent.com/getredash/redash/master/.env

Файл .env — это где живут ключевые настройки: секретный ключ, cookie secret, параметры Postgres. Перед первым запуском сгенерируйте собственные секреты вместо значений по умолчанию из репозитория — это не опция, а обязательный шаг для безопасности:

python3 -c "import secrets; print(secrets.token_hex(32))"

Вставьте результат в REDASH_COOKIE_SECRET и REDASH_SECRET_KEY в .env — используйте два разных сгенерированных значения, не один и тот же ключ для обеих переменных.

Развёртывание через Docker Compose

Прежде чем поднимать полный стек, нужно инициализировать базу данных Redash — создать схему и служебные таблицы. Официальный compose-файл включает сервис create_db, который делает это одной командой:

docker compose run --rm server create_db

Дождитесь, пока команда отработает без ошибок (обычно 10-20 секунд), затем поднимайте весь стек:

docker compose up -d

Проверьте, что все пять контейнеров запустились и не падают в рестарт-цикл:

docker compose ps
docker compose logs -f server

В логах сервера ищите строку о старте на порту 5000 — по умолчанию Redash слушает именно его. Если контейнер server уходит в restart loop, чаще всего причина — неверные креды к встроенной Postgres в .env (значения REDASH_DATABASE_URL должны совпадать с тем, что задано в сервисе postgres того же compose-файла) или недостаточно памяти на сервере для одновременного старта всех контейнеров.

Откройте http://ваш_IP:5000 в браузере — должна появиться форма создания первого администратора. На этом этапе Redash уже работает, но только по HTTP и без домена — для рабочего использования это нужно закрыть.

Настройка домена, HTTPS и обратного прокси

Открывать BI-инструмент с бизнес-данными по голому HTTP и IP-адресу — плохая идея даже для внутреннего использования. Заведите A-запись на ваш VPS (например redash.вашдомен.ru) и поставьте перед контейнером Redash Nginx как обратный прокси с Let's Encrypt.

Если домен ещё не настроен на сервере, начните с базовой привязки DNS — процесс подробно разобран в статье про настройку домена и DNS на Ubuntu 24.04. Дальше нужен сам Nginx с проксированием на порт 5000:

server {
    listen 80;
    server_name redash.вашдомен.ru;

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

Подробный разбор конфигурации reverse proxy, включая нюансы с WebSocket и таймаутами (у Redash есть живое обновление статуса запросов через периодический поллинг, долгие запросы иначе будут упираться в таймаут прокси) — в статье Nginx как обратный прокси на Ubuntu 24.04. Обязательно увеличьте proxy_read_timeout до 60-120 секунд, если аналитики будут гонять тяжёлые запросы к внешним источникам — иначе Nginx оборвёт соединение раньше, чем Redash получит ответ от базы.

Сертификат ставится стандартным certbot:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d redash.вашдомен.ru

После выпуска сертификата обновите REDASH_HOST в .env на https://redash.вашдомен.ru и перезапустите стек (docker compose restart server worker), иначе ссылки в письмах-приглашениях и алертах будут генерироваться с неверным протоколом.

Не забудьте про файрвол — открытым наружу должен быть только 443/80 порт для Nginx, а 5000-й порт Redash стоит закрыть от внешнего доступа, оставив его только на localhost. Как настроить UFW под такую схему — в статье про установку и настройку файрвола UFW на VPS.

Подключение источников данных

Первое, что делаете после логина администратором — идёте в Settings → Data Sources → New Data Source и подключаете первую базу. Redash поддерживает PostgreSQL, MySQL, ClickHouse, MongoDB, Google Sheets, Elasticsearch, Athena, BigQuery и ещё около четырёх десятков коннекторов из коробки.

Для PostgreSQL форма подключения простая:

• Host — адрес сервера с базой (если это другой VPS, используйте его внутренний IP или домен, а не localhost)
• Port — 5432 по умолчанию
• User / Password — учётная запись с правами SELECT на нужные схемы, без прав на запись
• Database name — конкретная база

Здесь важный момент безопасности: создайте для Redash отдельного read-only пользователя на стороне PostgreSQL, а не подключайтесь под суперпользователем. Это минимум одна команда:

CREATE USER redash_ro WITH PASSWORD 'сложный_пароль';
GRANT CONNECT ON DATABASE your_db TO redash_ro;
GRANT USAGE ON SCHEMA public TO redash_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO redash_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO redash_ro;

Если продакшен-база и сервер Redash стоят на разных VPS, убедитесь, что PostgreSQL слушает не только localhost и что доступ к порту 5432 ограничен конкретным IP сервера с Redash — общие принципы настройки самой базы описаны в статье об установке PostgreSQL на Ubuntu 24.04. Открывать 5432-й порт всему интернету не стоит ни при каких обстоятельствах.

Дашборды, алерты и шаринг для команды

После подключения источника данных рабочий цикл такой: создаёте запрос в разделе Queries, визуализируете результат (таблица, график, счётчик, sunburst — визуализаций больше десятка), затем добавляете виджет на дашборд через Dashboards → New Dashboard.

Полезные возможности, которые часто упускают на старте:

• Параметризованные запросы — вместо десяти похожих запросов под разные фильтры пишете один с {{ дата_начала }} и {{ регион }}, а пользователь дашборда сам выбирает значения в выпадающих списках.
• Кэширование результатов — тяжёлый запрос к базе можно кэшировать на заданное время (например, обновлять раз в час), чтобы дашборд открывался мгновенно и не грузил продакшен-базу при каждом просмотре.
• Алерты — Redash умеет проверять результат запроса по расписанию и слать уведомление (в том числе на почту или в Slack-подобные интеграции), если значение вышло за порог — например, если конверсия упала ниже заданного процента.
• Публичные дашборды — можно сгенерировать ссылку на дашборд без авторизации, полезно для витрины метрик, которую смотрит вся команда через большой экран в офисе.

Для приглашения коллег нужна работающая почта — Redash шлёт письма с приглашением и алертами через SMTP, настройки которого задаются переменными REDASH_MAIL_* в .env (сервер, порт, логин, пароль, шифрование). Без корректного SMTP пригласить пользователя можно только вручную, скопировав ссылку-приглашение из логов сервера — рабочий, но неудобный обходной путь для небольшой команды на старте.

Резервное копирование и обновление

Вся конфигурация дашбордов, запросов и подключений хранится во встроенной PostgreSQL-базе Redash (не путать с базами-источниками данных — это отдельная внутренняя БД самого приложения). Бэкапить нужно именно её:

docker compose exec postgres pg_dump -U postgres postgres > redash_backup_$(date +%F).sql

Разумно вынести это в cron на самом VPS с ротацией старых бэкапов и, по возможности, копированием на внешнее хранилище — локальный снапшот диска не спасёт, если проблема в самом контейнере или человеческой ошибке в конфигурации.

Обновление до новой версии — это смена тега образа в docker-compose.yml и пересоздание контейнеров:

cd /opt/redash
docker compose pull
docker compose up -d
docker compose run --rm server manage db upgrade

Перед мажорным обновлением делайте бэкап и проверяйте changelog проекта на breaking changes — как и у любого активно развивающегося open-source инструмента, между версиями иногда меняется формат конфигурации или требуется дополнительный шаг миграции.

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