Self-hosted всё 2026: своя инфраструктура вместо SaaS — Nextcloud, Gitea, n8n

Зачем self-hosting в 2026

Я держу собственный VPS уже несколько лет и за последние два года перевёл на self-hosted инфраструктуру несколько клиентов — от студии на пять человек до компании на сорок сотрудников. Раньше это был выбор энтузиастов. В 2026 году это обоснованное бизнес-решение, и причин для него стало больше.

Первая причина — уход вендоров и нестабильность доступа. За последние годы российский бизнес не раз сталкивался с тем, что привычный SaaS-сервис в один день перестал принимать оплату, заблокировал аккаунт или просто ушёл с рынка. Когда вся ваша рабочая переписка, документы и автоматизации висят на внешнем сервисе, любое такое решение вендора — это паралич бизнеса на неопределённый срок. Своя инфраструктура от этого не зависит: пока работает ваш сервер, работаете и вы.

Вторая причина — цены SaaS. Подписочная модель устроена так, что плата растёт вместе с командой и аппетитами вендора. Вы платите за каждого пользователя, за каждый гигабайт, за каждую интеграцию. На команде из 5 человек это незаметно, на 20 — уже ощутимо, на 50 — это статья бюджета, которую начинает замечать финансовый директор. При этом цена растёт, а вы не управляете этим ростом.

Третья причина — контроль над данными. В SaaS ваши данные лежат на чужих серверах, в чужой юрисдикции, под чужими правилами. Вы не знаете точно, кто имеет к ним доступ, как они шифруются, что произойдёт при сбое или утечке. На своём сервере вы знаете о данных всё, потому что они физически у вас.

Четвёртая причина — 152-ФЗ и локализация. Федеральный закон «О персональных данных» требует, чтобы персональные данные граждан РФ обрабатывались и хранились на серверах, расположенных на территории России. Когда вы держите инфраструктуру на российском VPS, локализация выполняется по определению — данные физически в РФ, под вашим управлением. Это сильно упрощает соответствие требованиям регулятора по сравнению с разбирательством, где именно хранит ваши данные тот или иной зарубежный SaaS. Подробнее о требованиях я писал в статье об аудите 152-ФЗ.

Пятая причина — независимость и гибкость. На своём сервере вы ставите то, что нужно, настраиваете как нужно, интегрируете что угодно с чем угодно. Нет лимитов тарифа, нет «эта функция только в Enterprise», нет вендорского замка. Захотели — подняли новый сервис за вечер, не захотели — убрали.

Честно скажу сразу, чтобы не было иллюзий: self-hosting — это не бесплатно и не «поставил и забыл». Вы меняете подписочные платежи на стоимость сервера плюс своё (или подрядчика) время на поддержку. Дальше в статье я честно разберу, когда этот обмен выгоден, а когда нет.

Экономика — когда self-hosted дешевле SaaS

Главный вопрос, который мне задаёт каждый клиент: «А это вообще выгодно?» Ответ зависит от размера команды и того, как считать. Давайте посчитаю на реальном примере.

Возьмём компанию из 20 человек, которая использует типичный набор облачных сервисов: облачное хранилище для файлов, git-хостинг для кода, сервис автоматизаций, веб-аналитику, менеджер паролей, корпоративный мессенджер. На SaaS-подписках при 20 пользователях это легко набегает на 40-80 тыс. ₽ в месяц, то есть 500-960 тыс. ₽ в год. И эта сумма растёт с каждым новым сотрудником.

Теперь self-hosted. Один VPS среднего класса (8 vCPU / 16 ГБ RAM / 200 ГБ NVMe) на российском хостинге стоит примерно 4-8 тыс. ₽/мес. Плюс отдельное хранилище для бэкапов — ещё 1-2 тыс. ₽/мес. Плюс поддержка: либо своё время сисадмина, либо подрядчик на абонентке 15-40 тыс. ₽/мес. Итого инфраструктура и поддержка — 20-50 тыс. ₽/мес против 40-80 тыс. на SaaS.

