Дорожная карта домашнего мини-ПК в 2026: что развернуть, в каком порядке, и зачем — план апгрейда от инфраструктурщика

Вместо вступления

Каждый месяц с карты списываются деньги за подписки. Spotify, Яндекс Плюс, Notion, Obsidian Sync, Google One — суммы небольшие по отдельности, в сумме набегает заметно. Параллельно с этим у меня работает VPS с несколькими проектами, на роутере крутится OpenWrt с AdGuard Home. Инфраструктурный опыт есть. Дома при этом — никакого сервера, всё в облаке.

Это начинает раздражать не только из-за денег. Сервисы меняют каталоги без предупреждения, поднимают цены, требуют доплат за объём, периодически ломают регионы. Контроль над собственными фотографиями, заметками и медиатекой постепенно перестал быть моим.

Решил спланировать переезд на свой мини-ПК. Пока разбирался с железом и стеком, обнаружил, что нормальной системной дорожной карты «бери и иди» в 2026 году нет. Есть каталоги «50 self-hosted сервисов», восторженные посты про конкретные приложения, треды на Reddit. Структурированного маршрута для нового человека — нет.

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

Честная позиция автора

Прежде чем нырять в технику — одно признание.

Мини-ПК у меня пока нет. На момент написания статьи он не куплен. Я не могу написать «я поставил, и вот результаты» — это была бы выдумка.

Зато есть:

• Production-опыт с Docker, Docker Compose, Caddy, Nginx, Tailscale на VPS

• Свой инфраструктурный проект OpenClaw на VPS

• AdGuard Home на домашнем роутере с OpenWrt — первая часть будущего стека

• Понимание, что именно из SaaS я хочу заменить и зачем

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

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

Кому это нужно, кому нет

Домашний сервер не для всех. Если вы платите 500 рублей в месяц за подписки и не задумываетесь — он не нужен. Если вам нравится экосистема Apple и устраивает iCloud — не нужен. Если не хотите ни одного дополнительного устройства в квартире — не нужен.

Своё железо имеет смысл, когда совпадают несколько условий:

• Платите за SaaS-подписки заметные деньги и уже посчитали сумму

• Важен контроль над собственными данными

• Есть базовое понимание Linux и Docker (или сильное желание разобраться)

• Готовы потратить пару выходных на первоначальную настройку

• Готовы изредка чинить, когда что-то ломается

Если хотя бы три пункта про вас — читайте дальше. Self-hosted — это инженерный hobby с практическим выходом, а не способ срочно сэкономить тысячу в месяц. Окупаемость есть, но если считать только её, проще оставить SaaS как есть.

Слой 0 — Железо

Самый дорогой и долгоживущий выбор. От него зависит всё остальное.

Что не беру и почему

Raspberry Pi 5 8GB. Изначально планировал именно его — комплект с корпусом и БП за 20 000 ₽ выглядит привлекательно. Но когда сел расписывать стек под задачи, стало понятно, что Pi 5 не подходит. Три причины.

Первая — транскодинг видео. Jellyfin часто транскодирует на лету: 4K-фильм на телефон требует пересжатия в 1080p в реальном времени. Pi 5 умеет H.264 на ускорителе, но H.265 (а большинство свежих файлов в нём) тащит слабо.

Вторая — ML-задачи Immich. Распознавание лиц, объектов, OCR — это GPU-нагрузка. На Pi 5 индексация архива в 50 тысяч фотографий займёт сутки и больше. На x86 с iGPU — несколько часов.

Третья — экосистема ARM в Docker. Часть образов под ARM либо отсутствует, либо собирается с ошибками, либо медленнее. Это постоянные мелкие грабли там, где на x86 их нет.

Pi 5 хорош для GPIO-проектов, сетевых задач без тяжёлой нагрузки, низкого энергопотребления с батареей. Для домашнего сервера с медиа и ML — это инженерная ошибка.

AMD-машины на Ryzen 7 7735HS / Ryzen 9 7940HS. На маркетплейсах находятся интересные конфиги: FIREBAT на 7735HS за 27 000 ₽, Machenike на 7940HS за 53 000 ₽. CPU-производительность отличная, но есть нюанс, который сильнее всего бьёт по домашнему медиа-серверу.

Документация Jellyfin прямым текстом: «AMD is not recommended due to poor quality H.264 and H.265 (HEVC) output, as well as being hard to set up the compute environment». Качество транскодирования через AMD VCN заметно хуже, и настройка VAAPI на AMD APU в Linux требует возни с драйверами и флагами. Работает, но с граблями.

