Домашний сервер в гостиной за $300 на старом ThinkPad T460s

Как старый ThinkPad T460s со сломанным тачпадом стал домашним сервером для Telegram-ботов, музыки, аудиокниг, торрентов, NFS-хранилища и приватного доступа.

Ноутбук, подключённый к телевизору и работающий как хомлаб

Возле моего телевизора стоит старый ThinkPad T460s. Он подключён к док-станции, к нему висят два USB-диска, на нём крутится Archcraft, и он уже давно перестал ощущаться как ноутбук. Это медиабокс, загрузочная машина, хост для Telegram-ботов, точка входа в приватную сеть и иногда площадка для экспериментов.

Я не собирался строить хомлаб. У меня просто был ноутбук, который всё ещё был полезен, но неудобен как обычный ноутбук.

Примерно в 2019 году я купил его у бывшего работодателя за $300. Это был ThinkPad T460s: обычная рабочая машинка, уже не новая даже тогда. Позже у неё сломался тачпад. Наверное, его можно заменить, но для старого ноутбука, который не уезжает дальше тумбы под телевизором, мне просто не хочется этим заниматься. Позже мне захотелось попробовать Archcraft, скорее из любопытства. Я поставил систему, понравился минимальный i3-сетап, подключил ноутбук к телевизору через HDMI, воткнул USB-клавиатуру, подключил док-станцию и оставил его там.

Временный эксперимент постепенно превратился в машину, которая держит домашние медиа, Telegram-ботов, приватный доступ в сеть и всю скучную обвязку вокруг этого. Сетап рос постепенно, по одной маленькой бытовой проблеме за раз.

Домашний сервер или хомлаб?

Честный ответ: и то и другое, но центр тяжести всё-таки ближе к домашнему серверу.

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

Это хомлаб, потому что на нём всё ещё есть эксперименты. Я меняю способ деплоя сервисов, пробую идеи с приватной сетью, переношу вещи между Docker и systemd, сравниваю медиапроцессы и иногда что-то ломаю, пока понимаю, какой должна быть следующая версия.

Это различие полезно, потому что задаёт нормальные ожидания. Это не лаборатория из одноразовых тестовых узлов и не production-сервер с формальными SLA. Это полезный домашний сервер, в котором всё ещё есть место для экспериментов.

Машина

Железо обычное, и именно поэтому мне нравится этот сетап. Он показывает, что хомлаб не обязан начинаться со стойки, серверной платы и списка покупок.

ThinkPad T460s, который используется как домашний сервер в гостиной
ThinkPad T460s в нынешней роли: корпус старого ноутбука, работа домашнего сервера, стоит на верхней полке моего книжного шкафа.
МашинаThinkPad T460sстарый ноутбук со сломанным тачпадом, теперь подключённый к док-станции
CPUIntel Core i5-6200U2.30 GHz, 2 ядра, 4 потока
Память20 ГБ DDR4хватает на контейнеры, кеш и десктопную сессию
Внутренний SSD238 ГБArchcraft, Docker-данные, загрузки, кеш
Диск бэкапов~600 ГБвнешний HDD для резервных копий
Медиадиск3.6 ТБвнешний NTFS HDD, смонтирован в /mnt/EHDDSG-4
ОСArchcraftбаза Arch Linux с i3wm

По текущему состоянию всё ещё комфортно: корневая файловая система занята примерно на 72%, медиадиск на 3.6 ТБ — примерно на 64%, а средняя нагрузка обычно низкая, если ничего не качается и не транскодируется. Swap тоже есть, но большую часть времени полезная память уходит в файловый кеш.

Физически это не изящно: ноутбук возле телевизора, подключённый к док-станции, а от неё уже тянутся два USB-диска, HDMI, Ethernet и питание. Сломанный тачпад перестал иметь значение, потому что это уже не ноутбук в обычном смысле. Это маленький сервер со встроенным экраном, батареей, клавиатурой и аварийной консолью.

Док-станция делает этот комок проводов терпимым. Ethernet, HDMI, USB-диски, клавиатура и питание сходятся в одном месте, поэтому ноутбук можно снять или обслужить без того, чтобы заново собирать всю кабельную схему в гостиной.

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

Как это собрано

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

Схема домашнего сервера в гостиной: Telegram управляет tg-mpv-bot на ThinkPad, mpv выводит картинку на телевизор, NFS открывает медиадиск, а nginx отдаёт приватные .lab сервисы.
Один ноутбук работает как сервер, устройство воспроизведения, файловый шлюз и входная точка для приватных сервисов.