Ключевой момент экономики self-hosting — расходы почти не растут с командой. Добавили 10 новых сотрудников — на SaaS это +20-40 тыс. ₽/мес, на своём сервере чаще всего 0 ₽, потому что мощности ещё хватает. Именно поэтому точка безубыточности — это команда примерно от 5-10 человек. Ниже этого порога SaaS обычно выгоднее, потому что разовые затраты на настройку и постоянная нагрузка по поддержке не окупаются экономией на подписках.

На горизонте 12-24 месяцев для команды от 20 человек self-hosted даёт экономию 100-300 тыс. ₽/год даже с учётом стоимости поддержки. Плюс вы получаете контроль над данными и независимость от вендоров, которые деньгами не измеряются, но в текущих реалиях стоят дорого.

Какой VPS взять

Раз мы говорим про 152-ФЗ и независимость, VPS берём российский. Я работаю с тремя провайдерами и каждый из них надёжен для продакшена.

Selectel — мой основной выбор для серьёзных проектов. Зрелая облачная платформа, дата-центры в РФ, гибкое масштабирование, S3-совместимое объектное хранилище для бэкапов прямо у них. Хорошая панель управления, API, снапшоты дисков. Чуть дороже конкурентов, но за стабильность.

Timeweb Cloud — отличный баланс цены и качества. Простая панель, быстрые NVMe-диски, есть managed-базы и S3-хранилище. Хорош для малого и среднего бизнеса, где не нужна тяжёлая enterprise-инфраструктура.

RuVDS — давно на рынке, дата-центры в РФ, в том числе с повышенной защищённостью. Подходит, если важны юридические гарантии размещения в России и есть требования по безопасности.

Стартовая рекомендация для большинства — 4 vCPU / 8 ГБ RAM / 160 ГБ NVMe. Этого хватает на основной набор сервисов малого бизнеса с запасом. Берите NVMe-диски, не обычные SSD: базы данных и Nextcloud любят быстрый диск. Операционная система — любой современный LTS-дистрибутив Linux на ваш вкус; я обычно беру Debian или Ubuntu LTS за стабильность и долгий цикл поддержки.

Важный момент: не экономьте на RAM. Каждый Docker-контейнер с базой данных и приложением ест память. Nextcloud с PostgreSQL, n8n, аналитика и пара мелких сервисов на 4 ГБ будут задыхаться. 8 ГБ — комфортный минимум для рабочего набора.

Docker + Docker Compose как основа

Весь мой self-hosted стек живёт в Docker. Это не догма, но за годы практики я не нашёл способа лучше. Docker даёт изоляцию: каждый сервис в своём контейнере, со своими зависимостями, не конфликтует с соседями. Обновление одного сервиса не ломает другой. Перенос на новый сервер — это копирование папки с данными и одна команда запуска.

Docker Compose поверх Docker превращает управление десятком контейнеров в один декларативный файл. Вы описываете все сервисы, их связи, тома и сети в docker-compose.yml, и поднимаете всё командой docker compose up -d. Это и документация вашей инфраструктуры, и инструмент развёртывания одновременно.

Базовая логика, которой я придерживаюсь: один docker-compose.yml на сервис (или группу связанных сервисов), данные в именованных томах или bind-mount в отдельную папку, конфиги под контролем версий в вашем же Gitea. Перед глазами всегда понятно, что где лежит и как поднимается.

Вот реальный пример — Nextcloud с базой PostgreSQL и фоновым cron-контейнером для регулярных задач Nextcloud:

# docker-compose.yml — Nextcloud + PostgreSQL
services:
  nextcloud-db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - ./data/db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    networks:
      - nextcloud-net

  nextcloud-app:
    image: nextcloud:30-apache
    restart: unless-stopped
    depends_on:
      - nextcloud-db
    ports:
      - "127.0.0.1:8080:80"   # слушаем только локально, наружу через nginx
    volumes:
      - ./data/nextcloud:/var/www/html
    environment:
      POSTGRES_HOST: nextcloud-db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      NEXTCLOUD_ADMIN_USER: ${ADMIN_USER}
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.ru
      OVERWRITEPROTOCOL: https
    networks:
      - nextcloud-net

  nextcloud-cron:
    image: nextcloud:30-apache
    restart: unless-stopped
    depends_on:
      - nextcloud-db
    volumes:
      - ./data/nextcloud:/var/www/html
    entrypoint: /cron.sh   # запускает фоновые задачи Nextcloud каждые 5 минут
    networks:
      - nextcloud-net