Intel iGPU с QuickSync, для сравнения, документирован, поддерживается из коробки, в production уже больше десяти лет. Для Jellyfin/Immich на Linux — правильный выбор, даже если CPU-производительность ниже.

Б/у HP/Lenovo Tiny на i5-8500T. Корпоративная сборка, тихая, надёжная. Но я хочу новое железо с гарантией — это домой на годы, лишний риск с диагностикой б/у не нужен.

Что беру

Beelink Mini S13 (Intel N150 / 16 ГБ DDR4 / 512 ГБ NVMe) — 28 000 ₽.

Beelink Mini S13. Источник: ITPro review

Intel N150 — младший процессор Twin Lake (обновлённый Alder Lake-N), 4 ядра, 4 потока, базовый TDP 6 Вт, турбо до 3.6 ГГц. Не флагман, но критичная деталь — встроенный Intel iGPU с QuickSync. Этот класс iGPU способен на HEVC 10-bit транскодирование с тонмаппингом — достаточно для персонального использования с учётом ограничений по производительности и энергопотреблению.

Реальные тесты подтверждают, что Intel N100 в роли Jellyfin-сервера тянет три одновременных 4K-потока на NAS. N150 быстрее N100 на ~25%.

Что важно для развёртывания: по обзору ITPro, Beelink не предлагает версию без ОС, но Ubuntu 24.04 загружается с USB-флешки и работает идеально из коробки. Первое, что я сделаю — снесу Windows 11 Pro и поставлю Ubuntu Server.

Из коробки получаю: 16 ГБ DDR4, 512 ГБ NVMe, 2.5 GbE Ethernet, слот под второй M.2 SSD, idle 8 Вт, под нагрузкой до 25 Вт. За год работы 24/7 — около 70-100 кВт·ч, или 700-1000 ₽ электричества.

Что докупить

Накопитель для медиа — ADATA UE800 2TB (AELI-UE800-2T-CSG) — 24 000 ₽. Технически это USB-флешка с Type-C, не SSD в боксе. По характеристикам — NVMe-чип в металлическом корпусе со скоростями чтения и записи 1000 МБ/с (USB 3.2 Gen 2). По объёму 2 ТБ хватит на фотоархив, музыку и активную ротацию кино.

Альтернатива — внешний USB-HDD на 4 ТБ за 7-10 тысяч. Дешевле и больше объём, но шумит. Если ставить в гостиной — лучше SSD.

ИБП ExeGate 800ВА / 500Вт (EX295996RUS) — 8 000 ₽. Обязательная позиция. Мини-ПК не любят резких отключений питания, особенно когда внутри Postgres пишет в индексы (это случай Immich и Home Assistant). Один скачок напряжения может закончиться порчей базы. ИБП окупается одним предотвращённым случаем.

Zigbee USB-стик SONOFF Dongle-LMG21 — 3 000 ₽. Понадобится, когда дойду до умных розеток и ламп. Покупаю сразу, чтобы не заказывать отдельно.

Итоговый бюджет железа

Это нижняя адекватная планка домашнего сервера на годы. Можно дешевле — без ИБП, с одним диском, с китайской флешкой вместо ADATA, — но в каждом случае это компромисс по надёжности или производительности.

Архитектура: думаем слоями

Большинство гайдов «как поднять домашний сервер» начинаются с приложений: «давайте поставим Jellyfin». Это плохая ментальная модель. Если думать сервисами, через полгода получится хаос из десятка контейнеров без понятной структуры, открытых наружу портов и без бэкапов.

Правильный подход — думать слоями:

┌─────────────────────────────────────────────────┐
│  Слой 3: Прикладной — то, что используешь       │
│  Immich, Jellyfin, *arr-стек, Home Assistant…   │
├─────────────────────────────────────────────────┤
│  Слой 2: Сервисный — как приложения работают    │
│  Reverse proxy, доступ снаружи, бэкапы,         │
│  мониторинг, управление контейнерами            │
├─────────────────────────────────────────────────┤
│  Слой 1: Фундамент — на чём всё крутится        │
│  ОС, Docker, файловая система                   │
├─────────────────────────────────────────────────┤
│  Слой 0: Железо                                 │
│  Beelink, диски, ИБП, Zigbee-стик               │
└─────────────────────────────────────────────────┘

Каждый слой — фундамент для следующего. Если пропустить слой 2 (бэкапы, reverse proxy) и сразу прыгать на слой 3, через месяц обнаружится одна из двух проблем: либо диск умер и фотки потеряны, либо Jellyfin торчит наружу без HTTPS и его поломали.

