Что это вообще такое и зачем оно нужно?

Самохостинг (или 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.

Важные меры безопасности

При открытии сервера наружу немедленно примите следующие меры:

  1. Закройте лишние порты (оставьте только 80 и 443).

  2. Настройте SSH: только по ключу, на нестандартном порту.

  3. Установите фаервол (UFW, iptables) и fail2ban.

  4. Используйте HTTPS (Let’s Encrypt, Traefik).

  5. Не храните ценные данные в корне DMZ.

Помните: DMZ — не защита, а изолированный сегмент. Безопасность обеспечивается настройками и обновлениями.

Простой алгоритм выбора

  1. Начните с DMZ и DDNS — чтобы понять принцип работы.

  2. Для постоянной эксплуатации выберите VPN через VPS — это надёжнее.

  3. Если хотите углубиться в сетевые технологии — пробуйте OpenWrt и комплексную маршрутизацию.

Как реализовать на практике: пошаговая инструкция для Ubuntu

1. Подготовка установочного носителя

  1. Скачайте Ubuntu Server с официального сайта (предпочтительно последнюю LTS‑версию).

  2. Создайте загрузочную флешку:

    • в Windows — используйте Rufus;

    • в macOS/Linux — balenaEtcher.

  3. Запишите ISO‑образ на флешку.

2. Установка системы

  1. Загрузите устройство с установочной флешки.

  2. В процессе установки:

    • включите SSH‑доступ (рекомендуется сразу настроить аутентификацию по ключам);

    • задайте статический IP‑адрес (или зарезервируйте его в настройках роутера);

    • установите hostname (уникальное имя сервера);

    • активируйте автоматические обновления пакетов.

  3. По завершении установки перезагрузите систему.

3. Настройка SSH‑доступа (безопасность первым делом)

  1. Сгенерируйте SSH‑ключ на своём компьютере:

ssh-keygen -t ed25519 -C "you@example.com"
  1. Скопируйте публичный ключ на сервер:

ssh-copy-id user@server_ip
  1. Отключите парольную аутентификацию в /etc/ssh/sshd_config:

PasswordAuthentication no
  1. Перезапустите SSH‑сервис:

sudo systemctl restart ssh

4. Базовая оптимизация оборудования

  1. В BIOS/UEFI:

    • активируйте режим максимальной производительности (CPU Performance / Disable Energy Saver);

    • отключите энергосберегающие функции, если они мешают стабильной работе.

  2. Установите утилиты для мониторинга:

    • sensors и htop — контроль температуры и загрузки CPU;

    • smartmontools — мониторинг состояния дисков.

  3. Проверьте температуру компонентов после загрузки:

sensors
  1. Оцените загрузку системы:

htop

5. Установка дополнительного ПО (по необходимости)

Для развёртывания сервисов установите нужные пакеты через apt или snap:

  • Dockersudo snap install docker

  • Prometheussudo apt install prometheus

  • LXDsudo 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 (возможно, и выше). Пришлось его менять, на другую машинку

  • Второй мини‑ПК был почти идеален, но потребовал минимального вмешательства — смазки вентилятора.

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

Комментарии (6)


  1. Hubr2025
    30.10.2025 11:29

    Это все прекрасно, но живо ли, в свете последних событий?

    Имею ввиду - доступно ли оно вне домашней сети?


    1. Kotelnikovekb Автор
      30.10.2025 11:29

      Для тестов я пробовал связку VPN + VPS (туннель через WireGuard) — всё поднимается и работает, но стабильность действительно зависит от провайдера: иногда туннель рвётся из-за фильтрации или падения UDP. Для постоянной работы я использую DMZ и статический IP — это проще, надёжнее и гарантированно доступно извне.


    1. ofthevoid
      30.10.2025 11:29

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


  1. LeshaRB
    30.10.2025 11:29

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


    1. Kotelnikovekb Автор
      30.10.2025 11:29

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


    1. S-trace
      30.10.2025 11:29

      Aoostar 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 дисковую корзину, но это уже другой уровень.