networks:
  nextcloud-net:

Обратите внимание на строку ports: "127.0.0.1:8080:80" — приложение слушает только localhost, а наружу его пробрасывает reverse-proxy с SSL. Это базовый принцип безопасности: ни один контейнер не торчит в интернет напрямую. Пароли вынесены в переменные окружения через файл .env, который никогда не попадает в git.

Nextcloud вместо облачных дисков

Nextcloud — это сердце моего self-hosted стека и обычно первый сервис, который я поднимаю клиенту. Это замена облачным хранилищам файлов: синхронизация папок между устройствами, общий доступ по ссылкам, версионирование файлов, мобильные и десктопные клиенты под все платформы.

Но Nextcloud давно перерос роль «своего Диска». Через приложения (их ставят в пару кликов из встроенного магазина) он превращается в целую рабочую платформу: совместное редактирование документов через встроенный офисный движок, календари и контакты с синхронизацией по стандартным протоколам, заметки, канбан-доски для задач, видеозвонки. Для малого бизнеса это закрывает огромный пласт потребностей одним сервисом.

Из практики: Nextcloud любит ресурсы и быстрый диск. На медленном HDD совместное редактирование документов будет лагать. PostgreSQL вместо встроенной SQLite обязателен для любой реальной нагрузки — на SQLite Nextcloud начинает спотыкаться уже на 5-10 одновременных пользователях. Обязательно настройте фоновый cron (отдельный контейнер из примера выше), иначе фоновые задачи будут выполняться при заходах пользователей и тормозить интерфейс.

Ещё важная деталь по 152-ФЗ: вся синхронизация и хранение файлов идут на ваш российский сервер. Документы клиентов, договоры, персональные данные сотрудников физически остаются в РФ. Это сильное преимущество перед зарубежными облаками с точки зрения соответствия закону.

Gitea/Forgejo вместо внешнего git-хостинга

Для разработки нужен git-хостинг: репозитории, pull-request'ы, code review, issue-трекер, CI/CD. Внешние сервисы хороши, но для российской команды это снова вопрос доступа и данных — ваш код, ваша интеллектуальная собственность лежит на чужих серверах.

Gitea — лёгкий git-сервис, написанный на Go. Один бинарник, минимум ресурсов, быстрый веб-интерфейс. Поднимается на VPS за десять минут, тянет команду в десятки разработчиков на скромном железе. Поддерживает pull-request'ы, ревью, issues, проекты, wiki, встроенный CI через Gitea Actions (совместимый по синтаксису с популярным форматом workflow-файлов).

Forgejo — форк Gitea, который пошёл по пути более открытого community-управления. Технически очень близок к Gitea, во многом совместим, активно развивается. Я ставлю либо то, либо другое в зависимости от предпочтений команды — для пользователя разница минимальна.

Из реального опыта: Gitea/Forgejo на 4 ГБ RAM спокойно обслуживает команду из 10-15 разработчиков с десятками репозиториев. Встроенный CI-раннер (Gitea Actions / Forgejo Actions) закрывает базовые потребности — прогон тестов, сборка, деплой. Для тяжёлых пайплайнов раннер лучше вынести на отдельную машину, чтобы сборки не отъедали ресурсы у самого git-сервиса.

Главный плюс — миграция простая. Gitea умеет импортировать репозитории с других хостингов вместе с issues и PR. Перевод команды занимает пару дней, после чего весь код живёт у вас.

n8n вместо внешних сервисов автоматизации

Автоматизация рутины — это то, на чём команда экономит больше всего времени. Внешние no-code сервисы автоматизации удобны, но дорожают с числом операций и снова держат логику ваших процессов на чужой стороне.

n8n — self-hosted платформа автоматизации с визуальным редактором workflow. Вы соединяете блоки-ноды в цепочки: «пришло письмо → распарсить → создать запись в базе → отправить уведомление в чат». Сотни готовых интеграций, поддержка вебхуков, расписаний, ветвлений, и при необходимости вставка собственного JavaScript-кода прямо в ноду.