Поэтому в слой 3 идём в последнюю очередь, когда всё ниже закрыто.

Слой 1 — Фундамент

Операционная система: Ubuntu Server 24.04 LTS

Дистрибутив, на котором гарантированно работает всё нужное и под который есть ответы на любой вопрос в гугле.

Альтернативы, которые рассматривал:

• Debian 12 — стабильнее Ubuntu, но новые ядра доезжают позже. Для свежего железа N150 это критично.

• Proxmox VE — гипервизор для VM и LXC. Отличный инструмент, но избыточен для одного физического хоста с Docker.

• Unraid / TrueNAS — заточены под массивы дисков, не под мини-ПК с одним SSD. И платные.

• Home Assistant OS — заточена под HA, но я хочу запускать не только HA. Поставлю HA в Docker.

Один важный момент: для нормальной работы iGPU N150 нужно HWE-ядро (Hardware Enablement). Стандартное ядро Ubuntu 24.04 не подхватывает аппаратное ускорение iGPU без него. HWE-ядро даёт более новые драйверы и поддержку свежего железа, что необходимо для VAAPI и QSV на N150. Решается одной командой:

sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

Без HWE Jellyfin будет транскодировать на CPU и упрётся в потолок. С HWE — заработает QuickSync через VAAPI.

Контейнеризация: Docker + Docker Compose

Стандарт де-факто для self-hosted. Каждый сервис — отдельный контейнер, описанный в docker-compose.yml. Никаких системных установок, никакого «а где этот пакет хранит конфиги». Вся конфигурация в файлах, всё легко поднимается заново.

Структура папок, к которой я приду:

/srv/
├── docker/
│   ├── caddy/
│   ├── immich/
│   ├── jellyfin/
│   ├── arr-stack/
│   ├── homeassistant/
│   └── ...
└── media/
    ├── photos/
    ├── downloads/
    └── library/
        ├── movies/
        └── tv/

Один сервис — одна папка с docker-compose.yml. Запуск — docker compose up -d, остановка — docker compose down, бэкап — копирование папки.

Reverse proxy: Caddy

У меня уже есть свой домен, и я возьму поддомен под домашний сервер — так получится нормальный TLS через Let’s Encrypt вместо самоподписанных сертификатов. Каждое приложение получает свой поддомен: immich.home.example.com, jellyfin.home.example.com, ha.home.example.com.

Из тройки Caddy / Traefik / Nginx Proxy Manager выбираю Caddy. Причины: он сам выпускает и обновляет сертификаты Let’s Encrypt без отдельной настройки, и его конфиг — это десять строк простого текста, а не YAML на 200 строк (Traefik) и не клики в веб-интерфейсе (NPM).

Минимальный Caddyfile:

immich.home.example.com {
    reverse_proxy localhost:2283
}

jellyfin.home.example.com {
    reverse_proxy localhost:8096
}

jellyseerr.home.example.com {
    reverse_proxy localhost:5055
}

ha.home.example.com {
    reverse_proxy localhost:8123
}

Caddy сам выпустит сертификат для каждого поддомена через DNS-challenge или HTTP-challenge.

Доступ снаружи: Tailscale

Эту тему я откладывал на подумать дольше всего, потому что у неё есть нюансы.

Tailscale — mesh-VPN на базе WireGuard. Клиент устанавливается на каждое устройство (телефон, ноутбук, мини-ПК), они видят друг друга по приватным IP-адресам в подсети 100.x.x.x, как будто все в одной локальной сети. Белый IP не нужен, проброс портов не нужен, динамический DNS не нужен. Работает за NAT, через CGNAT, на мобильном интернете.

Зачем это домашнему серверу: чтобы из кафе посмотреть фотки в Immich, проверить состояние Home Assistant, починить что-то по SSH. Без Tailscale это требует либо белого IP, либо проброса портов наружу (небезопасно), либо платных сервисов вроде Cloudflare Tunnel.

Отдельная фича — Tailscale Funnel — позволяет открыть один сервис в публичный интернет под доменом вида https://homeassistant.your-tailnet.ts.net. Tailscale выдаёт валидный TLS-сертификат, и сервис становится доступен с любого устройства, даже без установленного клиента Tailscale. Это нужно для одного конкретного случая — для интеграции Алисы с Home Assistant, потому что Яндекс должен достучаться до HA с серверов Яндекса, а Tailscale-клиент туда не поставишь.

