У каждого инженера рано или поздно появляется мысль: хочется иметь свой Netflix, свой Google Фото, своё файловое хранилище и отдельную площадку для экспериментов. Не арендованную, не ограниченную тарифами и не завязанную на чужие продуктовые решения, а полностью контролируемую инфраструктуру.
У меня эта история началась ещё в 2007 году, когда под столом появился первый сервер из старого системного блока и набора найденного железа. Но эта статья не про историю и эволюцию домашнего сервера. Об этом можно написать отдельно.
Сейчас сервер — это рабочая инфраструктура для медиа, фотографий, файлов, резервного копирования, мониторинга, CI/CD, личных проектов и игровых серверов. Основная система — Debian 12 Bookworm. Большинство сервисов запущено в Docker-контейнерах. Снаружи стоят фаервол, honeypot и reverse proxy.
Зачем вообще нужен домашний сервер
Домашний сервер имеет смысл не потому, что это дешевле любого облака. Иногда дешевле, иногда нет. Главная ценность в другом: контроль над данными, отсутствие искусственных ограничений, независимость от подписок и возможность быстро поднимать сервисы под свои задачи.
Это не замена всем облакам. Важные резервные копии всё равно должны уходить за пределы дома. Но как основная площадка для личной инфраструктуры домашний сервер закрывает очень широкий набор задач.
Jellyfin: личный медиасервер
Jellyfin — главный потребитель ресурсов на сервере. Через него я смотрю фильмы, сериалы и слушаю музыку. Важная функция — аппаратная транскодировка. Она позволяет смотреть медиатеку с разных устройств дома и за пределами домашней сети, даже если устройство не поддерживает исходный формат файла или не тянет высокий битрейт.
Основные альтернативы — Plex и Emby.
Plex удобен, зрелый и хорошо отполирован с точки зрения клиентских приложений. Но для моего сценария у него есть принципиальный минус: часть важных возможностей завязана на Plex Pass. В частности, аппаратное ускорение транскодинга относится к платным возможностям. Для домашнего сервера, где я сознательно ухожу от подписок, это плохая модель.
Emby ближе к Jellyfin по духу и тоже хорошо подходит для домашнего медиасервера. Но у Emby также есть коммерческая составляющая, а аппаратное транскодирование относится к возможностям Emby Premiere. В результате получается промежуточный вариант: вроде бы self-hosted, но не полностью свободный по набору функций.
Поэтому я выбрал Jellyfin. Он open source, не требует подписки, не прячет ключевые возможности за платным тарифом и даёт мне то, что нужно: собственную медиатеку, доступ с разных устройств и аппаратную транскодировку.
Immich: замена Google Фото
Immich закрывает задачу личной фотогалереи. Это автоматическая загрузка фото и видео с телефонов, удобный просмотр, распознавание лиц, поиск, работа с метаданными и хранение без сжатия. Сейчас в нём хранится около 35 000 фотографий.
Главная альтернатива — PhotoPrism. Я пользовался им раньше, и это сильный проект: он хорошо индексирует фотографии, умеет работать с большим архивом и подходит для self-hosted-сценария. Но в моём случае Immich оказался лучше по пользовательскому опыту. У него приятнее интерфейс, стабильнее работает мобильная синхронизация, а приложение активно развивается и регулярно обновляется.
Ещё один вариант — использовать Nextcloud Photos. Но для меня это скорее дополнительная возможность файлового облака, а не полноценная замена Google Фото. Nextcloud хорош как файловая платформа, но для фотографий я предпочитаю специализированный инструмент.
Поэтому для фотоархива я выбрал Immich. Здесь решающим фактором стала не только функциональность, но и ежедневное удобство: открыл приложение, фото загрузились, поиск работает, интерфейс не мешает.
Nextcloud: файловое хранилище и обмен файлами
Nextcloud — базовый сервис для домашнего сервера. Это файловое хранилище, доступ через домен, синхронизация, web-интерфейс и удобный способ расшаривать файлы без ограничений внешних сервисов.
Альтернативы есть: Seafile, Syncthing, обычный WebDAV, SFTP или минималистичная связка из файлового сервера и reverse proxy. Но у каждой из них другая зона ответственности.
Seafile хорош как быстрый файловый синхронизатор, но он менее универсален. Syncthing отлично подходит для синхронизации между устройствами, но не заменяет полноценное файловое облако с web-интерфейсом и ссылками для внешнего доступа. SFTP и WebDAV просты и надёжны, но требуют больше ручной работы и хуже подходят для обычного пользовательского сценария.
Nextcloud я использую именно как универсальную точку доступа к файлам. Когда нужно быстро открыть документ, отправить ссылку, загрузить файл с телефона или получить доступ из браузера — это удобнее, чем собирать несколько отдельных инструментов.
RustDesk: удалённый доступ под своим контролем
RustDesk — это self-hosted-альтернатива TeamViewer и AnyDesk. Для меня здесь важен не только бесплатный доступ, но и контроль над инфраструктурой удалённого подключения.
TeamViewer и AnyDesk удобны, но это внешние сервисы с собственными правилами, ограничениями и коммерческими моделями. Для разовой помощи они подходят, но держать постоянный удалённый доступ через чужую инфраструктуру мне не хочется.
RustDesk позволяет поднять собственный сервер и не отдавать критичный сценарий внешнему провайдеру. Это логично вписывается в общую модель домашнего сервера: если сервис касается доступа к моим устройствам, я хочу понимать, где он работает и через что проходит соединение.
Grafana и InfluxDB: мониторинг
Grafana и InfluxDB используются для мониторинга системных ресурсов и состояния RAID. Да, они живут на том же сервере, который мониторят. С инженерной точки зрения это не идеальная схема: если сервер полностью ляжет, мониторинг тоже исчезнет.
Но даже такая схема лучше, чем отсутствие мониторинга. Графики по CPU, памяти, дискам, температуре и состоянию RAID позволяют увидеть деградацию до того, как она станет критичной. Алерты дают шанс среагировать заранее.
Альтернативы — Prometheus, VictoriaMetrics, Zabbix, Netdata. Для домашнего сервера можно выбрать любой стек, но Grafana остаётся удобным интерфейсом для наблюдения. InfluxDB в моём сценарии достаточно хорошо закрывает хранение временных рядов и не требует избыточной сложности.
GitLab и GitHub runners: сборки без очередей
На сервере живут GitLab и GitHub runners для автоматических сборок моих проектов. Это не обязательно для каждого домашнего сервера, но для разработчика такой сценарий очень полезен.
Публичные бесплатные раннеры удобны, пока их хватает. Но когда хочется быстрее собирать свои проекты, не ждать свободного окружения и не упираться в лимиты, собственный runner становится нормальным решением.
Альтернативы — Forgejo, Gitea, Woodpecker CI, Drone CI или полностью облачные CI/CD-сервисы. Но мне удобно иметь совместимость с GitLab и GitHub, поэтому собственные runners хорошо дополняют текущий workflow.
Игровые серверы
Minecraft, Unreal Tournament 99 и Quake III Arena живут на том же домашнем сервере. Это отдельная категория удовольствия: можно играть с нужными настройками, не искать публичные серверы, не зависеть от случайных людей и спокойно ставить любые моды.
Альтернативы простые: арендовать игровой хостинг, поднять сервер на VPS или играть на публичных серверах. Но если дома уже есть машина с ресурсами и нормальным каналом, держать свои игровые серверы вполне естественно.
Syncthing: синхронизация без центрального облака
Syncthing я использую для синхронизации отдельных директорий и Obsidian между устройствами и сервером. Это не файловое облако в стиле Nextcloud, а децентрализованная синхронизация. Устройства синхронизируются напрямую, а сервер становится одним из постоянных узлов.
Альтернативы — Nextcloud Desktop Client, Resilio Sync, rsync, git-репозиторий для текстовых заметок. Но Syncthing удобен тем, что работает непрерывно, не требует центрального облачного провайдера и хорошо подходит для сценария «папка должна быть одинаковой на нескольких устройствах».
Схема у меня такая: устройства синхронизируют выбранные директории на сервер, а уже с сервера эти данные уходят в централизованный backup.
Резервное копирование: rsync, WebDAV и GPG
Для резервного копирования используются rsync, WebDAV, rclone и шифрование через GPG. Часть данных уходит в облако. За облако уже приходится платить, но это нормальная плата за повышение надёжности.
Домашний сервер не должен быть единственной точкой хранения. RAID не заменяет backup, а backup на том же сервере не защищает от пожара, кражи, ошибки администратора или полного отказа железа.
Backup у меня разделён на два контура. Первый — локальный системный backup: по расписанию systemd timer запускает отдельный backup-пайплайн, который собирает важные системные и пользовательские директории через rsync, сохраняет права, владельцев, ACL и extended attributes, формирует manifest со списком файлов, упаковывает результат в tar.zst, шифрует архив через GPG с AES256 и считает sha256 для проверки целостности. Готовый backup-набор атомарно переносится в отдельную директорию локального хранилища, а старые наборы удаляются по retention policy. Чтобы процесс не мешал обычной работе сервера, backup запускается с пониженным CPU и I/O приоритетом.
Второй контур отвечает за вынос данных за пределы сервера. Через cron запускаются rclone-задачи, которые синхронизируют фотоархив, системные backup artifacts и отдельную архивную директорию в удалённое хранилище по WebDAV/S3-совместимому интерфейсу. По умолчанию используется rclone sync, то есть удалённая сторона приводится к состоянию локальной; для первичной загрузки предусмотрен режим копирования без удаления. После выполнения задачи пишутся логи и отправляется уведомление в Telegram. Такая схема даёт понятное разделение ответственности: локальный контур создаёт проверяемый и зашифрованный artifact, а внешний контур регулярно выносит его за пределы домашнего сервера.
Альтернативы — BorgBackup, Restic, Duplicati, Kopia, облачные snapshot-решения. Я использую более простую и понятную связку, потому что она прозрачна: понятно, что копируется, куда копируется и чем шифруется.
Личные сайты, проекты и MVP
Часть сайтов тоже хостится на домашнем сервере. Личные проекты и MVP сначала поднимаются здесь же. Если проект вырастает, получает пользователей или начинает требовать отдельной надёжности, он переезжает на VDS.
Домашний сервер в этом смысле работает как внутренний production-like полигон. Можно быстро поднять сервис, проверить идею, настроить reverse proxy, домен, SSL, CI/CD и мониторинг. Для разработчика это практичнее, чем держать все эксперименты только на локальной машине.
Железо
Сейчас всё это работает на следующей конфигурации:
- Intel Core i5-11400;
- 32 GB DDR4;
- 4 + 4 TB HDD WD Red в software RAID 1 на mdadm — основное хранилище;
- SSD 256 GB под операционную систему и домашние директории пользователей;
- SSD 128 GB под кэши и временные файлы;
- HDD 2 TB под редкие раздачи для проекта «Хранители» RuTracker.
Это не серверное железо в классическом смысле. Но для домашней инфраструктуры такой конфигурации достаточно: медиасервер, фотогалерея, файловое облако, мониторинг, runners и несколько дополнительных сервисов работают параллельно без ощущения, что система постоянно находится на пределе.
Почему AI-агентов я туда пока не пускаю
AI-агентов напрямую на этот сервер я пока не запускал. Не потому, что это невозможно, а потому что не хочется нарушать уже сложившуюся идиллию.
Домашний сервер — это не просто песочница. На нём лежат фотографии, файлы, бэкапы, доступы, сайты и сервисы, которыми я действительно пользуюсь. Поэтому любые автоматические агенты с доступом к инфраструктуре должны появляться там только после нормальной изоляции, ограничений прав и понятной модели безопасности.
Отдельный кейс с AI, который за одну ночь помог воскресить сервер, у меня уже есть. Но это история для отдельной статьи.
Итог
Раньше над домашними серверами часто смеялись: зачем он нужен, если всё уже есть в облаке. Фото — в Google, фильмы — в стримингах, файлы — в облачных дисках, сборки — в hosted CI, удалённый доступ — через внешние сервисы.
Но со временем вопрос изменился. Теперь домашний сервер — это не только про экономию. Это про контроль, независимость, инженерную практику и возможность строить свою инфраструктуру так, как удобно тебе.
И самое интересное: люди, которые раньше спрашивали «зачем тебе это нужно», теперь всё чаще спрашивают, как собрать себе такой же сервер и какие сервисы поставить первыми.