На своём сервере n8n снимает лимиты по числу операций — вы платите за сервер, а не за каждое срабатывание. Я использую n8n для типичных вещей: синхронизация данных между сервисами, обработка форм с сайта, уведомления команде о событиях, регулярные выгрузки и отчёты, интеграция самописных скриптов в общий конвейр.

Поднимается n8n тоже в Docker одним compose-файлом, данные workflow хранит в своей базе. Важно сразу настроить аутентификацию и закрыть его за reverse-proxy — n8n имеет доступ к токенам всех ваших интеграций, это лакомая цель, и наружу без защиты его выставлять нельзя.

На практике одна толковая n8n-автоматизация процесса, который раньше делался руками по полчаса в день, окупает месяц аренды VPS за пару недель сэкономленного времени сотрудника.

Своя веб-аналитика вместо внешней

Веб-аналитика — отдельная история с точки зрения 152-ФЗ. Когда вы подключаете внешний счётчик, данные о ваших посетителях (включая IP и поведение, которые при определённых условиях считаются персональными данными) утекают на сторонний сервер. Self-hosted аналитика держит эти данные у вас.

Plausible — лёгкая, приватная аналитика. Не использует cookies, не собирает персональные данные в привычном смысле, отдаёт чистый понятный дашборд: источники трафика, популярные страницы, конверсии. Скрипт счётчика крошечный, не замедляет сайт. Идеально, когда нужны метрики без перегруза и без головной боли с согласиями на cookies.

Umami — ещё легче Plausible, тоже приватная и без cookies, открытый код, простой дашборд. Минимальные требования к ресурсам. Мой выбор для небольших сайтов, где нужно «просто видеть посещаемость».

Matomo — тяжёлая артиллерия. Полноценная замена большим аналитическим платформам: воронки, когорты, тепловые карты, записи сессий, A/B-тесты. Жрёт ресурсы заметно больше, нужна нормальная база и регулярное обслуживание. Беру, когда клиенту реально нужна глубокая аналитика, а не просто счётчик.

Для большинства проектов я ставлю Plausible или Umami — они закрывают 90% реальных потребностей и не требуют обслуживания. Matomo держу только там, где маркетинг действительно работает с глубокой аналитикой.

Vaultwarden вместо облачных менеджеров паролей

Пароли, токены, ключи доступа — самое чувствительное, что есть у команды. Держать их в облачном менеджере означает доверить весь доступ к вашей инфраструктуре третьей стороне. Self-hosted решает это радикально.

Vaultwarden — лёгкая реализация сервера, совместимого с клиентами популярного менеджера паролей с открытым исходным кодом. Вы используете привычные браузерные расширения и мобильные приложения, но данные синхронизируются с вашим сервером, а не с чужим облаком. Написан на Rust, ест минимум ресурсов — спокойно живёт даже на самом скромном VPS.

Возможности — всё, что ждёшь от командного менеджера паролей: организации и коллекции, разграничение доступа по ролям, шаринг паролей между сотрудниками, генерация, двухфакторная аутентификация, хранение защищённых заметок и файлов. Хранилище зашифровано на стороне клиента, то есть даже имея доступ к серверу, прочитать пароли без мастер-ключа нельзя.

Из обязательного: Vaultwarden держим строго за HTTPS, с включённым 2FA для всех, и обязательно в бэкапах. Потеря базы Vaultwarden без бэкапа — это потеря всех паролей команды, поэтому именно этот сервис я бэкаплю особенно тщательно.

Свой чат и почта

Корпоративные коммуникации — следующий кандидат на импортозамещение. Здесь есть два направления: командный чат и почта.

Для чата у меня два рабочих варианта. Rocket.Chat — полноценный командный мессенджер с каналами, тредами, файлами, звонками, ботами и интеграциями. Веб, десктоп, мобильные клиенты. По функционалу закрывает потребности корпоративного чата целиком. Требователен к ресурсам — на нём не экономьте память.