Альтернатива — голый WireGuard на VPS. Работает, но настройка каждого нового устройства требует копипаста ключей и редактирования конфига. Tailscale делает то же самое за один клик в каждом приложении. На бесплатном тарифе — до 100 устройств на одного пользователя.

Управление контейнерами: Dockge

Когда сервисов станет десять, ходить в каждую папку и делать docker compose up -d — это не серьёзно. Нужен веб-интерфейс.

Из двух кандидатов — Portainer CE и Dockge — выбираю Dockge. Portainer постепенно становится платным продуктом, community-версия теряет фичи. Dockge делает только то, что нужно: показывает stack-и, позволяет редактировать compose-файлы прямо в браузере, перезапускать контейнеры. Open-source, без подписок, без растущей сложности.

Бэкапы: Restic + правило 3-2-1, всё локально

Бэкапы должны появиться в плане до того, как туда поедут 50 тысяч фотографий.

Правило 3-2-1: три копии, на двух разных носителях, одна — географически отдельно. Реализация без облака:

1. Копия 1 — оригинал на ADATA UE800, подключённой к Beelink

2. Копия 2 — локальная на отдельный USB-HDD на 4 ТБ, который подключаю раз в неделю и снимаю инкрементальный бэкап через Restic

3. Копия 3 — удалённая через Tailscale на машину у родителей или у друга, тоже через Restic

Restic шифрует на клиенте, делает дедупликацию и инкрементальные снапшоты. Удалённая машина видится по Tailscale-адресу как обычный SFTP-эндпоинт:

restic -r sftp:user@parents-server.tail-xxx.ts.net:/backup backup /srv/media

Один раз в месяц — тестовое восстановление файла. Без проверки бэкапов как бы нет.

Облачное хранилище (Backblaze B2, российские S3-совместимые) можно подключить позже, если будет нужно. Для старта хватит трёх локальных копий.

Мониторинг: Beszel

Не хочется превращать домашний сервер в Prometheus + Grafana — это overkill. Нужно простое: посмотреть температуру, нагрузку на CPU, память, диск, состояние контейнеров.

Beszel — лёгкий мониторинг с одним веб-интерфейсом, набирает популярность как замена Glances и Netdata. Один контейнер, один дашборд, всё что нужно.

Что должно быть готово на этом этапе

Это фундамент. Без него не имеет смысла ставить Immich, Jellyfin или что-либо ещё.

Слой 2 — Замены SaaS

Фотографии: Immich

Главная причина всего переезда. Архив фотографий семьи — это то, что нельзя терять и нельзя отдавать в чужой контроль. Google Photos однажды потребовал ещё денег за хранение, и стало ясно: на семейных фотках кто-то не должен иметь рычага.

Immich — open-source реплика Google Photos. На GitHub проект растёт быстрее всех в нише: 98K+ звёзд и продолжает набирать; это самый быстрорастущий self-hosted проект.

Интерфейс Immich. Источник: immich.app

Что умеет:

• Нативные мобильные приложения для iOS и Android с автоматическим бэкапом фоток с телефона

• Распознавание лиц через ML — у каждого человека отдельная страница со всеми его фото

• Распознавание объектов и сцен — поиск работает по «море», «закат», «торт», «собака»

• Поиск по местам на карте через геотеги

• Альбомы и общий доступ через ссылки

• Внешние библиотеки — можно подключить уже существующую папку без копирования

В сравнении с PhotoPrism (главный конкурент) Immich выигрывает в семейном сценарии. Immich — это true Google Photos replacement с автоматическим phone backup, нативными мобильными приложениями, отличным распознаванием лиц и полированным UI, который подойдёт всей семье. У PhotoPrism нет нативных мобильных приложений — только PWA через WebDAV.

Минимальные требования: 4 ГБ RAM, с ML-моделями ближе к 8. Beelink с 16 ГБ переваривает легко.

Технический момент: Immich использует Postgres с расширением pgvector для семантического поиска. Официальный docker-compose это уже учитывает, но если ставить руками — есть шанс наступить на грабли.

Видео: Jellyfin + полный *arr-стек

Здесь сразу важная оговорка. Jellyfin — это медиа-сервер, который красиво показывает то, что в него положили. Что положить — забота владельца сервера. У контента есть юридические нюансы, которые каждый решает сам и сообразно законам своей страны.

С этим оговоренным — про сам стек.

