Lovable lance Deploy on AWS : applications et données hébergées dans le VPC du client

Lovable a lancé en préversion privée le mode Deploy on AWS : les clients entreprise peuvent désormais exécuter les applications construites dans Lovable au sein de leur propre compte AWS. La génération reste assurée par l'éditeur cloud de Lovable, mais le runtime, la base de données, le stockage et les logs migrent vers un VPC dédié du client. Deutsche Telekom est le premier client enterprise mondial : elle a mis en service cette configuration en octobre.

Ce qui s'installe concrètement dans votre compte

Jusqu'ici, la réponse à la question « où tourne l'application et où se trouvent les données » était unique : sur l'infrastructure de Lovable. Pour la plupart des équipes, cela suffit. Mais si un outil interne a besoin de données issues d'un système RH ou d'un entrepôt de données qui, selon la politique de l'entreprise, ne quittent pas le périmètre, l'application ne passe pas la validation de sécurité. Deploy on AWS cible précisément ce cas.

Dans le VPC du client, Lovable déploie l'ensemble suivant :

• le data plane de Lovable sur un cluster Amazon EKS, y compris les sandboxes de prévisualisation où s'exécutent les builds pendant les itérations ;
• les applications publiées : statique sur Amazon S3, requêtes dynamiques traitées par AWS Lambda ;
• la base de l'application sur Amazon Aurora PostgreSQL et le stockage de fichiers sur S3 ;
• les logs des applications, qui peuvent être envoyés vers S3, CloudWatch ou d'autres systèmes du client ;
• la passerelle de connecteurs et les secrets pour les intégrations.

L'accès aux systèmes internes, par exemple un DWH ou un CRM, passe par du VPC peering : ces systèmes n'ont donc pas besoin d'être exposés sur l'internet public. Lovable prend en charge l'installation, la maintenance et les mises à jour : l'équipe du client n'a pas à administrer son propre cluster.

Installation et accès : comment ça fonctionne

L'administrateur crée un nouveau workspace Enterprise et choisit un hébergement dans AWS. Lovable génère un template CloudFormation que l'équipe du client examine, puis lance elle-même. La stack crée le VPC, une instance EC2 pour le composant Lovable runner et les droits dont il a besoin. Ensuite, le runner déploie lui-même EKS, Aurora, S3 et les autres services.

Le runner sert d'outil de pilotage de l'installation, et le client voit tout ce qu'il fait. Des rôles IAM distincts sont utilisés pour la configuration, la maintenance courante et la mise hors service, ce qui applique le principe du moindre privilège à chaque étape. Le seul hôte externe avec lequel le runner communique est son endpoint chez Lovable. Chaque mise à jour des composants est livrée sous forme de Helm chart versionné, avec des références vers des images de conteneurs signées dans le registre du client.

Les contrôles d'entreprise s'appliquent aussi à ce mode : SSO et SCIM, publication réservée par défaut aux membres du workspace, vérification de sécurité à chaque build et logs d'audit.

Où passe la frontière des données

Les données des applications restent dans le VPC du client, sous son propre chiffrement et ses politiques d'accès AWS. Les composants du compte se connectent à Lovable vers l'extérieur via un tunnel mTLS, et Lovable n'a pas besoin d'une connexion entrante dans le réseau du client. L'historique des conversations et des projets est stocké côté Lovable sous forme chiffrée. Grâce au bring your own key, l'administrateur connecte sa propre clé AWS KMS dans les paramètres du workspace et peut à tout moment révoquer l'accès de Lovable.

La frontière ne couvre toutefois pas l'ensemble du produit. L'éditeur, l'agent, le chat, l'historique des projets, les paramètres du workspace, l'identification et la facturation restent dans le service multitenant de Lovable. Les requêtes vers les modèles d'IA pendant la génération sont elles aussi traitées par le service de Lovable. Si les prompts ou le contexte du projet relèvent de restrictions, il faut le vérifier séparément.

Deutsche Telekom a connecté Lovable via sa plateforme d'IA interne AskT. Selon l'entreprise, des milliers d'applications et de prototypes y ont déjà été créés, et les charges les plus sensibles exigent que les applications et les données ne quittent pas son propre réseau. Telekom construit actuellement, avec son équipe RH mondiale, des plateformes destinées aux employés.

Par où commencer

Le mode n'est accessible qu'à une sélection de clients Enterprise, et une partie des fonctions d'hébergement de Lovable y fait encore défaut : il n'y a pas de parité complète. L'hébergement chez Lovable reste l'option par défaut et, d'après la description, de nombreuses organisations garderont deux types de workspaces : l'un dans leur propre AWS pour les données sensibles, les autres chez Lovable.

Voici un ordre d'action pragmatique. Commencez par dresser la liste des applications qui ont besoin de données confidentielles et notez ce que la politique de l'entreprise exige quant à leur lieu d'exécution. Présentez ensuite l'architecture aux équipes IT et sécurité via votre account manager Lovable, ou écrivez à [email protected]. Vérifiez à part si le schéma dans lequel Lovable traite les requêtes vers les modèles vous convient. Le même jour, l'entreprise a annoncé une variante équivalente pour Azure.