В августе 2024 года автор статьи, backend-разработчик, получил токен у BotFather и написал первого телеграм-бота, который честно признаёт «кривым»: одна модель, отсутствие контекста и падения на длинных сообщениях. Однако бот начал работать и привлёк первых пользователей — детей и знакомых, что подтолкнуло автора к решению «немного доделать». Это «немного» растянулось на два года, и сейчас перед нами платформа, включающая веб-приложение, шесть каналов доставки (Telegram, VK, MAX, Discord, веб и email для уведомлений), биллинг, голосового агента и RAG по документам. Под капотом — 66 контейнеров на двух нодах, собственная BGP-маршрутизация, CI, хелпдеск и GPU-нода с локальными моделями, причём всё это работает на железе, которое стояло под столом и потребляло меньше энергии, чем игровая приставка, до появления второй ноды с RTX 3090. Статья, по словам автора, написана по двум причинам: ему самому не хватало целостной картины селф-хоста всего, и он надеется, что комментарии Хабра укажут на ошибки в его архитектуре.

Экономическое обоснование отказа от облака простое: для AI-платформы нужны постоянно живой backend, очереди, воркеры, две базы данных, объектное хранилище, векторная база и GPU для локального инференса. Автор подсчитал, что аренда подобной конфигурации в облаке обошлась бы в 40–80 тысяч рублей в месяц даже при нуле пользователей, тогда как собственное железо — это разовые расходы и плата за электричество, что для соло-проекта без инвестиций оказывается решающим фактором. Второй аргумент — управляемость доступа: платформа использует как российских провайдеров (GigaChat, YandexGPT, SpeechKit, Yandex OCR, YandexART), так и зарубежных (OpenAI, Anthropic), плюс локальные модели на GPU-ноде. Российские сервисы должны работать напрямую, без туннелей, чтобы избежать лишней задержки, а зарубежные требуют стабильного и резервированного соединения, и автор предпочитает контролировать это разделение самостоятельно на своём маршрутизаторе, а не через поддержку хостинга.

Сетевой уровень — самое спорное и, по признанию автора, оверинжиниренное решение. Дома установлен MikroTik с двумя аплинками от провайдера: российский трафик идёт напрямую через ISP, а зарубежный маршрутизатор отправляет в ECMP-балансировку по нескольким туннелям до VPS, причём часть туннелей терминируется прямо на сервере платформы, который сам является одним из egress-узлов собственной сети. Списки «зарубежных» префиксов не ведутся вручную: на VPS работает сервис, который собирает актуальные списки, рендерит конфиг BIRD и отдаёт маршруты на MikroTik по BGP, обновляясь автоматически. Автор признаёт, что это может выглядеть избыточным, но с момента внедрения ему ни разу не пришлось трогать маршрутизацию руками, а падения туннелей оставались незамеченными для пользователей благодаря ECMP. Первая версия использовала ручные списки маршрутов, что оказалось «работой на полставки», и переход на BGP-фид решил проблему, хотя потребовал разобраться в связке BIRD с RouterOS. Свежие грабли (август): боты в Telegram молчали почти сутки, тогда как MAX и VK работали — причиной оказался не Telegram и не туннель, а unattended-upgrades, который обновил openssl и перезапустил systemd-networkd, а тот по умолчанию удаляет чужие правила policy routing (ManageForeignRoutingPolicyRules=yes). Правила, направлявшие трафик Telegram в туннель, исчезли, но таблицы маршрутов остались, что затруднило диагностику. Лечение — одна строка в drop-in'е networkd, но чтобы её написать, пришлось сутки разбираться; автор делает вывод: всё, что делается с ip rule руками, должно либо жить внутри networkd, либо явно запрещать ему трогать чужое.