Большинство гайдов в интернете останавливаются на «поставьте Jellyfin». Этого мало. Полная автоматизированная медиа-система — это связка из шести-семи сервисов, которая из «нашёл фильм → скачал → переименовал → перенёс → обновил библиотеку → нашёл субтитры» делает «жена пишет в интерфейсе „хочу посмотреть Дюну в 4K“ и через час видит её в Jellyfin».

Архитектура

Пользователь → Jellyseerr (запрос)
                    ↓
              Sonarr / Radarr (поиск)
                    ↓
              Prowlarr (индексаторы)
                    ↓
              qBittorrent (скачивание через VPN)
                    ↓
              Bazarr (субтитры)
                    ↓
              Jellyfin (стриминг)

Компоненты по функциям

Jellyfin — сам медиа-сервер. Нативные клиенты под Android, iOS, Apple TV, Android TV, Roku, LG webOS, Samsung Tizen, KODI. Аппаратное транскодирование через QuickSync (для этого N150 и был выбран). Метаданные с TMDb / TVDb автоматически.

Jellyseerr — фронтенд для запросов «хочу посмотреть это». Интерфейс в стиле Netflix: ищешь фильм, выбираешь качество, жмёшь «запросить». В семье из двух человек удобно тем, что жене не надо разбираться с Sonarr/Radarr — она работает с одним красивым интерфейсом.

Radarr — менеджер фильмов. Отслеживает запросы, ищет торренты под нужное качество, отправляет на скачивание, переносит готовые файлы в библиотеку, переименовывает по правилам.

Sonarr — то же самое для сериалов, плюс отслеживает выход новых эпизодов.

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

qBittorrent — торрент-клиент. Получает магнет-ссылки от Sonarr/Radarr, качает, отдаёт обратно.

Bazarr — автоматический поиск субтитров под скачанные файлы. Подключается к OpenSubtitles, Subscene и другим источникам. Русские субтитры приезжают сами.

FlareSolverr — необязательный, но полезный сервис. Многие трекеры закрыты CloudFlare-челленджами; FlareSolverr автоматически их проходит. Без него часть индексаторов в Prowlarr будет регулярно отваливаться.

Gluetun — VPN-обёртка для qBittorrent в Docker-контейнере. Через него весь торрент-трафик идёт через VPN-провайдера (ProtonVPN, Mullvad, NordVPN). Если контейнер qBittorrent падает в случае разрыва VPN — это правильное поведение, никакой утечки реального IP.

Ключевая деталь — hardlinks и правильная файловая структура

Hardlinks позволяют файлам с разными именами и в разных папках указывать на один реальный файл. В медиа-стеке это критично: один файл одновременно лежит и в downloads (где qBittorrent его сидирует), и в library (где Jellyfin его показывает), не занимая места дважды.

Для работы hardlinks все папки (downloads и library) должны быть на одной файловой системе. Поэтому структура такая:

/srv/media/
├── downloads/
└── library/
    ├── movies/
    └── tv/

Если разнести их по разным дискам, hardlinks не сработают, и Radarr будет копировать файлы вместо переноса — расход места и времени удвоится.

Quality profiles через TRaSH Guides

Это секретный соус, без которого стек собирает фильмы как попало. Для лучших настроек качества используется TRaSH Guides с Recyclarr — инструментом, который синхронизирует community-проверенные quality profiles в Radarr и Sonarr автоматически. Без этого Radarr может скачать сжатый WEBRip 720p вместо 4K Remux, потому что «он первый попался».

Recyclarr — это контейнер, который раз в неделю обновляет quality profiles по открытым гайдам. Поставил один раз — настройки актуальны без ручной поддержки.

Транскодинг Jellyfin

Чтобы Jellyfin использовал QuickSync, в docker-compose прокидывается устройство /dev/dri:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "109"  # render group
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /srv/media/library:/media:ro
    network_mode: host
    restart: unless-stopped

В настройках Jellyfin: Playback → Transcoding → Hardware acceleration: Intel QuickSync (QSV), путь к устройству /dev/dri/renderD128.

После этого htop при стриминге 4K на телефон показывает 5-10% CPU вместо 100% — iGPU делает работу.

Что получается в итоге

Жена пишет в Jellyseerr: «хочу посмотреть Дюну: часть вторая в 4K». Дальше:

1. Jellyseerr передаёт запрос в Radarr с пометкой «4K Remux»

2. Radarr ищет лучший вариант через Prowlarr (по quality profile из TRaSH Guides)

3. Найденный торрент отправляется в qBittorrent через Gluetun (VPN включен)

4. qBittorrent скачивает файл в /srv/media/downloads

