Lovable запустила Deploy on AWS: приложения и данные уйдут в VPC клиента

Lovable выпустила в закрытое превью режим Deploy on AWS: корпоративные клиенты теперь могут запускать приложения, собранные в Lovable, внутри собственного AWS-аккаунта. Сборка по-прежнему идёт в облачном редакторе Lovable, а вот рантайм, база данных, хранилище и логи переезжают в выделенный VPC клиента. Первым глобальным enterprise-клиентом стала Deutsche Telekom, которая запустила такую конфигурацию в октябре.

Что именно поселится в вашем аккаунте

До сих пор ответ на вопрос «где работает приложение и где лежат данные» был один: на инфраструктуре Lovable. Для большинства команд этого хватает. Но если внутреннему инструменту нужны данные HR-системы или хранилища, которые по политике не покидают периметр, такое приложение не проходит проверку безопасности. Deploy on AWS закрывает именно этот сценарий.

В VPC клиента Lovable разворачивает следующий набор:

• data plane Lovable на кластере Amazon EKS, включая песочницы предпросмотра, где выполняются сборки во время итераций;
• опубликованные приложения: статика в Amazon S3, динамические запросы обрабатывает AWS Lambda;
• база приложения на Amazon Aurora PostgreSQL и файловое хранилище в S3;
• логи приложений, которые можно отправлять в S3, CloudWatch или другие системы клиента;
• шлюз коннекторов и секреты для интеграций.

Доступ к внутренним системам, например к DWH или CRM, строится через VPC peering, так что эти системы не выходят в публичный интернет. Установку, обслуживание и обновления берёт на себя Lovable: команде клиента не нужно администрировать собственный кластер.

Как устроены установка и доступы

Администратор создаёт новый Enterprise-воркспейс и выбирает размещение в AWS. Lovable генерирует шаблон CloudFormation, команда клиента просматривает его и запускает сама. Стек создаёт VPC, EC2-инстанс для компонента Lovable runner и необходимые ему права. Дальше runner самостоятельно поднимает EKS, Aurora, S3 и остальные сервисы.

Runner служит инструментом управления установкой, при этом клиент видит всё, что он делает. Для настройки, повседневного обслуживания и вывода из эксплуатации используются отдельные IAM-роли, то есть принцип минимальных привилегий соблюдается на каждом этапе. Единственный внешний хост, с которым общается runner, это его endpoint у Lovable. Каждое обновление компонентов поставляется как версионированный Helm chart со ссылками на подписанные контейнерные образы в реестре клиента.

Корпоративные средства контроля распространяются и на такой режим: SSO и SCIM, публикация только для участников воркспейса по умолчанию, проверка безопасности при каждой сборке и аудит-логи.

Где проходит граница данных

Данные приложений остаются в VPC клиента под его собственным шифрованием и политиками доступа AWS. Компоненты в аккаунте подключаются к Lovable наружу через туннель с mTLS, и входящее соединение в сеть клиента Lovable не требуется. История чатов и проектов хранится на стороне Lovable в зашифрованном виде. Через bring your own key админ подключает собственный ключ AWS KMS в настройках воркспейса и может в любой момент отозвать доступ Lovable.

Граница при этом проходит не по всему продукту. В мультитенантном сервисе Lovable остаются редактор, агент, чат, история проектов, настройки воркспейса, идентификация и биллинг. Запросы к ИИ-моделям во время сборки тоже обрабатывает сервис Lovable. Если промпты или контекст проекта попадают под ограничения, это нужно проверить отдельно.

Deutsche Telekom подключила Lovable через внутреннюю ИИ-платформу AskT. По словам компании, там уже создали тысячи приложений и прототипов, а самые чувствительные нагрузки требуют, чтобы приложения и данные не покидали собственную сеть. Сейчас с глобальной HR-командой Telekom строит платформы для сотрудников.

С чего начинать

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

Практичный порядок действий такой. Сначала составьте список приложений, которым нужны закрытые данные, и выпишите, что политика требует от места их запуска. Затем покажите архитектуру ИТ и безопасности через аккаунт-менеджера Lovable или напишите на [email protected]. Отдельно проверьте, устраивает ли вас схема, при которой запросы к моделям обрабатывает Lovable. В тот же день компания анонсировала аналогичный вариант для Azure.