Главная деталь: ThinkPad одновременно сервер и устройство воспроизведения. Он не стримит видео на клиент в Smart TV. Он запускает mpv локально на машине, которая уже подключена к телевизору. Путь медиа получается коротким, а Telegram-бот ощущается как настоящий пульт, а не как веб-приложение, притворяющееся пультом.

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

Как я им управляю

Поскольку машина живёт в гостиной, я не отношусь к ней как к полностью хедлесс-серверу. Основной способ управления — x2x: он расшаривает клавиатуру и мышь с моего основного ноутбука в X11-сессию Archcraft по SSH. Увожу курсор за край экрана ноутбука — и он появляется на телевизоре.

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

Для консольной работы хватает обычного SSH. Для редких случаев, когда нужна полная удалённая десктопная сессия, есть xrdp, но это не ежедневный путь.

Хранилище: простой полезный NAS

Схема хранения намеренно скучная:

  • Внутренний SSD: система, состояние контейнеров, временные загрузки, кеш.
  • Маленький внешний HDD: цель для бэкапов.
  • Большой внешний HDD: медиатека с video/, music/, books/, audiobooks/ и podcasts/.

Большой диск расшарен по NFSv4 на мой NixOS-ноутбук в локальной сети. Раньше я использовал Samba, но она слишком часто превращала мелкие вопросы совместимости в отдельные задачи. Для Linux-to-Linux шаринга NFS оказался проще и спокойнее.

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

RAID тут нет, и я не делаю вид, что это storage appliance. Важным данным нужны бэкапы. Заменяемым медиа нужна организация. Для этой машины такой компромисс достаточен.

Диск для бэкапов нужен для того, что действительно жалко потерять: конфиги, небольшие проектные данные, метаданные и выбранные личные файлы. Большая медиатека живёт по другому правилу. Что-то будет неприятно восстанавливать, но не всё заслуживает защиты уровня enterprise. Для этой машины граница такая: сначала защищать незаменимое, заменяемое медиа держать в порядке и не делать вид, что старый ноутбук с USB-дисками — полноценный NAS appliance.

SSD тоже намеренно используется как рабочая зона, а не как долгосрочный архив. Docker-состояние, незавершённые торренты, кеши и временные загрузки могут крутиться там, не трогая постоянно медиатеку. Готовые файлы переезжают на большой диск только после того, как я решил, что им там место.

Сервисы

Большинство сервисов стоит за nginx с короткими .lab-именами внутри приватного меша. В итоге это ощущается не как куча портов, а как маленькая локальная платформа: music.lab, torrents.lab и похожие имена работают с моих устройств без публикации сервисов в интернет.

Сервисы делятся на три группы:

  • Ежедневные: tg-mpv-bot, Navidrome, Deluge, nginx, NFS, приватный доступ.
  • Периодические: Audiobookshelf, tg-media-bot, tg-streaming-bot, IPTV, радио.
  • Почти на пенсии: Plex и GitLab. Оба полезные как идеи, но уже не настолько важны, чтобы быть центральной частью сетапа.

Telegram-боты

Боты — самая личная часть сетапа, потому что они связывают телевизор, Telegram и медиатеку в один рабочий поток.

  • tg-mpv-bot управляет mpv на телевизоре из Telegram. Можно просматривать файлы, отправить YouTube-ссылку, переслать видео и запустить его на экране без прямого взаимодействия с машиной. Он работает как пользовательский systemd-сервис, потому что ему нужен доступ к X11-сессии и IPC-сокету mpv.
  • tg-media-bot скачивает медиа через yt-dlp и отправляет файлы обратно в Telegram. Работает в Docker вместе с локальным Telegram Bot API сервером, чтобы большие файлы были практичны.
  • tg-streaming-bot занимается музыкальными и видеостримами для групповых звонков Telegram. Он менее центральный, чем mpv-бот, но полезен, когда цель не телевизор, а голосовой чат.

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

Обычный вечер может выглядеть так: переслал видео боту, нашёл что-то на YouTube из Telegram или открыл просканированные медиапапки и сказал mpv запустить файл на телевизоре. Важно не то, что Telegram — идеальный медиаинтерфейс. Важно, что команды всегда в кармане, живут в той же истории чата и не требуют открывать отдельное приложение только ради старта воспроизведения.

Музыка: Navidrome

