Проще говоря, self-hosted - это когда инструмент работает у вас, а не только у поставщика SaaS. Вы сами управляете сервером, доступами, обновлениями, резервными копиями, логами, сетью и безопасностью.
Для AI-проектов self-hosted часто выбирают, когда важны контроль данных, интеграции с внутренними системами, требования безопасности, локальный запуск моделей, стоимость при больших объемах или запрет на передачу данных во внешние облака.
Но self-hosted не означает автоматически безопаснее или дешевле. Если сервер плохо настроен, нет обновлений, бэкапов, мониторинга, секреты лежат в открытых файлах, а доступы выданы всем подряд, риск может быть выше, чем в зрелом облачном сервисе.
В AI-агентах self-hosted-подход часто используют для оркестрации workflow, хранения памяти, RAG, логов, документов и интеграций. Модель при этом может быть локальной, облачной или гибридной: например, агент работает на вашем сервере, а отдельные запросы отправляет в OpenAI API.
Главные плюсы self-hosted: контроль над данными, гибкая настройка, возможность работать во внутренней сети, независимость от ограничений SaaS и больше вариантов кастомизации. Главные минусы: ответственность за поддержку, безопасность, обновления, масштабирование, доступность и аварийное восстановление.
Перед выбором self-hosted стоит честно оценить команду. Нужны люди, которые умеют администрировать сервер, настраивать HTTPS, firewall, Docker, бэкапы, мониторинг, секреты, права доступа и обновления. Без этого self-hosted быстро превращается в технический долг.
В production важно иметь инфраструктурный минимум: HTTPS, закрытые порты, регулярные обновления, резервные копии, мониторинг, alerting, журнал доступа, управление секретами, раздельные роли, план восстановления и документацию по запуску.
Примеры
- Компания разворачивает n8n self-hosted на своем VPS, чтобы подключить внутренние CRM и базы без лишних внешних доступов.
- AI-агент работает на корпоративном сервере, хранит память в PostgreSQL и вызывает модель через отдельный API.
- Ollama запускает локальную LLM на рабочей станции, а агент обращается к ней через local API.
- Vector database развернута self-hosted, чтобы документы компании не уходили в сторонний сервис.
- Команда использует Docker Compose для запуска агента, Redis, PostgreSQL и панели мониторинга на одном сервере.
Где используется
- локальный AI-агент
- запуск AI-агента на сервере
- хранение памяти и логов внутри компании
- RAG по внутренним документам
- интеграция с закрытыми CRM и 1С
- развертывание n8n и workflow-автоматизации
- работа с локальной LLM
- контроль данных и доступов
- снижение зависимости от SaaS-поставщиков
Связанные термины
Частые вопросы
Что такое self-hosted простыми словами?
Это когда сервис или AI-агент установлен на вашем сервере или инфраструктуре, а не используется только как внешний облачный сервис.
Self-hosted всегда безопаснее облака?
Нет. Он дает больше контроля, но безопасность зависит от настройки сервера, обновлений, бэкапов, прав доступа, мониторинга и управления секретами.
Когда стоит выбирать self-hosted?
Когда важны контроль данных, закрытый контур, интеграции с внутренними системами, кастомизация, локальные модели или ограничения на передачу данных наружу.
Какие минусы у self-hosted?
Нужно самим отвечать за поддержку, обновления, безопасность, масштабирование, резервные копии, доступность и восстановление после сбоев.
Что обязательно настроить для self-hosted AI-агента?
HTTPS, firewall, закрытые порты, секреты, роли доступа, бэкапы, мониторинг, логи, обновления, health checks и план восстановления.
