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

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

Самохостинг (или 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 docker
Prometheus: sudo apt install prometheus
LXD: 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 (возможно, и выше). Пришлось его менять, на другую машинку
Второй мини‑ПК был почти идеален, но потребовал минимального вмешательства — смазки вентилятора.

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