Lovable lässt Unternehmen Apps in der eigenen Azure-Subscription betreiben

Was Deploy on Azure leistet

Viele Lovable-Kunden arbeiten nach Unternehmensangaben in Microsoft-Umgebungen: Die Anmeldung erfolgt über Microsoft Entra ID, die Daten liegen in Microsoft 365, Microsoft Fabric und Microsoft Azure, und die Sicherheitsteams legen fest, wo Apps laufen dürfen. Für manche Apps gelten strenge Vorgaben, sodass sowohl die App als auch ihre Daten in der unternehmenseigenen Azure-Subscription bleiben müssen. Genau dafür ist Deploy on Azure gedacht.

Teams bauen weiterhin so in Lovable, wie sie es heute tun. Lovable empfiehlt die Option, wenn Daten in der eigenen Infrastruktur des Kunden bleiben müssen und Apps über das Firmennetzwerk auf interne Systeme zugreifen sollen.

Die Funktion befindet sich in der Private Preview für ausgewählte Enterprise-Kunden. Laut Lovable sind einige Funktionen, die beim Hosting auf Lovable verfügbar sind, noch nicht enthalten. Das Unternehmen arbeitet an vollständiger Funktionsparität.

So funktioniert das Setup

Die Komponenten, die zum Betrieb einer bereitgestellten App nötig sind, liegen in einem dedizierten VNet in der Azure-Subscription des Kunden. Dazu gehören laut Lovable:

• Die Lovable Data Plane auf einem Azure-Kubernetes-Service-Cluster (AKS), einschließlich der Preview-Sandboxes, in denen Builds während der Iteration laufen
• Veröffentlichte Apps, mit statischen Dateien in Azure Blob Storage und dynamischen Anfragen, die über Azure Functions abgewickelt werden
• Die App-Datenbank auf Azure Database for PostgreSQL sowie der App-Speicher in Azure Blob Storage
• Anwendungslogs, die in Azure Blob Storage oder einen Log-Analytics-Workspace fließen können
• Das Connector-Gateway und die Secrets für Integrationen

Lovable weist darauf hin, dass einige dieser Komponenten erst im Lauf der Private Preview ausgerollt werden. Die Account-Teams können bestätigen, was für ein bestimmtes Setup verfügbar ist. Apps greifen per VNet Peering auf interne Systeme wie ein Data Warehouse oder CRM zu, sodass diese Systeme vom öffentlichen Internet getrennt bleiben.

Zum Start legt ein Admin einen neuen Enterprise-Workspace an und wählt Azure als Hosting-Ziel. Lovable erzeugt eine Azure-Resource-Manager-Vorlage, die das Team des Kunden prüft und ausführt. Die Container-Images von Lovable werden in die eigene Azure Container Registry des Kunden kopiert und lassen sich so in derselben Pipeline scannen wie Images anderer Anbieter. Ein Lovable Runner auf einer virtuellen Maschine im VNet richtet die Data Plane ein und verwaltet sie. Außerdem betreut er den PostgreSQL Flexible Server und den von Apps genutzten Blob Storage.

Lovable verwaltet und aktualisiert, was es bereitstellt, während das Infrastrukturteam des Kunden den Azure-Footprint verantwortet. Die Enterprise-Kontrollen gelten weiterhin, darunter SSO und SCIM über Entra ID, standardmäßig auf Workspace-Mitglieder beschränkte Veröffentlichung, ein Sicherheitsscan bei jedem Build und Audit-Logs.

Was bei Lovable bleibt und wie Daten geschützt werden

Die Entwicklungsarbeit bleibt im Multi-Tenant-Dienst von Lovable: der Editor, der Agent, Chat und Projektverlauf sowie Workspace-Einstellungen, Identität und Abrechnung. KI-Modellanfragen, die beim Bauen entstehen, verarbeitet weiterhin der KI-Dienst von Lovable.

App-Daten bleiben im VNet des Kunden unter dessen eigener Azure-Verschlüsselung und Zugriffskontrolle. Die Komponenten in der Subscription des Kunden bauen eine ausschließlich ausgehende, per mTLS verschlüsselte Verbindung zu Lovable auf, sodass Lovable nie eine eingehende Verbindung ins Netzwerk des Kunden benötigt. Chat und Projektverlauf werden im Ruhezustand verschlüsselt. Mit Bring Your Own Key können Admins in den Workspace-Einstellungen einen eigenen Azure-Key-Vault-Schlüssel anbinden und den Zugriff von Lovable jederzeit widerrufen.

Eine von drei Microsoft-Optionen

Lovable stellt Deploy on Azure als einen von drei Wegen vor, in einer Microsoft-Umgebung zu arbeiten, und zwar als jenen, der am meisten innerhalb des Microsoft-Setups des Kunden hält.

• Copilot Managed Runtime (Public Preview): Microsoft hostet die App im Tenant des Kunden. Apps sind ausschließlich intern, liegen hinter der Entra-Anmeldung und übernehmen Tenant-Einstellungen, DLP- und Connector-Kontrollen. Erforderlich sind Copilot Credits oder eine Power-Platform-Premium-Lizenz, und die Datenbank, Secrets und Backend-Funktionen von Lovable sind in diesen Apps nicht verfügbar. Die Option ist als Public Preview für Business- und Enterprise-Workspaces verfügbar.
• Hosting auf Lovable mit Microsoft-Connectors: Apps laufen auf Lovable und arbeiten über Connectors für Microsoft 365, Entra ID, Azure-Verwaltung und Fabric mit vorhandenen Microsoft-Daten. Der Connector-Traffic stammt aus einem festen IP-Bereich, der auf eine Allowlist gesetzt werden kann, und jeder Connector benötigt die Zustimmung eines Admins. Lovable hostet App und Datenbank in der für den Workspace gewählten Region mit dem vollen Funktionsumfang. Lovable gibt an, SOC-2-Type-II-konform zu sein und dass Enterprise-Workspaces keine öffentlichen Projekte anlegen können.

Teams können über mehrere Workspaces hinweg bauen, sodass sich mehr als eine Option gleichzeitig nutzen lässt.

Was das für Unternehmenskunden bedeutet

Für Organisationen, deren Sicherheitsvorgaben verlangen, dass Apps und Daten in der eigenen Azure-Subscription bleiben, bietet die Preview einen Weg, Lovable weiterhin zum Bauen zu nutzen, ohne Laufzeitdaten auf das Hosting von Lovable zu verlagern. Der Zugang ist vorerst begrenzt. Interessierte Kunden können sich an ihr Account-Team wenden oder eine E-Mail an [email protected] schreiben.