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

MAATRIX

Стартовая страница для домашней лаборатории или рабочего сервера обычно превращается либо в закладки браузера, которые никто не поддерживает в порядке, либо в самописный HTML на коленке. Dashy закрывает эту нишу иначе: один YAML-файл описывает все ссылки, а дашборд сам проверяет, жив ли сервис за каждой из них, и показывает статус прямо на плитке. Ниже — рабочий docker-compose.yml, структура конфига и настройка статус-чеков и виджетов, которые делают Dashy не просто списком ссылок, а живой панелью состояния инфраструктуры.

Чем Dashy отличается от Homer, Heimdall и Homepage

На рынке self-hosted дашбордов с десяток заметных проектов, и путаница в выборе — обычное дело. Разница по факту не в списке ссылок (это умеют все), а в том, что происходит с этим списком дальше.

Если нужен максимально лёгкий статический список — берите Homer. Если хочется, чтобы дашборд сам разбирал Docker-лейблы и рисовал карточки по контейнерам — Homepage ближе к этой задаче. Dashy — золотая середина: тяжелее Homer, но с полноценным UI-редактором, статус-мониторингом «из коробки» без плагинов и десятками готовых виджетов, которые не нужно писать самому.

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

Минимальный рабочий файл — контейнер с образом lissy93/dashy, проброс порта и монтирование конфига с хоста, чтобы правки переживали пересоздание контейнера.

