Что это вообще такое и зачем оно нужно?
Самохостинг (или Self Hosted) — это практика размещения и управления своими веб-сервисами (сайтами, репозиториями, системами мониторинга и т.д.) на собственном оборудовании — например, на домашнем сервере или мини-ПК, — вместо того чтобы арендовать хостинг у сторонних компаний.
На практике это означает: вы берёте свой старый мини-ПК, ставите туда Linux, Docker и пару контейнеров — и он превращается в полноценный сервер. В этой статье я расскажу, как реализовал самохостинг на двух мини‑ПК с AliExpress. А если хотите следить за моими экспериментами и получать оперативные обновления — подписывайтесь на мой Telegram‑канал: @kotelnikoff_dev На Хабре уже есть отличная обзорная статья про базовый self-hosting — ? Self-Hosted для домашнего сервера
А я хочу рассказать, как я реализовал это на двух мини-ПК с AliExpress и что из этого вышло.
В материале:
разбор плюсов и минусов самохостинга;
сравнение с облачными решениями (VPS);
пошаговая инструкция по установке и настройке сервера на Ubuntu;
варианты организации доступа (DMZ, VPN, OpenWrt);
расчёт затрат и оценка окупаемости;
реальный кейс перехода с VPS на самохостинг.
Статья будет полезна разработчикам, DevOps‑инженерам и энтузиастам, которые хотят:
сэкономить на хостинге;
получить полный контроль над инфраструктурой;
развернуть внутренние сервисы без ограничений облачных платформ.
Вы получите не только теоретические знания, но и конкретные инструкции — от выбора оборудования до базовых мер безопасности.
За и против
Плюсы
Полное владение инфраструктурой: никто не отключит ваш аккаунт и не повысит тариф.
Отсутствие подписок и лимитов: нет ограничений по ресурсам.
Гибкость настройки: вы строите инфраструктуру под свои нужды — например, разворачиваете GitLab, Sentry, SonarQube и другие инструменты.
Минусы
Полная ответственность за обслуживание: если что‑то сломается, ремонтировать придётся самостоятельно.
Зависимость от домашнего интернета: провайдеры не гарантируют аптайм, необходимый для продакшена.
Вопросы безопасности: один незащищённый порт может сделать систему доступной для посторонних.
Ограничения провайдера: при высоком входящем трафике вас могут попросить перейти на коммерческий тариф.
Отсутствие резервирования: выход из строя оборудования приведёт к простоям до его замены.
Когда самохостинг оправдан
Самохостинг идеален для разработки, тестирования и внутренних инструментов — сервисов, которыми пользуетесь вы и ваша команда, даже если они доступны из интернета.
Примеры подходящих сценариев:
GitLab — хранение репозиториев, задач и пайплайнов без ограничений.
Sentry — сбор ошибок и логов.
SonarQube — анализ качества кода и покрытия тестами.
CI/CD — собственные конвейеры сборки и деплоя (без лимитов GitHub Actions).
Prometheus/Grafana — мониторинг инфраструктуры и эксперименты с DevOps‑настройками.
Docker Registry или Harbor — хранение контейнеров и образов для проектов.
Такие сервисы могут быть доступны извне (например, через HTTPS и Traefik), но их ключевая особенность — это внутренняя инфраструктура, а не клиентские продукты.
Почему не стоит использовать домашний сервер для продакшена
Домашний сервер не должен становиться «мини‑датацентром» для клиентских сайтов или платёжных сервисов. Причины:
нестабильность домашнего интернета;
отсутствие SLA (соглашения об уровне обслуживания);
риски безопасности;
возможные ограничения со стороны провайдера;
отсутствие резервирования данных и оборудования.
Кому подойдёт самохостинг
Этот подход особенно полезен:
командам, работающим с крупными файлами или играми (где GitHub и GitLab накладывают ограничения на размер репозитория);
тем, кто хочет развернуть собственные CI/CD‑пайплайны без лимитов по времени и ресурсам;
разработчикам с множеством проектов, желающим подключить Sentry, мониторинг и тестирование без зависимости от сторонних сервисов.
VPS против своего сервера
Критерий |
VPS |
Собственный сервер |
Доступность |
Работает 24/7 в дата-центре |
Зависит от дома и интернета |
Цена |
ежемесячные платежи. очень дорогая стоимость гигабайта хранения |
Разовая покупка |
Контроль |
Ограниченный |
Полный |
Безопасность |
Защищён дата-центром |
Ответственность полностью на вас |
Обслуживание |
Все заботы на провайдере |
Всё на тебе |
Варианты реализации: как организовать доступ к серверу из интернета
Варианты реализации: как организовать доступ к серверу из интернета
Существует три основных подхода — от простого к продвинутому.
1. DMZ и проброс портов
Суть: прямой доступ через роутер.
Что нужно:
статический IP от провайдера или DDNS (при динамическом IP);
настройка DMZ‑зоны или проброса портов (80, 443) на роутере.
Плюсы:
простота реализации;
минимум дополнительных сервисов.
Минусы:
сервер виден извне — повышенные требования к безопасности.
Для кого: новички, тесты, личные проекты.
2. VPN через VPS
Суть: сервер доступен извне, но без открытых портов.
Как работает:
между домашним сервером и VPS с белым IP поднимается VPN (обычно WireGuard);
VPS становится точкой входа: трафик по VPN идёт в домашнюю сеть.
Плюсы:
высокий уровень безопасности;
не требуется настройка роутера.
Минусы:
нужны расходы на VPS.
Для кого: пользователи за CGNAT/серым IP, те, кто ценит безопасность.
3. OpenWrt на роутере
Суть: гибкая маршрутизация и сегментация сети.
Возможности:
создание VLAN;
Policy‑based routing;
VPN‑туннели;
объединение подсетей (сервер, NAS, умный дом).
Плюсы:
полный контроль над сетью;
высокая кастомизация.
Минусы:
требует глубоких знаний сетевых настроек;
время на конфигурацию.
Для кого: продвинутые пользователи, энтузиасты DevOps.
ВАЖНО!
Многие VPN-протоколы (в частности WireGuard и OpenVPN) периодически блокируются Роскомнадзором или ограничиваются провайдерами.
Как выбрать подходящий вариант
Белый IP и стандартный роутер → DMZ/проброс портов.
CGNAT или серый IP → VPN через VPS.
Нужно единое сетевое пространство → OpenWrt + маршрутизация.
Максимальная безопасность → VPN через VPS или OpenWrt + VLAN.
Минимум вложений → DMZ с DDNS.
Хотите прокачать навыки → OpenWrt + VPN + DMZ.
Важные меры безопасности
При открытии сервера наружу немедленно примите следующие меры:
Закройте лишние порты (оставьте только 80 и 443).
Настройте SSH: только по ключу, на нестандартном порту.
Установите фаервол (UFW, iptables) и fail2ban.
Используйте HTTPS (Let’s Encrypt, Traefik).
Не храните ценные данные в корне DMZ.
Помните: DMZ — не защита, а изолированный сегмент. Безопасность обеспечивается настройками и обновлениями.
Простой алгоритм выбора
Начните с DMZ и DDNS — чтобы понять принцип работы.
Для постоянной эксплуатации выберите VPN через VPS — это надёжнее.
Если хотите углубиться в сетевые технологии — пробуйте OpenWrt и комплексную маршрутизацию.
Как реализовать на практике: пошаговая инструкция для Ubuntu
1. Подготовка установочного носителя
Скачайте Ubuntu Server с официального сайта (предпочтительно последнюю LTS‑версию).
-
Создайте загрузочную флешку:
в Windows — используйте Rufus;
в macOS/Linux — balenaEtcher.
Запишите ISO‑образ на флешку.
2. Установка системы
Загрузите устройство с установочной флешки.
-
В процессе установки:
включите SSH‑доступ (рекомендуется сразу настроить аутентификацию по ключам);
задайте статический IP‑адрес (или зарезервируйте его в настройках роутера);
установите hostname (уникальное имя сервера);
активируйте автоматические обновления пакетов.
По завершении установки перезагрузите систему.
3. Настройка SSH‑доступа (безопасность первым делом)
Сгенерируйте SSH‑ключ на своём компьютере:
ssh-keygen -t ed25519 -C "you@example.com"
Скопируйте публичный ключ на сервер:
ssh-copy-id user@server_ip
Отключите парольную аутентификацию в
/etc/ssh/sshd_config:
PasswordAuthentication no
Перезапустите SSH‑сервис:
sudo systemctl restart ssh
4. Базовая оптимизация оборудования
-
В BIOS/UEFI:
активируйте режим максимальной производительности (CPU Performance / Disable Energy Saver);
отключите энергосберегающие функции, если они мешают стабильной работе.
-
Установите утилиты для мониторинга:
sensorsиhtop— контроль температуры и загрузки CPU;smartmontools— мониторинг состояния дисков.
Проверьте температуру компонентов после загрузки:
sensors
Оцените загрузку системы:
htop
5. Установка дополнительного ПО (по необходимости)
Для развёртывания сервисов установите нужные пакеты через apt или snap:
Docker:
sudo snap install dockerPrometheus:
sudo apt install prometheusLXD:
sudo snap install lxd
Примечание:
Используйте
snapдля быстрого развёртывания (подходит для новичков).Для продвинутой настройки предпочтителен
aptс ручным конфигурированием.Перед установкой проверьте актуальные инструкции на официальных сайтах проектов.
Экономика самохостинга: краткий расчёт
При старте потребуются разовые затраты на оборудование (от 10 000 до 55 000 ₽ — в зависимости от выбора железа, роутера и накопителей). Ежемесячные расходы складываются из электроэнергии (около 188 ₽/мес за мини‑ПК мощностью 36 Вт), домашнего интернета (500–1 000 ₽/мес) и, при необходимости, VPS для VPN (300–800 ₽/мес). В сумме — от 988 до 1 988 ₽/мес. Для сравнения: аренда сопоставимого облачного сервера обойдётся в 15 000 ₽/мес. Таким образом, самохостинг окупается уже в первый год (экономия — от 131 000 ₽/год) при условии постоянного использования и наличия базовых навыков администрирования.
Как у меня всё получилось: реальный опыт
Изначально я использовал два VPS: один под GitLab (4 380 ₽/мес), второй под Sentry (3 630 ₽/мес). В сумме — около 8 010 ₽/мес, или 90 120 ₽/год. Эта цифра и стала стимулом для перехода на самохостинг.
На AliExpress я приобрёл два мини‑ПК за 12 000 ₽. Однако экономия тут же столкнулась с реальностью:
Первый мини‑ПК оказался с конструктивным изъяном: охлаждение и питание были объединены в один модуль, а контроллер вентилятора не работал. В результате устройство постоянно троттлило, нагреваясь до 84 °C (возможно, и выше). Пришлось его менять, на другую машинку
Второй мини‑ПК был почти идеален, но потребовал минимального вмешательства — смазки вентилятора.
Вывод: даже недорогое железо нуждается в обслуживании. Самохостинг экономит деньги, но требует времени и внимания к деталям — от мониторинга температур до профилактики механических узлов.
Комментарии (18)