Navidrome индексирует папку с музыкой на большом диске и отдаёт её через Subsonic API. На телефоне я использую Tempo, а внутри меша сервис доступен как music.lab.

Важная деталь: музыкальная коллекция остаётся обычными файлами на диске. Navidrome — это индекс и слой воспроизведения, а не владелец библиотеки. Если я позже заменю сервис, сама коллекция останется понятной.

Plex, почти на пенсии

Plex тоже установлен, и раньше я пользовался им заметно активнее. Сейчас открываю редко: большую часть видео я запускаю через tg-mpv-bot. Отправил файл или ссылку в Telegram, mpv воспроизвёл это на телевизоре, а медиатека осталась обычными папками без необходимости жить внутри отдельного media-center интерфейса.

Plex всё ещё лучше как отполированный медиакаталог. У него красивые миниатюры, постеры, matching, описания, актёры, сезоны и вся дополнительная метаинформация, из-за которой библиотека ощущается как стриминговое приложение.

Telegram-бот выигрывает в управлении и скорости действия. /mpv_scan может просканировать медиапапки и сгенерировать плейлисты для всей библиотеки, так что категории и навигация из Telegram всё равно есть. Но воспроизведение остаётся простым: mpv играет напрямую на машине, подключённой к телевизору. Обычно это значит без серверного транскодинга, без переговоров о совместимости клиента и без внезапного скачка CPU из-за того, что формат субтитров или кодек заставил Plex конвертировать поток. Тот же бот умеет вещи, для которых Plex не очень подходит: случайные ссылки, пересланные Telegram-файлы, YouTube-поиск, интернет-радио через /mpv_radio и live TV через /mpv_iptv. Plex лучше, когда нужен богатый каталог. Бот лучше, когда Telegram уже открыт и нужно просто запустить что-то на телевизоре.

Аудиокниги: Audiobookshelf

Для аудиокниг используется Audiobookshelf. Его compose-файл монтирует /mnt/EHDDSG-4/data/audiobooks как библиотеку аудиокниг и /mnt/EHDDSG-4/data/podcasts как библиотеку подкастов, а конфиг и метаданные лежат рядом с compose-проектом в ~/docker/audiobookshelf.

Это лучше, чем просто отдавать директории. Аудиокнигам нужны прогресс, главы, метаданные, авторы, серии и нормальный интерфейс на телефоне. Обычные файлы хороши для хранения; Audiobookshelf делает их удобными для прослушивания.

Торренты: Deluge

Deluge работает в Docker, веб-интерфейс живёт на torrents.lab. Контейнер пишет загрузки в ~/Downloads/torrents-deluge, а незавершённые загрузки отделены от готовых.

Мне нравится это разделение: torrent-клиенту не нужен доступ на запись ко всей медиатеке. У него есть посадочная зона. Я сам решаю, что переезжает в библиотеку и куда именно.

GitLab, остановлен

GitLab на машине есть, но сейчас остановлен. Для одного человека он тяжёлый, а публичные проекты и так нормально живут на GitHub. Если мне снова понадобится локальный forge, я выберу что-то легче.

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

Что поменялось по дороге

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

Первой была Samba. Она работала, пока не переставала, и ломалась скучно: диалекты SMB, поведение клиентов, мелкие вопросы совместимости. Поскольку мои основные клиенты — Linux-машины, переход на NFSv4 сделал историю с хранилищем проще.

Вторым был Plex. Я всё ещё уважаю его как каталог, но для моих привычек у телевизора это стало лишней церемонией. Telegram-бот лучше совпал с тем, как я на самом деле взаимодействую с медиа: отправить, найти, продолжить, запустить на телевизоре.

Третьим был GitLab. Это мощная штука, но для одного пользователя на домашнем сервере она оказалась слишком тяжёлой относительно пользы. Остановить его — не провал, а нормальное обслуживание.

Приватный доступ

Удалённый доступ построен вокруг Tailscale-совместимого меша с self-hosted headscale control plane на польском VPS. У хомлаба стабильный адрес в меше, и он анонсирует домашнюю LAN-подсеть, так что я могу достучаться до домашних устройств вне дома без публикации случайных портов на роутере.

Исходящий доступ при необходимости идёт через AmneziaVPN. Это важно, потому что Telegram и связанная инфраструктура из России могут вести себя нестабильно в зависимости от маршрута. Ботам важнее стабильный исходящий доступ, чем публичный входящий.