5. Radarr делает hardlink в /srv/media/library/movies/Dune Part Two (2024)/...

6. Bazarr автоматически подтягивает русские субтитры

7. Jellyfin индексирует файл, отправляет уведомление

8. Жена открывает Jellyfin на телевизоре, выбирает фильм, смотрит

Если телевизор подключён по Ethernet и поддерживает прямое воспроизведение — Jellyfin отдаёт файл напрямую без транскодинга, нагрузка на CPU 1-2%. Если на телефоне или в плохой сети — QuickSync пересжимает на лету.

Заметки и продуктивность: открытый вопрос

Здесь я не определился окончательно. Notion даёт единый интерфейс для документов, баз данных, задач — нормальной open-source альтернативы пока нет. AppFlowy, AnyType, AFFiNE приближаются, но не тянут.

Поэтому план промежуточный:

• Заметки → Obsidian (он уже у меня есть, локальные markdown-файлы)

• Синхронизация Obsidian-vault между устройствами → Syncthing (вместо платного Obsidian Sync)

• Notion — пока оставлю, поищу решение позже

Syncthing — peer-to-peer синхронизация файлов. Запускается контейнером на сервере, плюс приложение на каждом устройстве. Vault Obsidian становится «папкой для синхронизации», изменения с любого устройства разлетаются в реальном времени. Никаких облаков, никаких подписок.

Возможно, в будущем рассмотрю AppFlowy в self-hosted режиме как замену Notion для семейных задач. Но это отдельный шаг, не на старте.

AdGuard Home — это уже работает

Сетевая блокировка рекламы для всей квартиры. У меня уже стоит на роутере с OpenWrt — переносить никуда не надо. Все устройства в сети получают DNS, который режет рекламу до того, как она долетит до браузера или приложения.

Это, возможно, самая благодарная вещь во всём self-hosted: 30 минут настройки, и реклама в YouTube на телевизоре, в мобильных играх, в подозрительных приложениях исчезает.

Сводная таблица замен

Слой 3 — Умный дом

В квартире зоопарк из четырёх экосистем, который надо свести в одну:

• Roborock Q8 Pro Max — приложение Roborock

• Xiaomi-чайник и весы — приложение Mi Home

• LG F2V5HS5W — стиральная машина, приложение LG ThinQ

• Яндекс Станция Макс — Яндекс Дом

• В планах — умные розетки и свет (Zigbee)

Четыре приложения для управления одним домом — не умный дом, а бюрократия. Решение — Home Assistant как единая точка управления.

Дашборд Home Assistant. Источник: home-assistant.io

Home Assistant в Docker

Один compose-файл, веб-интерфейс на порту 8123, проксируется через Caddy на ha.home.example.com.

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    privileged: true
    network_mode: host
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0  # Zigbee USB-стик
    restart: unless-stopped

network_mode: host нужен, чтобы HA видел устройства в локальной сети через mDNS/SSDP — без этого половина интеграций не находит ничего.

Интеграции для имеющихся устройств

Roborock. Встроенная интеграция в HA с 2024 года. Работает через cloud-аккаунт Roborock. Для большинства задач этого хватает: показать статус, запустить уборку, отозвать на базу. Если хочется полностью локально — есть Valetudo, но это требует root и кастомной прошивки пылесоса. Для начала ограничусь cloud-интеграцией.

Xiaomi (Mi Home). Для чайника и весов — встроенная интеграция Xiaomi Miio через Xiaomi Cloud. Нужен токен, получается через приложение Mi Home. Часть устройств работает локально, часть — через облако.

LG ThinQ. Встроенная интеграция LG ThinQ появилась в Home Assistant 2024.11. Подключение через Personal Access Token (PAT), который генерируется в личном кабинете LG. Нужен интернет — интеграция работает через LG ThinQ Cloud. Стиральная машина появится как набор сенсоров (статус, режим, время до конца) и сервисов (запустить, остановить).

Яндекс Станция и Алиса. Самая интересная часть. Прямой интеграции от Яндекса нет — официального API не выпускают. Используются два community-проекта:

• AlexxIT/YandexStation — управление Станцией: отправлять голосовые сообщения, проигрывать треки, читать TTS, перехватывать команды

• dext0r/yandex_smart_home — пробрасывает устройства из HA в Алису, чтобы можно было сказать «Алиса, включи свет в гостиной»

Оба ставятся через HACS (Home Assistant Community Store) — менеджер пакетов для community-интеграций.

Главная техническая сложность: как Алиса достучится до HA