LeshaRB
30.10.2025 11:29А что за мини ПК , тоже выбираю. Присматриваюсь

Kotelnikovekb Автор
30.10.2025 11:29OUMAX MAX N95 и у него проблемы с перегревом. И блок питания встроенный. Но можно добавить планку ОЗУ.
SOYO Efficient M4 Pro Мини. в него лезет только маленькие ссд. он хорошо работает

S-trace
30.10.2025 11:29Aoostar WTR PRO на Ryzen 7 5825U неплохие, как основа для NAS/мини-сервера имхо сейчас лучший вариант по цене/производительности. Поместится 2 (если очень надо - 3, но третий будет ограничен одной линией PCI-Express 3.0) M.2 SSD 2280 и 4 диска 3.5" (2х Exos 20ТБ точно нормально помещаются).
По цифрам и бенчмаркам миники на N100/150 сильно уступают (производительность ядер у них хуже, самих ядер меньше, слот RAM и M.2 слот всего один).
Только если захочется XPEnology - придётся вспомнить, что драйвера amdgpu там нет и аппаратное транскодирование заведётся только если поставить PVE, в нём поднять контейнер с Jellyfin (который будет юзать драйвер amdgpu от PVE) и VMку с XPEnology.
Но это если медиасервер нужен, для любых других задач недостатков у вариата на Ryzen имхо нет. Конечно, неплохо бы ECC-память и hot-swappable дисковую корзину, но это уже другой уровень.

