PaaS в России 2026: как меняется рынок и как выбирать платформу для продуктовой команды

В 2024–2025 годах российский рынок управляемых платформ для запуска приложений прошёл стадию активного тестирования: платформы набирали пользователей, обрастали механизмами доступности, а команды присматривались и пробовали. Год назад мы опубликовали первый обзор этого рынка — «Хостинг Docker-контейнеров в 2025: тренд на развитие платформ». Этот материал — его обновление: что изменилось, кто остался на рынке, кто пришёл, и по каким критериям платформу имеет смысл выбирать сейчас.

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

Эволюция рынка: от эксперимента к рабочему инструменту

За год рынок заметно сдвинулся в сторону специализированных решений. Если раньше типовой сценарий запуска контейнеризированного приложения выглядел как «арендовать VPS и настроить всё руками», то теперь устойчиво растёт спрос на платформы с абстракцией инфраструктуры. Причины понятны: стандартизация формата OCI-образов, развитие инструментов автоматической сборки, потребность в прозрачной тарификации и требования к локализации данных.

Платформы, закрывающие полный цикл «push в репозиторий → работающий HTTP-эндпоинт», стали стандартным способом сократить время вывода сервиса в продакшен. Параллельно выросли требования к наблюдаемости: логи, метрики и алертинг всё чаще ожидаются как часть базовой конфигурации сервиса, а не как отдельный стек, который нужно разворачивать самостоятельно.

Ландшафт платформ: статус участников прошлого обзора

• Amvera — независимый PaaS, продолжает развиваться. Деплой из Git, модель «один контейнер = один проект», набор преднастроенных сервисов (PostgreSQL, RabbitMQ, n8n, NocoDB и др.), бонус 111 ₽ при регистрации. Профиль — быстрый запуск одиночных приложений и ботов.
• Dockerhosting — контейнерный хостинг без деплоя из Git, есть бесплатный тариф для одного бота. Ниша — простой хостинг ботов и одиночных контейнеров.
• L1veStack — на момент подготовки обзора платформа не работает. Если вы остались без площадки, миграция типового сервиса на другую платформу обычно занимает 1–3 рабочих дня — чек-лист в конце статьи.
• Onreza — новый PaaS на рынке: деплой из Git, бесплатный пробный тариф без ограничений.
• Dockhost — наша платформа, поэтому здесь без описания: ниже отдельный раздел и строка в сравнительной таблице.

Отдельная оговорка: мы сравниваем только специализированные PaaS. Универсальные облака — Yandex Cloud, VK Cloud, Cloud.ru, MWS, Selectel, Timeweb — другой класс решений: там PaaS-модули обычно являются надстройкой над классической IaaS-инфраструктурой, и сравнивать их с узкоспециализированными платформами по нашим критериям некорректно.

Смена профиля проектов

Мы видим это по проектам, которые деплоят у нас: доля многокомпонентных архитектур устойчиво растёт. Если раньше типичный проект — один контейнер, то теперь всё чаще это связка «фронтенд + бэкенд + база данных + брокер сообщений», иногда с отдельными воркерами и планировщиками. Параллельно вырос спрос на изолированные staging-окружения, синхронизированные с основным каналом доставки.

Из этого складываются базовые требования к инфраструктуре:

• Декларативное развёртывание: разработчик описывает окружение в Dockerfile и пушит код — платформа сама собирает образ и раскатывает сервис, без ручного написания YAML-манифестов для кластера.
• Управление секретами: переменные окружения, токены и ключи изолируются на уровне тенанта, с гранулярными правами доступа и инжектированием в рантайм.
• Маршрутизация и контроль доступности: встроенный ingress, health-checks и rollback становятся стандартом, а не опцией.
• Приватные сети: компоненты проекта общаются через изолированную внутреннюю сеть — без ручной настройки сетевого экрана на уровне хоста.

Технологические тренды 2026 года

1. Developer Experience как метрика. Время от коммита до работающего URL, частота релизов и скорость разбора инцидентов напрямую влияют на темп разработки. Выигрывают платформы, которые минимизируют переключения между терминалом, панелью управления и IDE.

2. Observability в базовой конфигурации. Логи с фильтрацией по сервисам, метрики CPU/RAM/RPS/времени ответа/HTTP-статусов, алерты в мессенджеры и почту всё чаще входят в стандартную конфигурацию сервиса. Для большинства команд это устраняет потребность в ручной сборке стека Prometheus + Grafana + Alertmanager. Оговорка: для нетривиальных SLO и сложных правил алертинга внешний стек всё равно может понадобиться — это нормально.

3. Абстракция оркестрации без привязки к вендору. Платформа управляет пулами нод, сетевыми политиками и стратегиями обновления, но образ остаётся стандартным OCI — при изменении требований сервис можно перенести в другую среду без пересборки.