Это узловой нюанс всей конструкции, и он стоит отдельного разбора.

Проблема: dext0r/yandex_smart_home работает так — когда пользователь говорит «Алиса, включи лампу», Яндекс с своих серверов отправляет HTTP-запрос на Home Assistant. Серверам Яндекса нужно достучаться до HA из публичного интернета.

Без белого IP вариантов несколько:

1. Cloudflare Tunnel — бесплатно, но требует домен и аккаунт Cloudflare

2. Своя поддоменная запись с пробросом порта — у меня поддомен есть, но проброс порта на роутере — это открытый сервис в интернете, требующий внимания к безопасности

3. Tailscale Funnel — самый чистый вариант

Tailscale Funnel выдаёт публично доступный URL вида https://homeassistant.your-tailnet.ts.net с валидным TLS-сертификатом, без открытия портов на роутере. Серверы Яндекса видят этот URL, отправляют команды, HA получает и выполняет.

В Home Assistant Community App для Tailscale достаточно поставить флаг funnel: true, и сервис становится доступен снаружи.

Один важный момент безопасности: Tailscale Funnel открывает сервис полностью в публичный интернет. HA должен быть защищён сильным паролем и 2FA. Ничего другого через Funnel выставлять наружу не стоит.

Zigbee для розеток и света

Когда дойду до умных розеток и ламп — использую Zigbee, не Wi-Fi. Wi-Fi-устройства быстро забивают роутер и зависят от облаков производителя (которые могут отключиться). Zigbee — локальный протокол, устройства общаются через mesh-сеть с координатором.

Координатор — Sonoff Dongle-LMG21. Софт — Zigbee2MQTT в Docker. Любое Zigbee-устройство (Aqara, IKEA Tradfri, Xiaomi, Sonoff) подключается к Z2M, дальше через MQTT-брокер (Mosquitto) попадает в Home Assistant.

Эта связка даёт независимость от облаков и приложений: купил Aqara-розетку, прицепил к Z2M, она появилась в HA, HA её показывает Алисе через dext0r — всё работает локально. Если завтра Aqara закроет своё облако — система продолжит работать.

Что осознанно НЕ ставлю

Самый редкий раздел в статьях про self-hosted, и потому самый полезный. Все хвастаются тем, что поставили. Честный список того, что сознательно не делаю:

Свой почтовый сервер. SMTP в 2026 году — это битва с DKIM, DMARC, SPF, репутацией IP, прогревом, спам-листами, FBL, MX-warming. Один день настройки превращается в постоянную поддержку. Gmail, Yahoo, Outlook будут резать письма как спам годами. Это полная вселенная, которая требует выделенного человека.

Свой VPN-сервер для обхода блокировок. Отдельная статья про VLESS+Reality на роутере у меня уже была. Домашний сервер для этого не нужен, и смешивать обходные технологии с self-hosted на одном железе — плохая идея с точки зрения изоляции рисков.

Kubernetes / k3s. Для одного хоста — инженерное излишество. Docker Compose решает 100% задач, k8s добавляет 1000% сложности. Когда серверов станет три-пять, имеет смысл вернуться к вопросу. Сейчас — нет.

Nextcloud. Хорошая программа, но монструозная и тяжёлая. Для синхронизации Obsidian мне хватит Syncthing, для фото — Immich, для шаринга файлов с друзьями — отдельный лёгкий инструмент типа PicoShare. Nextcloud — перебор.

Свой Bitwarden / Vaultwarden. Не из-за качества — Vaultwarden отличный. Но менеджер паролей — критичная инфраструктура для семьи, и я не хочу, чтобы он жил на одном сервере с домашним зоопарком, где идут эксперименты. Использую облачный сервис.

Музыкальный сервер (Navidrome). Думал про замену Spotify через Navidrome — но там есть фундаментальная проблема. Свой сервер играет только ту музыку, которая у тебя есть. Поддерживать актуальную коллекцию из новинок и пополнять её — это отдельный регулярный труд, и при наличии Яндекс Плюса в подписке это нерационально.

Итоговый бюджет и ROI

Стоимость владения

Разовые затраты:

Регулярные затраты:

Что перестану платить

Часть подписок не отменю сразу — Notion остаётся под вопросом, музыкальный сервис, скорее всего, оставлю в Яндекс Плюсе. Реалистичная экономия — 30-40 тысяч в год.

Срок окупаемости

В оптимистичном сценарии (полная замена всех SaaS): 63 000 / (55 400 - 1 000) ≈ 1.16 года

