Самохостинг: плюсы, минусы и подводные камни глазами разработчика

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

Самохостинг (или Self Hosted) — это практика размещения и управления своими веб-сервисами (сайтами, репозиториями, системами мониторинга и т.д.) на собственном оборудовании — например, на домашнем сервере или мини-ПК, — вместо того чтобы арендовать хостинг ^[1] у сторонних компаний.

На практике это означает: вы берёте свой старый мини-ПК, ставите туда Linux, Docker и пару контейнеров — и он превращается в полноценный сервер. В этой статье я расскажу, как реализовал самохостинг на двух мини‑ПК с AliExpress. А если хотите следить за моими экспериментами и получать оперативные обновления — подписывайтесь на мой Telegram‑канал: @kotelnikoff_dev ^[2] На Хабре уже есть отличная обзорная статья про базовый self-hosting —
👉 Self-Hosted для домашнего сервера ^[3]
А я хочу рассказать, как я реализовал это на двух мини-ПК с AliExpress и что из этого вышло.

В материале:

• разбор плюсов и минусов самохостинга;

• сравнение с облачными решениями (VPS ^[1]);

• пошаговая инструкция по установке и настройке сервера на Ubuntu;

• варианты организации доступа (DMZ, VPN, OpenWrt);

• расчёт затрат и оценка окупаемости;

• реальный кейс перехода с VPS ^[1] на самохостинг.

Статья будет полезна разработчикам, DevOps‑инженерам и энтузиастам, которые хотят:

• сэкономить на хостинге ^[1];

• получить полный контроль над инфраструктурой;

• развернуть внутренние сервисы без ограничений облачных платформ.

Вы получите не только теоретические знания, но и конкретные инструкции — от выбора оборудования до базовых мер безопасности.

За и против

Плюсы

• Полное владение инфраструктурой: никто не отключит ваш аккаунт и не повысит тариф.

• Отсутствие подписок и лимитов: нет ограничений по ресурсам.

• Гибкость настройки: вы строите инфраструктуру под свои нужды — например, разворачиваете 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 против своего сервера

Варианты реализации: как организовать доступ к серверу из интернета

Варианты реализации: как организовать доступ к серверу из интернета

Существует три основных подхода — от простого к продвинутому.

1. DMZ и проброс портов

Суть: прямой доступ через роутер.
Что нужно:

• статический IP от провайдера или DDNS (при динамическом IP);

• настройка DMZ‑зоны или проброса портов (80, 443) на роутере.

Плюсы:

• простота реализации;

• минимум дополнительных сервисов.

Минусы:

• сервер виден извне — повышенные требования к безопасности.

Для кого: новички, тесты, личные проекты.

2. VPN через VPS

Суть: сервер доступен извне, но без открытых портов.
Как работает:

• между домашним сервером и VPS ^[1] с белым IP поднимается VPN (обычно WireGuard);

• VPS ^[1] становится точкой входа: трафик по VPN идёт в домашнюю сеть.

Плюсы:

• высокий уровень безопасности;

• не требуется настройка роутера.

Минусы:

• нужны расходы на VPS ^[1].

Для кого: пользователи за CGNAT/серым IP, те, кто ценит безопасность.

3. OpenWrt на роутере

Суть: гибкая маршрутизация и сегментация сети.
Возможности:

• создание VLAN;

• Policy‑based routing;

• VPN‑туннели;

• объединение подсетей (сервер, NAS, умный дом).

Плюсы:

• полный контроль над сетью;

• высокая кастомизация.

Минусы:

• требует глубоких знаний сетевых настроек;

• время на конфигурацию.

Для кого: продвинутые пользователи, энтузиасты DevOps.

ВАЖНО!

Многие VPN-протоколы (в частности WireGuard и OpenVPN) периодически блокируются Роскомнадзором или ограничиваются провайдерами.

Как выбрать подходящий вариант

• Белый IP и стандартный роутер → DMZ/проброс портов.

• CGNAT или серый IP → VPN через VPS ^[1].

• Нужно единое сетевое пространство → OpenWrt + маршрутизация.

• Максимальная безопасность → VPN через VPS ^[1] или 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 ^[1] — это надёжнее.

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"

2. Скопируйте публичный ключ на сервер:

ssh-copy-id user@server_ip

3. Отключите парольную аутентификацию в /etc/ssh/sshd_config:

PasswordAuthentication no

4. Перезапустите SSH‑сервис:

sudo systemctl restart ssh

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

1. В BIOS/UEFI:

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

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

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

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

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

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

sensors

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

htop

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

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

• Docker: sudo snap install docker

• Prometheus: sudo apt install prometheus

• LXD: sudo snap install lxd

Примечание:

• Используйте snap для быстрого развёртывания (подходит для новичков).

• Для продвинутой настройки предпочтителен apt с ручным конфигурированием.

• Перед установкой проверьте актуальные инструкции на официальных сайтах проектов.

Экономика самохостинга: краткий расчёт

При старте потребуются разовые затраты на оборудование (от 10 000 до 55 000  ₽ — в зависимости от выбора железа, роутера и накопителей). Ежемесячные расходы складываются из электроэнергии (около 188 ₽/мес за мини‑ПК мощностью 36 Вт), домашнего интернета (500–1 000 ₽/мес) и, при необходимости, VPS ^[1] для VPN (300–800 ₽/мес). В сумме — от 988 до 1 988 ₽/мес. Для сравнения: аренда сопоставимого облачного сервера обойдётся в 15 000 ₽/мес. Таким образом, самохостинг окупается уже в первый год (экономия — от 131 000 ₽/год) при условии постоянного использования и наличия базовых навыков администрирования.

Как у меня всё получилось: реальный опыт

Изначально я использовал два VPS ^[1]: один под GitLab (4 380 ₽/мес), второй под Sentry (3 630 ₽/мес). В сумме — около 8 010 ₽/мес, или 90 120 ₽/год. Эта цифра и стала стимулом для перехода на самохостинг.

На AliExpress я приобрёл два мини‑ПК за 12 000 ₽. Однако экономия тут же столкнулась с реальностью:

• Первый мини‑ПК оказался с конструктивным изъяном: охлаждение и питание были объединены в один модуль, а контроллер вентилятора не работал. В результате устройство постоянно троттлило, нагреваясь до 84 °C (возможно, и выше). Пришлось его менять, на другую машинку

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

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