Homepage или Homarr: что выгоднее и когда

MAATRIX

Оба закрывают одну и ту же боль — десяток сервисов на разных портах, которые надоело держать в закладках браузера. Но за одинаковой картинкой «карточки со ссылками» скрываются два разных подхода: один живёт в YAML-файлах и git, второй — в базе данных и веб-редакторе с мышкой. Разница ощущается не в первый день, а через месяц, когда дашборд обрастает сервисами и его нужно кому-то передать или перенести на новый сервер. Разберём, где выгоднее какой вариант — без маркетинга, с конкретными командами и честными ограничениями обоих.

Коротко: кому что подходит

Если сократить сравнение до одного вопроса, он звучит так: кто будет редактировать дашборд и как часто.

• Homepage — для одного администратора, который не против держать конфиг в текстовом редакторе и коммитить его в git вместе с остальной инфраструктурой. Взамен — минимальный вес, отсутствие базы данных и файлов, которые могут «протухнуть» после сбойного обновления.
• Homarr — для случаев, когда дашбордом пользуется больше одного человека, борд меняется часто (добавили сервис — сразу перетащили карточку), или нужны отдельные логины для разных пользователей. Взамен — своя база SQLite, обязательный ключ шифрования и чуть больше ресурсов на старте.

Оба — read-only агрегаторы в смысле управления инфраструктурой: ни тот, ни другой не заменяет Portainer или Traefik, они только показывают статус и дают быстрый переход. Разница именно в том, как меняется сама витрина — правкой файла или перетаскиванием плитки.

Установка: сколько времени и что нужно

Оба поднимаются одним docker-compose.yml и одной командой, но стартовые требования отличаются.

Homepage не просит вообще ничего сверх образа — при первом запуске он сам создаёт дефолтные YAML-файлы в примонтированном каталоге:

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:v1.4.0
    container_name: homepage
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./homepage-config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - HOMEPAGE_ALLOWED_HOSTS=dashboard.example.com,203.0.113.10:3000

mkdir -p homepage-config
docker compose up -d

Дашборд открывается на порту 3000 сразу же, редактировать пустые карточки — отдельным шагом.

Homarr требует одного обязательного действия до старта — сгенерировать ключ шифрования, которым база подписывает сохранённые токены интеграций. Без него контейнер не поднимется:

mkdir -p /opt/homarr/{data,configs,icons}
cd /opt/homarr
openssl rand -hex 32   # это и есть SECRET_ENCRYPTION_KEY

services:
  homarr:
    image: ghcr.io/homarr-labs/homarr:latest
    container_name: homarr
    restart: unless-stopped
    ports:
      - "7575:7575"
    environment:
      - SECRET_ENCRYPTION_KEY=${HOMARR_SECRET_KEY}
    volumes:
      - ./data:/appdata
      - ./configs:/app/data/configs
      - ./icons:/app/public/icons
      - /var/run/docker.sock:/var/run/docker.sock:ro

Забытый или слишком короткий ключ — самая частая причина, по которой контейнер Homarr падает сразу после старта. После успешного старта Homarr сразу предлагает создать администратора — это отдельная встроенная система пользователей, к системным аккаунтам сервера отношения не имеющая.

По времени разница небольшая — обе панели поднимаются за несколько минут, если docker-compose уже готов. Разница не во времени первого запуска, а в том, что происходит дальше.

Редактирование: YAML в git против мышки в браузере

Здесь и проходит главная граница между проектами.

Homepage хранит всё в YAML-файлах внутри homepage-config: settings.yaml для общего вида, services.yaml для карточек, bookmarks.yaml для простых ссылок без виджетов. Любое изменение — правка текста:

- Инфраструктура:
    - Portainer:
        href: https://portainer.example.com
        icon: portainer.png
        widget:
          type: portainer
          url: http://portainer:9000
          env: 1
          key: ptr_your-api-key

Файлы перечитываются на лету при обращении к странице — перезапускать контейнер не нужно, достаточно обновить вкладку. Плюс подхода: весь дашборд можно держать в git рядом с остальной инфраструктурой как код, диффы видны, откат — обычный git revert. Минус: коллеге без доступа к серверу или без желания разбираться в YAML показать карточку некому — только словами объяснить, что добавить.

Homarr редактируется прямо в интерфейсе — иконка карандаша открывает режим редактирования борда, дальше «Add item» → «App», указываете URL и иконку (поиск по библиотеке dashboard-icons подсказывает готовый SVG без загрузки файлов), плитку растягиваете по сетке. Всё сохраняется в SQLite-базу сразу, без редактора текста и без доступа к серверу. Структура — борд → секции → плитки, секции сворачиваются, что удобно при большом количестве сервисов.

