Lovable lanza Deploy on AWS: las aplicaciones y los datos se ejecutan en la VPC del cliente

Lovable ha lanzado en private preview el modo Deploy on AWS: los clientes corporativos ya pueden ejecutar las aplicaciones creadas en Lovable dentro de su propia cuenta de AWS. La compilación sigue haciéndose en el editor en la nube de Lovable, pero el runtime, la base de datos, el almacenamiento y los logs se trasladan a una VPC dedicada del cliente. El primer cliente enterprise global ha sido Deutsche Telekom, que puso en marcha esta configuración en octubre.

Qué se instalará exactamente en tu cuenta

Hasta ahora, la respuesta a la pregunta «dónde funciona la aplicación y dónde se almacenan los datos» era una sola: en la infraestructura de Lovable. A la mayoría de los equipos les basta. Pero si una herramienta interna necesita datos de un sistema de RR. HH. o de un almacén que, según la política de la empresa, no pueden salir del perímetro, esa aplicación no supera la revisión de seguridad. Deploy on AWS cubre precisamente ese caso.

En la VPC del cliente, Lovable despliega el siguiente conjunto de componentes:

• el data plane de Lovable en un clúster de Amazon EKS, incluidos los sandboxes de vista previa donde se ejecutan las compilaciones durante las iteraciones;
• las aplicaciones publicadas: contenido estático en Amazon S3 y solicitudes dinámicas procesadas por AWS Lambda;
• la base de datos de la aplicación en Amazon Aurora PostgreSQL y el almacenamiento de archivos en S3;
• los logs de las aplicaciones, que pueden enviarse a S3, CloudWatch u otros sistemas del cliente;
• la pasarela de conectores y los secretos para las integraciones.

El acceso a sistemas internos, como un DWH o un CRM, se establece mediante VPC peering, de modo que esos sistemas no salen a internet público. Lovable se encarga de la instalación, el mantenimiento y las actualizaciones: el equipo del cliente no tiene que administrar su propio clúster.

Cómo funcionan la instalación y los accesos

El administrador crea un nuevo workspace Enterprise y elige el alojamiento en AWS. Lovable genera una plantilla de CloudFormation que el equipo del cliente revisa y lanza por su cuenta. La pila crea la VPC, una instancia EC2 para el componente Lovable runner y los permisos que este necesita. A partir de ahí, el runner levanta por sí solo EKS, Aurora, S3 y el resto de los servicios.

El runner actúa como herramienta de gestión de la instalación, y el cliente ve todo lo que hace. Para la configuración, el mantenimiento diario y la retirada del servicio se usan roles IAM independientes, de modo que el principio de mínimo privilegio se respeta en cada etapa. El único host externo con el que se comunica el runner es su endpoint en Lovable. Cada actualización de componentes se entrega como un Helm chart versionado, con referencias a imágenes de contenedor firmadas en el registro del cliente.

Los controles corporativos también se aplican en este modo: SSO y SCIM, publicación por defecto solo para los miembros del workspace, revisión de seguridad en cada compilación y logs de auditoría.

Dónde está el límite de los datos

Los datos de las aplicaciones permanecen en la VPC del cliente, bajo su propio cifrado y las políticas de acceso de AWS. Los componentes de la cuenta se conectan hacia fuera con Lovable mediante un túnel con mTLS, y Lovable no necesita ninguna conexión entrante a la red del cliente. El historial de chats y proyectos se guarda cifrado en el lado de Lovable. Con bring your own key, el administrador conecta su propia clave de AWS KMS en la configuración del workspace y puede revocar el acceso de Lovable en cualquier momento.

El límite, sin embargo, no abarca todo el producto. En el servicio multitenant de Lovable permanecen el editor, el agente, el chat, el historial de proyectos, la configuración del workspace, la identidad y la facturación. Las solicitudes a los modelos de IA durante la compilación también las procesa el servicio de Lovable. Si los prompts o el contexto del proyecto están sujetos a restricciones, hay que comprobarlo por separado.

Deutsche Telekom conectó Lovable a través de su plataforma interna de IA, AskT. Según la compañía, ya se han creado allí miles de aplicaciones y prototipos, y las cargas más sensibles exigen que las aplicaciones y los datos no salgan de la red propia. Ahora, junto con el equipo global de RR. HH. de Telekom, está construyendo plataformas para los empleados.

Por dónde empezar

El modo solo está disponible para un grupo selecto de clientes Enterprise, y todavía le faltan algunas funciones del hosting de Lovable: no hay paridad completa. El hosting en Lovable sigue siendo la opción por defecto y, según la descripción, muchas organizaciones mantendrán dos tipos de workspaces: uno en su propio AWS para los datos sensibles y los demás en Lovable.

El orden práctico de actuación es este. Primero, haz una lista de las aplicaciones que necesitan datos cerrados y anota qué exige la política en cuanto al lugar de ejecución. Después, presenta la arquitectura de TI y seguridad a través del account manager de Lovable o escribe a [email protected]. Comprueba por separado si te encaja el esquema en el que Lovable procesa las solicitudes a los modelos. El mismo día, la compañía anunció una opción equivalente para Azure.