Matrix (сервер Synapse или более лёгкие альтернативы) — открытый федеративный протокол обмена сообщениями со сквозным шифрованием. Подходит, когда важна максимальная приватность переписки и децентрализация. Чуть сложнее в настройке и обслуживании, но даёт настоящее end-to-end шифрование из коробки.

Почта — отдельная и самая сложная тема в self-hosting. Скажу честно как практик: свой почтовый сервер для отправки писем — это боль. Проблема не в том, чтобы поднять сервер (готовые сборки вроде Mailcow или Mailu разворачиваются в Docker), а в доставляемости. Чтобы ваши письма не улетали в спам, нужны корректные PTR-записи, SPF, DKIM, DMARC, прогретый IP с хорошей репутацией, и постоянный мониторинг блок-листов.

Мой прагматичный совет: входящую почту и хранение писем держать у себя можно и нужно, а вот для надёжной отправки исходящих часто разумнее использовать relay через специализированный сервис отправки. Это компромисс, но он экономит десятки часов борьбы со спам-фильтрами. Полностью автономную почту имеет смысл поднимать, только если у вас есть человек, готовый постоянно за ней следить.

Metabase и Grafana для аналитики

Когда у вас уже есть свои базы данных (от Nextcloud, n8n, ваших приложений), хочется видеть по ним красивые дашборды. Тут два инструмента, которые решают разные задачи.

Metabase — BI-инструмент для бизнес-аналитики. Подключаете базу, и без единой строчки SQL строите графики, таблицы, дашборды через визуальный конструктор. Кто умеет SQL — пишет запросы напрямую. Идеален, когда руководителю нужно видеть бизнес-метрики: выручка, заказы, активность пользователей. Self-hosted, данные не покидают ваш сервер.

Grafana — инструмент для технических метрик и мониторинга. Дашборды по нагрузке сервера, использованию ресурсов, времени отклика сервисов, бизнес-метрикам из time-series баз. Связка Grafana + Prometheus — стандарт де-факто для мониторинга инфраструктуры. Я держу Grafana для технического здоровья сервера, Metabase — для бизнес-показателей.

Оба инструмента работают с вашими данными на вашем сервере. Никаких выгрузок в чужие облака, никаких вопросов «а кто видит нашу выручку». Для 152-ФЗ это снова плюс — аналитика по персональным данным не покидает периметр.

Бэкапы — критично

Это самая важная секция статьи, и я намеренно вынес её отдельно. Self-hosting без бэкапов — это не self-hosting, это мина замедленного действия. Диск умрёт, контейнер сломается при обновлении, кто-то выполнит не ту команду — вопрос не «если», а «когда». И в этот момент решает только наличие свежего рабочего бэкапа.

Мои инструменты — restic и borgbackup. Оба делают инкрементальные дедуплицированные шифрованные бэкапы. restic я люблю за нативную поддержку S3-совместимых хранилищ: бэкаплю прямо в объектное хранилище российского провайдера, данные зашифрованы до отправки. borg чуть быстрее на больших объёмах и хорош для бэкапа на отдельный сервер по SSH.

Железное правило бэкапов — 3-2-1: три копии данных, на двух разных носителях, одна копия offsite (вне основного сервера). На практике это значит: данные на VPS, бэкап в S3-хранилище того же или другого провайдера, и желательно ещё одна копия в другом месте. Бэкап на тот же диск, где лежат данные, бэкапом не считается.

#!/bin/bash
# backup.sh — ежедневный бэкап в S3 через restic
set -euo pipefail

export RESTIC_REPOSITORY="s3:https://s3.example-ru.cloud/my-backups"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="${S3_KEY}"
export AWS_SECRET_ACCESS_KEY="${S3_SECRET}"

BACKUP_PATHS="/srv/docker/nextcloud/data /srv/docker/gitea /srv/docker/vaultwarden"

echo "[$(date '+%F %T')] Останавливаем сервисы для консистентного дампа БД"
# Дамп баз перед бэкапом файлов
docker exec nextcloud-db pg_dump -U nextcloud nextcloud \
  > /srv/docker/nextcloud/data/db-dump.sql

echo "[$(date '+%F %T')] Запускаем restic backup"
restic backup $BACKUP_PATHS \
  --tag daily \
  --exclude='*.tmp' \
  --exclude='*/cache/*'