Классический вопрос — зачем соло-разработчику 66 контейнеров, если можно взять монолит. Автор отвечает: ядро и есть монолит на FastAPI, а контейнеры — это нарезка по зонам отказа, а не по моде. Каналы доставки реализованы как отдельные гейтвеи: Telegram, VK, MAX, Discord, веб-сокеты и интеграционный шлюз для n8n — если падает один гейтвей, остальные продолжают работать. Биллинг вынесен отдельно, потому что это деньги; медиа и файлы — отдельно, так как они самые прожорливые и падучие; воркеры очередей — отдельно, чтобы фоновая нагрузка не конкурировала с пользовательскими запросами; голосовой агент, веб-поиск, детектор типов файлов и антивирус для загрузок также изолированы. Вокруг ядра — PostgreSQL 17, Redis, MinIO (S3-совместимое хранилище) и Qdrant (векторная база для RAG), а схема БД насчитывает 95 alembic-миграций, что автор называет одной из причин, почему боится её больше всего остального. Отдельные грабли — docker из snap: автор предупреждает не повторять, так как это привело к проблемам с путями volumes, AppArmor-сюрпризам и неожиданным обновлениям. В августе он переехал на apt-версию, что стоило пяти алертов по диску за один вечер, и обнаружил, что docker save пишет несжатые слои, поэтому оценивать место нужно через docker system df, а не по размерам образов в реестре. Кроме того, новая установка Docker CE 29 включает containerd image store по умолчанию, что пересчитывает ID всех образов, и если где-то пинить образы по ID, всё развалится; автор вернул старый стор через "containerd-snapshotter": false в daemon.json ради совместимости миграции.

Контекст для этой истории — растущий тренд на селф-хостинг AI-инструментов, особенно в России, где доступ к зарубежным API нестабилен, а требования к защите данных (152-ФЗ) заставляют компании и разработчиков искать локальные альтернативы. Автор вписывается в этот тренд, используя гибридный подход: российские провайдеры — напрямую, зарубежные — через туннели, а локальные модели — на собственной GPU-ноде, что даёт независимость от внешних ограничений. Подобные проекты, как правило, остаются в тени, поскольку крупные компании предпочитают облачные решения, но для соло-разработчиков и малых команд собственное железо становится способом сократить расходы и получить полный контроль над инфраструктурой. Отраслевая реакция на такие публикации обычно активная: комментарии на Хабре полны советов и предупреждений, что автор и ожидает, признавая, что «почти наверняка делает что-то не так». В то же время подобные истории вдохновляют других энтузиастов, показывая, что даже один человек может построить сложную систему, если готов учиться на ошибках.

Сравнение с альтернативами неизбежно: если бы автор выбрал облако, он бы получил масштабируемость и отсутствие забот о железе, но потерял бы контроль над маршрутизацией и нёс бы постоянные расходы, которые для соло-проекта без дохода были бы неподъёмными. С другой стороны, покупка готового AI-решения, например корпоративной платформы, как в статье ТЕХНОНИКОЛЬ, требует бюджета и команды, что недоступно индивидуальному разработчику. Локальные модели на GPU-ноде дают преимущество в приватности и отсутствии задержек, но требуют умения их настраивать и обновлять, что автор, судя по тексту, освоил. Его подход с разделением на микросервисы и зоны отказа — это компромисс между монолитом и полным микросервисным зоопарком, который для одного человека оказывается жизнеспособным, хотя и требует дисциплины в управлении контейнерами и миграциями.

Перспективы проекта автор видит в продолжении развития платформы, хотя открытым остаётся вопрос, как долго он сможет поддерживать такой темп в одиночку. Среди потенциальных проблем — рост числа пользователей, который потребует либо оптимизации, либо перехода на облачные мощности, а также необходимость регулярно обновлять локальные модели и следить за безопасностью, особенно в свете свежих инцидентов с networkd. Автор также упоминает, что боится миграций базы данных, и это может стать узким местом при добавлении новых функций. В комментариях он ожидает получить советы по улучшению архитектуры, и, возможно, это приведёт к пересмотру некоторых решений, таких как использование BGP или количество контейнеров. В долгосрочной перспективе, если проект останется хобби, автор может либо коммерциализировать платформу, либо передать её сообществу, но пока он продолжает «немного доделывать», и эта статья — лишь промежуточный отчёт о том, как далеко может зайти домашний AI-кластер, начавшийся с кривого бота.