S-trace
30.10.2025 11:29Добавлю, возможность установить 2 полноскоростных M.2 SSD позволяет пробросить их в VMку с NASом и поднять на них NVME read/write кэш (для него нужны 2 SSD в RAID1, с одним можно только read-only кэш поднять (если RW-кэш умрёт - будут потеряны все данные, в том числе и те что на HDD)), а третий SSD можно сделать системным для PVE. Или обойтись хорошей USB3 флешкой, но они не так надёжны. 4 слота для SATA HDD/SSD дают запас слотов для безопасной миграции на другие диски (не разбивая зеркало) или расширения ёмкости.
PVE же удобен тем, что для него есть много готовых скриптов (Proxmox VE Helper-Scripts) которые автоматически разворачивают контейнеры и VMки с приложениями которые вы выберите (тот же Jellyfin к примеру), это очень удобно для самохостинга.
Только декоративную крышку на дисковую корзину лучше не устанавливать на WTR PRO - она мешает охлаждению дисков, перекрывает воздуху путь.
Ещё, вроде как 5825u позволяет установить 64GiB RAM, а n150 - 32. Хотя по спекам вдвое меньше у обоих, так что это не точно.

andy2000
30.10.2025 11:29Тоже долго выбирал. Буквально месяц назад взял Firebat am02 на ryzen 5 6600h, 16 ddr5, ssd nvme 512 за 17к рублей на озоне. Поставил proxmox. В сеть смотрит только одна виртуалка. В общем доволен, планирую воткнуть вторую планку оперативы и второй ссд. Долго рассматривал вариант с n150, но разница в цене мизерная, а в производительности прилично проиграл бы.