services:
  dashy:
    image: lissy93/dashy:latest
    container_name: dashy
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - ./conf.yml:/app/public/conf.yml
      - ./item-icons:/app/public/item-icons
    environment:
      - NODE_ENV=production
      - UID=1000
      - GID=1000
    healthcheck:
      test: ["CMD", "node", "/app/services/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

Пара нюансов, которые экономят время при первом запуске:

• latest тянет актуальный релиз проекта — для домашней лаборатории это нормально, но на боевом сервере лучше зафиксировать конкретный тег с GitHub Releases, чтобы обновление не прилетело неожиданно вместе с рестартом контейнера.
• Каталог ./item-icons не обязателен, но пригодится, если хотите держать собственные иконки локально, а не тянуть их с CDN при каждой загрузке страницы.
• Встроенный healthcheck использует штатный скрипт образа — Docker будет видеть реальное состояние приложения, а не просто «порт слушает».

Перед первым стартом создайте пустой conf.yml рядом с compose-файлом (иначе Docker смонтирует его как директорию вместо файла):

touch conf.yml
mkdir -p item-icons
docker compose up -d

После запуска Dashy сгенерирует конфиг по умолчанию, если файл был пустым, и его можно будет редактировать прямо в браузере через встроенный UI-редактор (иконка шестерёнки → Config → Local Edit Mode).

conf.yml: структура, секции, items

Конфиг делится на три верхних блока: pageInfo (заголовок, favicon), appConfig (поведение интерфейса) и sections — собственно список карточек, сгруппированных по разделам.

pageInfo:
  title: Панель управления
  description: Инфраструктура проекта
  navLinks:
    - title: GitHub
      path: https://github.com

appConfig:
  theme: dracula
  layout: auto
  iconSize: medium
  language: ru
  statusCheck: true
  statusCheckInterval: 60

sections:
  - name: Инфраструктура
    icon: fas fa-server
    items:
      - title: Portainer
        description: Управление контейнерами
        icon: hl-portainer
        url: https://portainer.example.com
        statusCheck: true

      - title: Grafana
        description: Метрики и дашборды
        icon: hl-grafana
        url: https://grafana.example.com
        statusCheck: true
        statusCheckUrl: https://grafana.example.com/api/health

  - name: Файлы и бэкапы
    icon: fas fa-database
    items:
      - title: Nextcloud
        url: https://cloud.example.com
        statusCheck: true

Пакет иконок hl-* (Homelab icons) встроен и покрывает большинство популярных self-hosted приложений — Portainer, Grafana, Nginx Proxy Manager, Pi-hole и десятки других — без необходимости искать и хостить картинки самому. Для остального работают иконки Font Awesome (fas fa-...) или Material Design Icons (mdi-...), а также произвольный URL на PNG/SVG.

Статус-мониторинг: как Dashy проверяет доступность сервисов

Это ключевая функция, ради которой Dashy обычно и выбирают вместо статичного списка ссылок. Когда у карточки указано statusCheck: true, Dashy периодически делает HTTP-запрос по адресу сервиса и красит индикатор карточки: зелёный — 2xx/3xx ответ, жёлтый — ответ получен, но код неожиданный, красный — таймаут или ошибка соединения.

Тонкая настройка на уровне отдельного элемента:

items:
  - title: API-сервис
    url: https://api.example.com
    statusCheck: true
    statusCheckUrl: https://api.example.com/health
    statusCheckHeaders:
      Authorization: 'Bearer some-token'
    statusCheckAcceptCodes: '200,204'
    statusCheckAllowInsecure: false

Несколько практических моментов, на которые стоит обратить внимание сразу:

• statusCheckUrl отдельно от url — полезно, когда сама главная страница сервиса требует авторизации (и вернёт 302/401), а отдельный /health или /api/ping эндпоинт отвечает без логина. Проверяйте именно то, что реально показывает «сервис жив», а не редирект на форму входа.
• Проверки идут с браузера пользователя, а не с сервера, где крутится сам Dashy (если не включён режим CORS-прокси через переменную окружения CORS_PROXY или обратный вызов через nginx). Это значит, что для внутренних адресов (10.0.0.5:9000) статус-чек сработает только если у зашедшего в дашборд есть сетевой доступ к этому адресу — актуально при работе через VPN или в локальной сети.
• Глобальный интервал statusCheckInterval в appConfig задаётся в секундах и действует для всех карточек, если не переопределён на уровне конкретного item. Ставить меньше 30 секунд для десятков сервисов сразу — плохая идея: браузер будет заметно грузить сеть и сам сервис лишними пингами.
• Self-signed сертификаты на внутренних сервисах — частая причина ложных красных индикаторов. statusCheckAllowInsecure: true временно решает проблему, но правильнее закрыть внутренние сервисы за Traefik или Nginx Proxy Manager с нормальным сертификатом от Let's Encrypt.

Если нужен более серьёзный мониторинг с историей аптайма, алертами в Telegram и графиками времени отклика — Dashy для этого не предназначен, это разные задачи. Для истории и уведомлений подойдёт Uptime Kuma рядом с Dashy: Dashy показывает «жив прямо сейчас» на главном экране, Kuma — «сколько было простоя за месяц» с алертами.

Виджеты: погода, статистика Docker, RSS и кастомные API

Отдельно от sections с карточками-ссылками Dashy поддерживает виджеты — блоки, которые подтягивают и показывают живые данные, а не просто ведут по клику. Они добавляются в widgets внутри секции.

sections:
  - name: Мониторинг
    displayData:
      sortBy: default
    widgets:
      - type: weather
        options:
          apiKey: ваш_ключ_openweathermap
          city: Moscow
          units: metric

      - type: docker-stats
        options:
          hostname: localhost
          port: 2375

      - type: rss-feed
        options:
          rssUrl: https://example.com/feed.xml
          limit: 5

      - type: cron-job-monitor
        options:
          apiKey: ваш_ключ_cronjob_org

Виджет docker-stats показывает CPU, память и число запущенных контейнеров текущего хоста, но требует доступа к Docker API — либо через проброшенный /var/run/docker.sock (с осторожностью: это фактически root-доступ к хосту из контейнера), либо через отдельно поднятый docker-socket-proxy с ограниченными правами только на чтение статистики. Второй вариант безопаснее и рекомендуется, если Dashy смотрит наружу через reverse proxy.

Полный список виджетов (их около трёх десятков — прогноз погоды, курсы криптовалют, статус GitHub Actions, публичный IP, XKCD-комикс, системная информация хоста и другие) стоит смотреть в официальной документации проекта: набор регулярно пополняется, и фиксировать его здесь конкретным числом смысла нет — на момент написания статьи (конец августа 2026) актуальный список всегда доступен через ? в UI-редакторе конфига.

Reverse proxy, HTTPS и аутентификация

Публиковать Dashy напрямую по IP:порту без шифрования и авторизации не стоит — на дашборде обычно собраны ссылки на всю внутреннюю инфраструктуру, и это ценная цель для сканеров. Два рабочих варианта защиты.

Базовая аутентификация встроенными средствами Dashy — без reverse proxy, для быстрого старта:

appConfig:
  auth:
    users:
      - user: admin
        hash: '5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d'

Хэш — SHA-256 от пароля, его можно сгенерировать так:

echo -n "ваш_пароль" | sha256sum

Это защита уровня «отвадит случайного посетителя», не более: без HTTPS пароль и так уходит открытым текстом при первом входе, а Dashy не хранит сессии так, как это делают полноценные auth-провайдеры.

Reverse proxy с TLS и внешним провайдером аутентификации — правильный вариант для сервера, доступного из интернета. Компактный пример для Traefik (лейблы на сам сервис Dashy в том же docker-compose.yml):

  dashy:
    # ... остальная конфигурация как выше
    labels:
      - traefik.enable=true
      - traefik.http.routers.dashy.rule=Host(`dash.example.com`)
      - traefik.http.routers.dashy.entrypoints=websecure
      - traefik.http.routers.dashy.tls.certresolver=letsencrypt
      - traefik.http.services.dashy.loadbalancer.server.port=80

Дальше перед Dashy встаёт Authelia или Keycloak (Dashy умеет OIDC-аутентификацию нативно, если такая инфраструктура уже есть), либо просто basic auth на уровне самого Traefik/Nginx Proxy Manager — этого достаточно для панели, которая не хранит секретов сама по себе, а только ссылки и статусы.

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