Практический результат простой: телефон достаёт сервисы по приватным именам, боты достают внешний мир, а nginx остаётся единой входной точкой для локальных веб-приложений. Путь к этому — заблокированные DPI хендшейки, DERP-релей, который молча работал только дома, и телефон, способный держать лишь один VPN одновременно — отдельная история, рассказанная в «Доступ к домашнему серверу отовсюду».

AI как слой терпения

Честная причина, почему сетап вырос так далеко: я часто использую AI-инструменты при настройке.

Раньше у меня часто не хватало терпения долго возиться с каждым конфигом, systemd unit, Docker compose файлом, правилом nginx и странным Linux edge case. Я мог это делать, но трение заставляло остановиться раньше. С AI можно попросить первый черновик, сравнить его с реальной машиной, поправить неверные предположения и продолжить.

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

Как это выглядит каждый день

Обычно машина скучная, и это хорошо. На момент написания она работает без перезагрузки 10 дней; это нормальный интервал между обновлениями ядра. Пользовательские сервисы и контейнеры поднимаются после ребута сами, поэтому перезагрузка не превращается в проект.

CPU старый, но редко напрягается. Вентилятор не живёт на максимальных оборотах. Настоящий центр тяжести — медиадиск; ноутбук в основном даёт вычисления, сеть и обвязку вокруг него.

Интересным сетап делает не мощность, а то, как маленькие части складываются:

  • Telegram становится пультом для телевизора и входящим ящиком для загрузок.
  • NFS делает медиадиск почти локальным на основном ноутбуке.
  • Navidrome даёт музыкальной коллекции нормальный мобильный интерфейс.
  • Audiobookshelf превращает папки с длинными аудиофайлами в библиотеку.
  • Приватный меш делает всё доступным без публичной экспозиции.

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

Что я хочу изменить

Проблемная часть — не железо. Проблемная часть — накопленное состояние системы.

Archcraft приятен, но со временем машина обросла вещами, которые существуют просто потому, что я однажды их поставил и пошёл дальше. Часть сервисов — это Docker compose проекты, один важный бот — пользовательский сервис, у nginx своя локальная история, mount points настроены руками.

Поэтому я хочу перевести её на NixOS.

На NixOS машину можно восстановить из flake, а не из памяти. Сервисы, mount points, пользователи, firewall rules, пакеты и пользовательские unit-файлы можно выразить кодом. Если обновление что-то ломает, есть предыдущие поколения и rollback, а не археология.

План — не трогать медиадиск. Данные важнее системы, и они должны пережить смену ОС без изменений. Миграция — это замена установки на SSD, декларативное описание текущих сервисов и переход от состояния “так сложилось на машине” к состоянию “так написано в репозитории”.

Ещё я бы хотел сделать физический сетап менее неловким. Док-станция помогает, но два внешних диска, HDMI, Ethernet и питание всё равно превращаются в небольшой кабельный клубок возле телевизора. Более аккуратный корпус для дисков или нормальная полка, вероятно, улучшили бы сетап сильнее, чем более быстрый CPU.

Тачпад не в приоритете. Он сломан, и его, наверное, можно заменить, но этой машине уже не нужно вести себя как переносному ноутбуку. Для такой роли важнее рабочие клавиатура, экран, док, Ethernet и хранилище.

Чему я научился

Этот хомлаб начался потому, что у меня был неудобный ноутбук и свободный HDMI порт. Это до сих пор лучшая часть истории.

Специализированное железо было бы аккуратнее. Настоящий NAS был бы безопаснее. Стойка лучше смотрелась бы в статье. Но ничего из этого не было обязательным, чтобы получить полезные домашние сервисы.

Реальные выводы меньше и практичнее:

  • Старые бизнес-ноутбуки хорошо подходят на роль домашних серверов: в них уже есть экран, клавиатура, батарея, Wi-Fi, Ethernet через док и достаточно CPU для скучных сервисов.
  • Прямое воспроизведение лучше лишней сложности медиасервера, когда та же машина уже подключена к телевизору.
  • Обычные папки недооценены. Красивые библиотеки приятны, но файлы должны оставаться понятными и без приложения.
  • Сервисы должны оправдывать потребление RAM. Если что-то тяжёлое и редко используется, оно не обязано постоянно работать.
  • Хомлаб не обязан быть впечатляющим, чтобы быть полезным. Ему достаточно решать реальные задачи и оставлять место для экспериментов.

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

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