sten65
30.10.2025 11:29доброго всем!
сам использую самохостинг. в первую очередь для тестирования - нет никакого желания проводить эксперименты на рабочей системе заказчика, да и развёртывание с нуля у клиента занимает намного меньше времени, когда процесс протестирован.
плюс ко всему собственный helpdesk, remote management тоже своё.
vps - использовал бы при необходимости, но упирается в интернет - один провайдер с ограничением по скорости :(
по железу: на входе openwrt на роутере, за роутером пара квазисерверов от 16+ потоками, 64+ ram, уже на них развёрнута виртуализация, ну и пара-тройка миников для тестирования пользовательских ос на реальном железе.

mureevms
30.10.2025 11:29Self Hosted - это самостоятельное размещение в противовес покупки сервиса (SaaS), при этом разместить можно и в облаке, а не обязательно на своем железе.

Pest85
30.10.2025 11:29Нет.
Self-hosting is the practice of hosting and managing applications on your own server(s) instead of consuming from SaaSS providers
Цитата с одного из крупнейших и популярнейших репозиторий для self hosting
https://github.com/awesome-selfhosted/awesome-selfhosted

NutsUnderline
30.10.2025 11:29(Мой) провайдер тупо закрывает ан вход порт 443 (и наверное 80) что делает неудобным что то публичное плюс сертификаты придется получать нестандартными способами

Kotelnikovekb Автор
30.10.2025 11:29Да, есть такая проблема, что некоторые операторы по умолчанию закрывают входящие 80 и 443 порты. А можно уточнить, кто у вас оператор?
У некоторых (особенно региональных или мобильных) блокируются не только HTTP/HTTPS, но и VPN-трафик — в том числе WireGuard и OpenVPN.

babysas
30.10.2025 11:29Сервисы тунелинга не подойдут?
localhost.run напиимер, этот крайне прост. позволяет любой порт магины по ssh пробросить на внешний домен и порт 80 по умолчанию. бесплатно работает час - достаточно для тестов, потом нужно перезапустить. на платном можно и домен свой прикрутить.
аналогов масса - легко гугляться. есть с очень разнообразными настройками и тариыными планами.

Zeus42
30.10.2025 11:29Пока читал заметил что в начале информация повторяется. Например рассмотр плюсов и минусов и в разделе "кому подойдёт" - та же информация только другими словами. И такое же второе место немного раньше.
В целом не плохой обзор, но упустили ещё один вариант настройки доступа, а именно через туннель Cloudflare. Когда ставил свой сервер столкнулся с этим и когда искал способ наткнулся на этот вариант. Бесплатного пакета хватает для нужд домашнего сервера и в этом варианте затраты будут только на домен и интернет (который и так оплачивается).
Минус такого подхода это сам туннель. Для файлообменника, просмотра видео и подобного скорости может не хватить и придется настраивать все корректно или переходить на платные планы. Также будут проблемы с приложениями которые используют специфические протоколы и порты, как Minecraft.
К плюсам можно отнести гибкую защиту, простоту базовой настройки (добавить поддомен для сервиса можно в пару команд) и хорошая политика доступа с аутентификацией (Google OAuth например).
В остальном для самохоста отличный вариант. Понятно что если есть блокировки, то это не подойдёт, но это один из возможных и довольно простых вариантов.

Pest85
30.10.2025 11:29Если нет необходимости давать доступ для всех, то можно рассмотреть Tailscale и похожие для ограничения доступа. Работает даже при использовании провайдером CGNAT, правда по wireguard протоколу, который может блокироваться.
Также вы не указали о том что неплохо было бы отделить сервер используя VLAN или openwrt firewall rules. Основная идея не дать возможность серверу (или в худшем случае тому кто его контролирует) увидеть остальные устройства в вашей сети.
Hubr2025
Это все прекрасно, но живо ли, в свете последних событий?
Имею ввиду - доступно ли оно вне домашней сети?
Kotelnikovekb Автор
Для тестов я пробовал связку VPN + VPS (туннель через WireGuard) — всё поднимается и работает, но стабильность действительно зависит от провайдера: иногда туннель рвётся из-за фильтрации или падения UDP. Для постоянной работы я использую DMZ и статический IP — это проще, надёжнее и гарантированно доступно извне.
ofthevoid
не везде. если вы близко к бордеру по маршруту, то у вас будет один тспу, тогда проблем нет. но если у вас длинный путь до бордера, то на маршруте может быть к примеру три таких точки и их фильтры вполне могут перекрывать друг друга. в этом случае все рискует упасть.
marineboy1
Уже год работаю со связкой VPS -> Wireguard -> Домашний сервер, так как доступен только мобильный интернет (CGNAT). В целом удобно, что при физическом переносе сервера, не нужно ничего настраивать: отключили мобильный интернет (в последнее время часто), плановое отключение электроэнергии и т.п., взял и отвёз к родственникам, воткнул в розетку и кабель в роутер, и готово - туннель сам поднялся и настроил маршруты. Такой сценарий с белым IP не получится.