Lovable、顧客自身のAWSアカウントへのデプロイをプライベートプレビューで開始
Lovableは、一部のエンタープライズ顧客向けに、自社のLovableアプリを完全に自分たちのAWSアカウント内で稼働させられる「Deploy on AWS」をプライベートプレビューとして公開した。制作自体はLovableの通常のエディタで続けられる。
詳細
- 専用VPC: 顧客ごとに自社AWSアカウント内に専用VPCを用意し、アプリに必要な要素を収容
- Amazon EKS上のLovableデータプレーン: 反復作業中にビルドが実行されるプレビュー用サンドボックスも含む
- 公開アプリの構成: 静的アセットはAmazon S3で配信し、動的リクエストはAWS Lambdaが処理
- アプリ用データベース: Amazon Aurora PostgreSQLを使用し、アプリのストレージはAmazon S3に保存
- 顧客管理下のログ出力: ログはS3やCloudWatchなど顧客自身のシステムへ送ることができる
- コネクタゲートウェイと連携用シークレットは顧客のアカウント内に保持され、VPCピアリングによりアプリはデータウェアハウスやCRMなど社内システムにパブリックインターネットを経由せずアクセスできる
- マネージドアップデート: バージョン管理されたHelmチャートと署名済みコンテナイメージを通じて、Lovableが各コンポーネントのインストール・管理・更新を行うため、顧客側のチームが直接運用する必要はない
- セットアップ手順: 管理者がエンタープライズワークスペースを作成してAWSホスティングを選択すると、Lovableが生成したCloudFormationスタックが実行され、「Lovable runner」となるEC2インスタンスがEKS・Aurora PostgreSQL・S3などを、セットアップ・保守・廃棄それぞれ専用のIAMロールを使って順にプロビジョニングする
- セキュリティ: 顧客アカウント内の各コンポーネントはmTLS経由でLovable側へアウトバウンド接続するのみで、インバウンドアクセスは不要。SSO・SCIM、公開はワークスペースメンバーに限定、ビルドごとのセキュリティスキャン、監査ログといった既存のエンタープライズ統制機能はそのまま適用され、アプリデータは保存時に暗号化される。BYOK(自己管理鍵)を使う顧客は自前のAWS KMSキーを接続し、いつでもLovableのアクセス権を取り消せる
- 中央集約されたまま残る要素: エディタ本体、エージェント、チャット・プロジェクト履歴、ワークスペース設定、ID管理、課金はLovableのマルチテナントサービス側に残り、制作中のAIモデルへのリクエストも引き続きLovable自身のAIサービスが処理する
- 第一号顧客: ドイツテレコムが自社AWSアカウント上でLovableアプリを稼働させており、同社Chief AI OfficerのKartik Sheth氏は「この方式でLovableを導入する世界初のグローバル企業であることを誇りに思う」とコメント
- 提供状況: 一部のエンタープライズ顧客向けプライベートプレビューで、Lovableは標準ホスティングとの機能完全一致を目指して開発を継続中。関心のある顧客は担当アカウントチームへの連絡、またはbyoc@lovable.devへのメールで問い合わせ可能
その後
「Deploy on AWS」は、AIアプリビルダー導入における企業側の典型的な障壁、すなわちセキュリティ・コンプライアンス部門が機密データを扱う本番ワークロードを自社が所有・管理するインフラ内で稼働させることを求める、という課題に対応するものだ。制作体験はLovableのホスト型エディタに残しつつ、実行環境・データ・シークレットは顧客自身のAWSアカウントへ移し、さらにBYOK暗号化まで提供することで、Lovableは従来フルホスト型のビルダーでは手が届かなかったエンタープライズのワークロードを取り込もうとしている。ドイツテレコムの先行導入はその参照事例となる。