Плата за удобство — состояние живёт в базе, а не в читаемых файлах: диффов в git не будет, перенос борда между площадками — это перенос volume целиком, а не пары YAML-строк. Если по борду работает не только администратор сервера — Homarr выигрывает без вопросов; если дашборд — личный инструмент одного человека, который и так живёт в терминале, YAML Homepage будет быстрее для регулярных мелких правок.

Виджеты и интеграции — сравнительная таблица

Обе панели умеют показывать живые данные с других сервисов на карточке, но реализовано это по-разному.

Заметная разница практична: Docker-виджет Homarr не просто показывает статус, а даёт кнопки управления контейнером прямо с борда — для Homepage это исключено принципиально, он read-only по архитектуре. Обеим панелям для статуса и управления контейнерами нужен доступ к docker.sock, а это отдельный разговор о безопасности (ниже).

Автообнаружение через лейблы — сильная сторона именно Homepage: сервис размечается лейблами homepage.* прямо в своём docker-compose.yml, и карточка появляется без синхронизации конфигов между стеками. У Homarr акцент сделан на скорость ручного добавления через интерфейс.

Память, база данных и рост со временем

Сама разница «файл против базы» превращается в разницу по ресурсам, и здесь важно не путать пиковую и стартовую нагрузку.

Homepage без базы данных — это, по сути, Next.js-рендер YAML-файлов почти без состояния. На сервере с парой других лёгких контейнеров он не создаёт заметной дополнительной нагрузки, узкое место — не сама панель, а сервисы, которые она опрашивает виджетами.

Homarr держит SQLite-базу с бордами, пользователями и зашифрованными токенами интеграций. На 1 vCPU / 1 ГБ RAM панель работает нормально вместе с парой соседних контейнеров, но если бордов много, пользователей несколько и активно используется Docker-виджет (он периодически опрашивает сокет), разумно закладывать от 2 ГБ RAM на сервер целиком. Точные цифры зависят от числа виджетов с внешними интеграциями — каждый это периодический запрос к чужому API, — так что ориентируйтесь на эти числа как на стартовую точку, а не гарантированный лимит.

Рост со временем у Homepage практически нулевой — YAML-файлы не растут сами по себе, разве что вы вручную добавляете карточки. У Homarr база растёт медленно (борды и настройки — это килобайты, не гигабайты), но при переходе на мажорную версию у проекта уже случались миграции схемы БД — откатиться назад без бэкапа data будет нельзя. Для обеих панелей бэкап сводится к копированию каталогов с состоянием — подробные процедуры расписаны в статьях про бэкап Homepage и про бэкап Homarr.

Безопасность и публикация наружу

Дашборд агрегирует ссылки и статусы всей инфраструктуры — по сути, карта сервера для того, кто до неё доберётся. Публиковать порт 3000 или 7575 напрямую в интернет не стоит ни для одной из панелей.

Общий риск для обеих — монтирование /var/run/docker.sock. Контейнер с доступом к сокету фактически получает root-доступ к хосту: через сокет можно поднять новый контейнер с примонтированным /, что эквивалентно полному доступу к файловой системе. Для личного сервера с закрытым доступом извне это обычно приемлемый компромисс, но если сокет не нужен — уберите строку монтирования: Homepage потеряет автообнаружение и виджет статуса контейнеров, Homarr — Docker-виджет с кнопками управления, остальной функционал сохранится. Принципы безопасной работы с сокетом (в частности, socket-прокси с ограниченным набором прав вместо прямого монтирования) — в статье про безопасность Docker.

Разница — во встроенной аутентификации. У Homepage её нет вовсе: любой, кто дотянется до порта, видит весь дашборд без пароля, защита — только на уровне reverse proxy (Basic Auth или Authelia). У Homarr своя система пользователей с логином и паролем есть из коробки, но это не повод открывать порт в интернет напрямую — админка со своими токенами интеграций должна ходить только по HTTPS.

Правильный путь для обеих панелей — спрятать порт за reverse proxy и не публиковать его наружу вовсе. Если на сервере уже поднят Traefik, лейблы добавляются прямо в сервис дашборда:

labels:
  traefik.enable: "true"
  traefik.http.routers.dashboard.rule: Host(`dashboard.example.com`)
  traefik.http.routers.dashboard.entrypoints: websecure
  traefik.http.routers.dashboard.tls.certresolver: letsencrypt

Как поднять сам Traefik с автоматическим TLS — подробно в статье «Traefik как reverse proxy для Docker»; для Homepage поверх Traefik стоит добавить ещё и Basic Auth middleware, поскольку встроенной защиты у панели нет вообще.

С точки зрения сервера обе панели — лёгкие приложения: 1 vCPU, 1–2 ГБ RAM и системный диск на 20 ГБ закрывают и Homepage, и Homarr с запасом, даже если рядом крутится десяток других контейнеров, которые они отображают. Ставить дашборд на отдельный сервер не нужно — он логично живёт рядом с инфраструктурой, которую показывает, и на Ubuntu 24.04 LTS обе панели ставятся по одинаковой схеме.

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