echo "[$(date '+%F %T')] Чистим старые снапшоты (политика хранения)"
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

echo "[$(date '+%F %T')] Проверяем целостность репозитория"
restic check

echo "[$(date '+%F %T')] Бэкап завершён успешно"

Этот скрипт я вешаю на cron раз в сутки ночью. Обратите внимание на три вещи: дамп базы данных перед бэкапом файлов (бэкап «живой» базы напрямую может оказаться битым), политика хранения (7 дней + 4 недели + 6 месяцев), и обязательная проверка целостности restic check в конце.

И самое главное, что забывают все: регулярно проверяйте восстановление. Бэкап, который вы ни разу не восстанавливали, — это не бэкап, а надежда. Раз в квартал я разворачиваю бэкап на тестовом сервере и проверяю, что данные читаются. Это единственный способ убедиться, что в час Х вы не останетесь с зашифрованным архивом, от которого потерян ключ.

Безопасность self-hosted

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

SSH по ключам, без паролей. Парольная аутентификация SSH отключается полностью, вход только по ключу. Порт SSH меняю с дефолтного — это не защита, но отсекает массу автоматических переборщиков. Root-логин по SSH запрещён, работа через обычного пользователя с sudo.

Firewall. Закрываем всё, открываем только нужное: 443 (HTTPS), 80 (для редиректа на HTTPS и выпуска сертификатов), и порт SSH. Все остальные порты — наружу закрыты. Контейнеры общаются между собой по внутренним Docker-сетям, наружу торчит только reverse-proxy.

fail2ban. Автоматически банит IP после нескольких неудачных попыток входа — по SSH, по веб-сервисам. Резко снижает фон брутфорс-атак.

SSL/TLS на всё. Никакого HTTP в продакшене. Бесплатные сертификаты от ACME-провайдера, автоматическое продление. Reverse-proxy типа Nginx или Caddy выпускает и обновляет сертификаты автоматически. Весь трафик шифруется.

Регулярные обновления. Это где сыпется большинство. Образы Docker обновляются, ОС обновляется, иначе известные уязвимости копятся. Я настраиваю автообновления безопасности ОС и раз в месяц прохожусь по версиям контейнеров. Устаревший Nextcloud или git-сервис с дырой — частая причина взломов self-hosted серверов.

Вот реальный фрагмент nginx как reverse-proxy с SSL для Nextcloud:

# /etc/nginx/sites-available/cloud.example.ru
server {
    listen 80;
    server_name cloud.example.ru;
    # Весь HTTP-трафик редиректим на HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name cloud.example.ru;

    ssl_certificate     /etc/letsencrypt/live/cloud.example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.example.ru/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # Заголовки безопасности
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "no-referrer" always;

    # Nextcloud любит большие файлы
    client_max_body_size 10G;
    client_body_timeout 300s;

    location / {
        # Контейнер слушает только localhost:8080
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Редиректы для CalDAV/CardDAV (календари и контакты Nextcloud)
    location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; }
    location = /.well-known/caldav  { return 301 $scheme://$host/remote.php/dav; }
}

Ключевые моменты: HTTP редиректится на HTTPS, заголовок HSTS заставляет браузер всегда ходить по HTTPS, client_max_body_size 10G позволяет грузить большие файлы в Nextcloud, и proxy_pass на 127.0.0.1:8080 — туда, где контейнер слушает локально. Наружу торчит только nginx с валидным сертификатом.

Мониторинг

Self-hosted сервис, который упал, и вы узнали об этом от рассерженного сотрудника, — это плохой self-hosting. Мониторинг закрывает этот разрыв: вы узнаёте о проблеме раньше пользователей.

Uptime Kuma — мой обязательный сервис на каждом сервере. Лёгкий, красивый, простой мониторинг доступности. Проверяет, что ваши сервисы отвечают (по HTTP, TCP, ping), показывает аптайм и время отклика, и шлёт уведомления в чат или на почту при падении. Поднимается за пять минут одним контейнером. Дополнительно умеет проверять срок действия SSL-сертификатов и предупреждать заранее.

Grafana + Prometheus — для более глубокого мониторинга ресурсов. Графики по загрузке CPU, памяти, диска, сети по каждому контейнеру и серверу в целом. Алерты при превышении порогов: место на диске заканчивается, память на исходе, нагрузка зашкаливает. Это спасает от ситуации «диск заполнился под ноль и всё встало».

Минимальная связка для старта — Uptime Kuma для доступности плюс простой алерт на свободное место на диске. Этого достаточно, чтобы не получать неприятных сюрпризов. По мере роста добавляется Grafana с детальными метриками.

Когда self-hosting НЕ нужен

Я зарабатываю на self-hosting, но скажу честно: он нужен не всем. Вот ситуации, когда я отговариваю клиента и рекомендую остаться на готовых сервисах.

Команда меньше 5 человек. Экономика не сходится. Стоимость настройки и поддержки не окупается экономией на подписках. Для соло-предпринимателя или команды из трёх человек готовые сервисы дешевле и проще. Точка.

Нет того, кто будет это поддерживать. Self-hosted — это не «поставил и забыл». Кто-то должен обновлять, чинить, следить за бэкапами и безопасностью. Если в команде нет технического человека и нет бюджета на подрядчика, не поднимайте инфраструктуру, за которой некому ухаживать. Заброшенный сервер с устаревшими сервисами опаснее, чем его отсутствие.

Критичность 24/7 без резервирования. Один VPS — это единая точка отказа. Если ваш бизнес встаёт колом при недоступности сервиса на час, вам нужно резервирование, отказоустойчивость, дежурный инженер — а это уже совсем другой бюджет. Иногда SLA готового сервиса дешевле, чем построить надёжность самому.

Узкоспециализированный функционал. Если вам нужен конкретный отраслевой сервис, у которого нет вменяемого self-hosted аналога, не изобретайте велосипед. Берите готовое и направляйте силы на бизнес.

Мой подход — гибридный. Часть стека self-hosted (то, что про данные, контроль и экономику), часть на готовых сервисах (то, где self-hosting не окупается или слишком рискован). Догматизм «всё своё или ничего» вредит бизнесу. Здравый смысл важнее идеологии.

Стоимость запуска и поддержки

Разовая настройка зависит от состава стека: базовый набор (Nextcloud + git-сервис + аналитика) — ближе к нижней границе, полный стек с чатом, BI, мониторингом и тонкой настройкой безопасности — к верхней. Ежемесячная поддержка — самая обсуждаемая статья: если в команде есть технический человек, она равна нулю в деньгах, но стоит его времени; если поддержка на подрядчике — это абонентка.

Окупаемость для команды от 15-20 человек обычно наступает в горизонте 12-18 месяцев за счёт ухода от растущих подписок. Дальше self-hosted работает в плюс, и плюс растёт с каждым новым сотрудником.

Топ-5 ошибок self-hosting

Ошибка 1: Нет бэкапов или они не проверяются. Самая дорогая ошибка. Сервер живёт год, всё хорошо, потом диск умирает — и выясняется, что бэкапов нет или они битые. Настройте автоматические бэкапы по правилу 3-2-1 в первый же день и проверяйте восстановление раз в квартал.

Ошибка 2: Сервисы торчат наружу без защиты. Контейнер с открытым наружу портом и дефолтным паролем взломают за часы. Всё за reverse-proxy с SSL, всё за фаерволом, сильные пароли и 2FA. Ни один сервис не должен слушать публичный интерфейс напрямую.

Ошибка 3: Не обновляют. «Работает — не трогай» — путь к взлому. Устаревшие версии копят известные уязвимости. Автообновления безопасности ОС и регулярный апдейт контейнеров обязательны.

Ошибка 4: Экономят на ресурсах. VPS на 2 ГБ RAM под полноценный стек — это постоянные тормоза и падения сервисов от нехватки памяти. Лучше взять конфигурацию с запасом, чем потом ловить нестабильность и объяснять команде, почему всё лагает.

Ошибка 5: Нет мониторинга. Сервис упал ночью, узнали утром от сотрудников, диск заполнился и база встала. Uptime Kuma и алерт на свободное место ставятся за полчаса и снимают этот класс проблем.

FAQ

Можно ли поднять всё это самому без сисадмина? Базовый стек (Nextcloud + git-сервис + аналитика) технически грамотный человек поднимет по документации за выходные. Но поддержка, безопасность и бэкапы требуют постоянного внимания. Если сомневаетесь — лучше делегировать настройку, а поддерживать по инструкции.

Что будет, если VPS-провайдер закроется? Поэтому и нужны бэкапы offsite. При наличии свежего бэкапа перенос на нового провайдера — это несколько часов: новый VPS, восстановление данных, запуск compose-файлов. Инфраструктура в Docker переносится легко.

Соответствует ли self-hosted на российском VPS требованиям 152-ФЗ? Размещение на российском сервере выполняет ключевое требование локализации — данные физически в РФ. Но 152-ФЗ — это не только про географию: нужны согласия на обработку, политика конфиденциальности, организационные меры. Self-hosting упрощает соответствие, но не отменяет остальных требований.

Насколько это надёжно по сравнению с готовыми сервисами? Один VPS менее надёжен, чем распределённая инфраструктура крупного провайдера. Но при грамотной настройке (бэкапы, мониторинг, обновления) аптайм вполне достаточный для большинства задач. Для критичных 24/7-нагрузок нужно резервирование.

Сколько сервисов потянет один VPS? На 8 ГБ RAM комфортно живут 5-8 основных сервисов малого бизнеса. Тяжёлые (Matomo, Rocket.Chat, почтовый сервер) лучше разносить или брать сервер помощнее.

Docker обязателен? Нет, но он сильно упрощает жизнь: изоляция, переносимость, простое обновление. Я не вижу причин в 2026 поднимать self-hosted стек без Docker.

Как мигрировать с готовых сервисов? По очереди, не всё сразу. Сначала самое простое (аналитика, пароли), параллельно со старым сервисом. Убедились, что работает — переключаемся полностью. Потом следующий сервис. Резкая миграция всего разом — частая причина хаоса.

Чек-лист запуска своей инфраструктуры

Self-hosting в 2026 — это зрелое и обоснованное решение для команд, которым важны контроль над данными, независимость от вендоров и соответствие 152-ФЗ. Но это инструмент, а не идеология: применять его нужно там, где он окупается, и не лезть туда, где готовый сервис объективно лучше.

Чек-лист запуска своей инфраструктуры:

Шаг 1: оцените экономику. Посчитайте текущие SaaS-расходы, размер команды, наличие технического человека. Если команда меньше 5 человек или некому поддерживать — остановитесь здесь, это не для вас сейчас.

Шаг 2: возьмите российский VPS (Selectel / Timeweb Cloud / RuVDS) от 4 vCPU / 8 ГБ RAM на современном LTS-дистрибутиве Linux. Настройте безопасность с первого дня: SSH по ключам, firewall, fail2ban.

Шаг 3: поднимите Docker + Docker Compose. Заведите reverse-proxy (Nginx или Caddy) с автоматическим SSL. Все сервисы — за прокси, ничего наружу напрямую.

Шаг 4: начните с ядра — Nextcloud для файлов, Gitea/Forgejo для кода, Plausible/Umami для аналитики, Vaultwarden для паролей. По одному сервису, параллельно со старыми, с проверкой.

Шаг 5: настройте бэкапы (restic/borg + offsite S3) и мониторинг (Uptime Kuma) ДО того, как переведёте на инфраструктуру боевые данные. Проверьте восстановление из бэкапа.

Шаг 6: по мере потребности добавляйте n8n для автоматизаций, Metabase/Grafana для аналитики, свой чат и почту. Не всё сразу — наращивайте постепенно.

Шаг 7: заложите регулярное обслуживание — обновления, проверка бэкапов, контроль метрик. Self-hosting живёт, пока за ним ухаживают.

Если нужна помощь с переводом инфраструктуры на self-hosted — пишите в Telegram. Я сам держу этот стек, перевожу клиентов с зарубежного SaaS на свои серверы в РФ, помогу подобрать конфигурацию, посчитать экономику и развернуть всё под ключ с бэкапами и безопасностью. Бесплатная консультация 30 минут.