4. Прозрачная экономика владения. Стоимость эксплуатации — это не только строка «CPU + RAM» в счёте, но и время на настройку окружения, мониторинг, резервное копирование и реакцию на инциденты. Для команды без выделенного DevOps операционная нагрузка часто обходится дороже самих ресурсов — платформа, которая забирает эту рутину, снижает скрытые затраты.

Сравнение платформ

Сравниваем по критериям, которые можно проверить по публичной документации и тарифным страницам. Где информации нет в открытых источниках — пишем «не заявлено».

Сравнение актуально на июль 2026 г. и основано на публичной документации и тарифных страницах платформ. Если нашли неточность — напишите нам, поправим.

Как это реализовано у нас, в Dockhost

Теперь от первого лица — по тем же строкам таблицы.

• Git-автодеплой и оркестрация. При пуше в репозиторий платформа читает Dockerfile, собирает OCI-образ и раскатывает rolling-релиз — без простоя при двух и более репликах сервиса. Предыдущие версии сохраняются: откат выполняется мгновенно, без повторной сборки. Доступность контролируется настраиваемыми HTTP-проверками — при сбое контейнер перезапускается автоматически.
• Каталог приложений: 50+ готовых сервисов в один клик — базы данных, брокеры сообщений, AI-инструменты, low-code, мониторинг, CMS.
• Observability из коробки: логи в реальном времени с фильтрацией по сервису и дате (по уровню записи — для структурированных JSON-логов), метрики CPU, RAM, RPS и HTTP-статусов, автоматические уведомления при превышении порогов.
• Командная работа: роли с гранулярными правами, изоляция staging- и production-окружений, централизованные секреты с инжектированием в контейнеры и аудит-логом изменений. Проект можно передать другому владельцу (на его баланс), оставшись в проекте на поддержке.
• Приватная сеть проекта: внутренний трафик между сервисами не покидает изолированный контур проекта; снаружи всё проходит через ingress.
• LLM API: доступ к 40+ моделям (GPT-5, Claude, Qwen, Grok, Llama, Gemini и др.) через OpenAI-совместимый API — в коде достаточно поменять base_url. Токены оплачиваются в рублях с общего баланса, расход виден по каждому сервису. Для чат-ботов, генерации документации, парсинга текстов и превью-ответов это избавляет от отдельных подписок и шлюзов. Честная оговорка: если у вас жёсткие требования к задержке или нужна воспроизводимость ответов (фиксированная версия модели, контроль окружения) — правильнее поднять модель на отдельных GPU-мощностях, и это сценарий вне Dockhost.
• Тарификация: без фиксированных планов — ресурсы (CPU, RAM, диск, сеть) настраиваются под конкретный сервис, списание поминутное, по факту потребления.
• Статус-панель: публичная, с историей инцидентов — status.dockhost.ru.
• Локализация данных: инфраструктура размещена в дата-центрах на территории РФ, обработка персональных данных — в соответствии со 152-ФЗ [подтвердить формулировку перед публикацией; при наличии записи в реестре отечественного ПО — указать].

Когда управляемая платформа (в том числе наша) не подойдёт

Честно про ограничения — класса решений в целом и Dockhost в частности:

• GPU-интенсивные задачи: тренировка и дообучение моделей, высоконагруженный инференс — за этим на выделенные GPU-мощности.
• Кастомные eBPF-программы и глубокая сетевая оптимизация — в мультитенантном PaaS доступ к ядру хоста невозможен.
• Legacy-монолиты с жёсткой привязкой к специфическим модулям ОС или устаревшим сетевым протоколам.
• Образы, которым нужны специфичные настройки ядра (sysctl и т.п.).

В этих сценариях классические VPS или on-prem остаются правильным выбором.

Чек-лист готовности к переходу

• ✅ Приложение построено как стейтлесс-сервисы, состояние вынесено в управляемые БД и кэш?
• ✅ Образы соответствуют OCI и не требуют кастомных настроек ядра?
• ✅ Конфигурация управляется декларативно и совместима с типовыми CI/CD-конвейерами?
• ✅ Команда готова к централизованному хранению секретов и ролевой модели доступа вместо локальных файлов конфигурации?
• ✅ Есть план миграции данных: дампы/снимки, переключение DNS? Время синхронизации зависит от объёма данных и стратегии переключения.

Если ответы «да» — переход типового стейтлесс-сервиса обычно занимает 1–3 рабочих дня без рефакторинга бизнес-логики. Проекты с большими объёмами данных потребуют отдельного планирования миграции БД.

Заключение

Специализированные PaaS в России перешли из категории экспериментов в рабочий инструмент продуктовых команд. Выбор платформы сегодня — это не только цена ресурсов, но и проверяемые вещи: деплой из Git, архитектура проектов, каталог сервисов, командная работа, прозрачность статуса платформы. Сравнивайте по таблице, проверяйте по документации — и если ваш профиль совпадает с нашим, будем рады видеть вас в Dockhost.