В реалистичном сценарии (замена только фото и видео): 63 000 / (35 000 - 1 000) ≈ 1.85 года

Через 1.5-2 года железо окупает себя в чистых деньгах. После этого — экономит около 30-40 тысяч в год.

Денежная окупаемость — не главная причина. Главная — контроль над собственными данными, отсутствие зависимости «сервис закроется / уйдёт из РФ / поднимет цену в три раза», и удовлетворение от того, что инфраструктура своя.

План перехода: 6 шагов на 6 выходных

Самая частая ошибка новичка — пытаться сделать всё сразу. Получается каша. План постепенный.

Выходные 1 — Слой 0 + 1 (фундамент). Покупка железа. Снос Windows, установка Ubuntu Server 24.04 с HWE. SSH, базовая безопасность, fail2ban. Docker + Compose. Tailscale, добавление телефона и ноутбука в tailnet. Настройка Caddy с поддоменами и Let’s Encrypt. Установка Dockge.

Выходные 2 — Бэкапы и мониторинг. Restic-репозиторий локально и удалённо (через Tailscale на машину родителей или друга). Скрипт автоматического бэкапа по cron. Тестовое восстановление файла. Beszel для мониторинга. Алерты в Telegram-бот при проблемах с диском или CPU.

Выходные 3 — Immich. Docker Compose с pgvector. Загрузка фотоархива (можно в фоне на неделю). Установка Immich-приложений на телефоны, настройка автобэкапа с телефона. Перенос на сервер, выключение Google Photos.

Выходные 4 — Полный медиа-стек. Jellyfin с прокидыванием /dev/dri для QuickSync. Sonarr, Radarr, Prowlarr, qBittorrent через Gluetun, Bazarr, FlareSolverr, Jellyseerr — единым docker-compose. Recyclarr для quality profiles из TRaSH Guides. Установка клиентов на телевизор и телефоны. Тест 4K-стриминга.

Выходные 5 — Home Assistant и 4 экосистемы. HA в Docker, HACS поверх. Интеграции: Roborock, Xiaomi, LG ThinQ. AlexxIT/YandexStation + dext0r/yandex_smart_home. Tailscale Funnel для доступа Алисы. Настройка первых сценариев («Алиса, начни уборку»).

Выходные 6 — Заметки и полировка. Syncthing для Obsidian-vault. Документация в Obsidian: что где лежит, как восстанавливать, какие пароли. Финальная проверка всего стека.

Если что-то затянется — не страшно. План — скелет, не догма. Главное — не пытаться сделать всё за один уикенд.

Что не сделал и почему

Честный финал — список того, что осталось за рамками этого плана.

Замена Notion. Оставил под вопросом. Ни AppFlowy, ни AnyType, ни AFFiNE пока не дотягивают до уровня Notion для моих задач. Возможно, разберусь с этим позже отдельной статьёй.

Family-friendly UI. Жена должна уметь сама зайти в Immich, найти фотки, что-то посмотреть в Jellyfin без обращения ко мне с вопросами. Над интерфейсом для нетехничных пользователей буду работать после развёртывания — это отдельная задача.

Бэкапы фото к родителям. Идея — у мамы тоже стоит мини-сервер, и наши фотоархивы зеркалятся через Tailscale. Это даёт географическую распределённость без облака. Но требует ещё одного железа и совместного администрирования — не на старте.

Мониторинг сертификатов и health-чеки. Caddy сам обновляет, но иногда что-то ломается. Нужен бот, который пишет в Telegram, если что-то пошло не так. Уровень оптимизации, до которого пока не дошёл.

Что дальше

Это план на ближайшие два-три месяца. Когда я его реализую и накоплю реальный опыт — напишу часть вторую: что сработало как ожидал, что пошло не так, какие нюансы вылезли в production. Возможно, обнаружу, что какой-то выбор был неверным — это нормально, открою и расскажу.

Если у вас есть свой опыт со self-hosted — пишите в комментариях, что упустил, что бы вы сделали иначе и где меня ждут грабли. Я планирую этот сервер на годы и буду благодарен за подсказки от тех, кто уже прошёл этот путь.

Один общий совет тем, кто сейчас задумывается: не покупайте железо, пока не написали свой план. Я сам чуть не взял Pi 5, потому что «все берут». Хорошо, что сел и расписал стек — стало понятно, что это была бы ошибка.

Полное описание следующих шагов, конфигов и грабель — в части второй после реальной эксплуатации. Спасибо, что дочитали.