Lovable Deploy on Azure: Was in deine Subscription wandert und was weiter bei Lovable bleibt

Was hat Lovable am 15. Oktober angekündigt?

Lovable hat Deploy on Azure vorgestellt: Apps, die du in Lovable baust, laufen dabei in einem eigenen Netzwerkbereich (VNet) in deiner Azure-Subscription. Die Funktion ist eine Private Preview, laut Lovable nur „for select Enterprise customers“. Einen Preis nennt Lovable nicht, Zugang gibt es über das Account-Team.

Dahinter steht die Frage, die bei jeder App mit echten Daten kommt: Darf eine App mit Kunden- oder Personaldaten auf der Infrastruktur eines Tool-Anbieters laufen? Bisher hieß die Antwort bei Lovable entweder „Region wählen und Vertrag prüfen“ oder „Code exportieren und selbst hosten“. Azure ist jetzt ein dritter Weg dazwischen.

Was läuft bei Deploy on Azure in deiner Subscription?

App-Daten, App-Betrieb und Schlüssel liegen bei dir. Laut Lovable sind das:

• Datenbank: Azure Database for PostgreSQL (Flexible Server)
• Dateien und Logs: Azure Blob Storage, Logs wahlweise in einem Log-Analytics-Workspace
• Veröffentlichte App: statische Dateien in Blob Storage, dynamische Anfragen über Azure Functions
• Data Plane: die Umgebung, in der Lovable Apps baut und Vorschauen startet, auf Azure Kubernetes Service (AKS)
• Connector-Gateway und Secrets: Zugangsdaten zu angebundenen Diensten
• Schlüssel: Azure Key Vault, mit eigenem Schlüssel (Bring Your Own Key, kurz BYOK)

Deine Komponenten bauen nur ausgehende, per mTLS (gegenseitig geprüftes TLS) verschlüsselte Verbindungen zu Lovable auf. Lovable braucht also keinen eingehenden Zugang in dein Netz. Interne Systeme wie ein ERP erreicht die App über VNet-Peering, also ohne Umweg über das öffentliche Internet. Externe Connectoren laufen weiter über das Internet.

Die Einrichtung läuft über ein ARM-Template (Azures Format für Infrastruktur als Code), das Lovable erzeugt und dein Team prüft und ausführt. Die Container-Images landen vorher in deiner eigenen Container Registry, damit dein Security-Team sie scannen kann.

Was bleibt trotzdem bei Lovable?

Alles, womit du baust, bleibt bei Lovable: Editor, KI-Agent, Chat- und Projektverlauf, Workspace-Einstellungen, Logins und Abrechnung. Der wichtigste Satz steht im Kleingedruckten der Ankündigung: „AI model requests made while building are still processed by Lovable's AI service.“

Praktisch heißt das: Wer beim Bauen echte Kundendaten in den Chat kopiert, schickt sie weiter an Lovable, egal wo die App später läuft. Den Chatverlauf verschlüsselt Lovable laut Ankündigung im Ruhezustand, mit BYOK kannst du Lovable den Zugriff auf deinen Schlüssel entziehen.

Dazu kommt: Lovable schreibt selbst, dass auf Azure noch nicht alle Funktionen der Lovable-Variante verfügbar sind und nicht alle Komponenten in der Preview ausgerollt sind. Welche fehlen, steht nicht im Text. Das musst du im Gespräch mit Lovable klären, bevor du planst.

Welche drei Wege gibt es, und wann passt welcher?

Für die Frage „Wo liegen die Daten?“ gibt es bei Lovable jetzt drei realistische Wege:

Lovable Cloud mit EU-Region: Laut Cloud-Dokumentation wählst du zwischen Americas, Europe und Asia Pacific. Länderregionen wie Deutschland gibt es nur für Enterprise auf Anfrage und je nach Kapazität. Die Sicherheitsseite sagt, dass Kundendaten standardmäßig in der gewählten Region bleiben. Auf Business- und Enterprise-Plänen verwendet Lovable Prompts und Code nicht zum Training, auf Free und Pro musst du das in den Kontoeinstellungen selbst abschalten.

Selbst hosten: Laut Lovables Hosting-Dokumentation läuft das Frontend auf jedem passenden Host, bei Azure etwa Static Web Apps, Container Apps oder AKS. Apps, die ab dem 13. Mai 2026 angelegt wurden, nutzen TanStack Start und brauchen einen Host, der Servercode ausführt. Das Backend ziehst du zu Supabase, gehostet oder selbst betrieben. Lovable warnt dabei ausdrücklich: Wer nur die PostgreSQL-Datenbank umzieht, hat Login, Dateispeicher, Realtime und Edge Functions noch nicht mitgenommen.

Unsere Einschätzung: Für ein internes Tool oder einen Prototyp im Mittelstand ist Lovable Cloud mit Region Europe plus Auftragsverarbeitungsvertrag meist der vernünftige Weg. Azure lohnt sich erst, wenn du ohnehin eine Azure-Landschaft mit eigenem Infrastruktur-Team hast und die App an interne Systeme muss. Selbst hosten empfehlen wir, wenn die App länger lebt und du dich nicht an einen Enterprise-Vertrag binden willst. Den Ablauf vom Prototyp bis zum Produkt beschreiben wir im Artikel MVP entwickeln.

Welche Fallstricke solltest du jetzt prüfen?

Vier Punkte, die du vor dem nächsten Projekt klären solltest:

1. Region beim ersten Aktivieren richtig wählen. Laut Doku lässt sich die Region nach dem Aktivieren von Cloud nicht mehr ändern, und Projekte lassen sich nicht zwischen Regionen verschieben. Auf Business und Enterprise kann ein Admin eine Pflichtregion für neue Projekte setzen. Bestehende Projekte bleiben, wo sie sind.
2. „Sign in with Lovable“ bewusst entscheiden. Seit dem 15. Oktober bauen neue Login-Seiten in Lovable-Cloud-Apps laut Changelog diese Anmeldung standardmäßig ein, neben E-Mail und Google. Für ein internes Tool mit Firmenkonten willst du das meist nicht. Nenne im Prompt die Login-Methoden, die du haben willst.
3. Export heißt nicht Datensicherung. Git-Sync und der Zip-Download enthalten nur den Code, keine Daten und keine hochgeladenen Dateien. Den Datenbank-Export gibt es als SQL-Dump bis 5 GB, einmal pro Projekt alle 24 Stunden, Dateien lädst du separat herunter.
4. KI-Funktionen und Connectoren laufen über Lovable. Solange deine App Lovables KI-Funktionen oder Connectoren nutzt, laufen diese Anfragen über Lovable und verbrauchen Credits. Was ein leeres Guthaben für eine Live-App bedeutet, steht in unserem Artikel zu Lovable Credits.

Was heißt das für dein Unternehmen?

Deploy on Azure beantwortet die Frage nach dem Speicherort der App-Daten, nicht die Frage, wohin deine Eingaben beim Bauen gehen. Für die Datenschutzprüfung brauchst du deshalb weiterhin den Vertrag mit Lovable und die Liste der Unterauftragnehmer, die Lovable laut Sicherheitsseite auf Anfrage herausgibt. Ob das für deinen Fall reicht, klärt deine Datenschutzbeauftragte, nicht ein Blogartikel.

Konkret für die nächsten Wochen:

• Du nutzt Lovable schon: In den Cloud-Einstellungen jedes Projekts nachsehen, welche Region eingestellt ist. Neue Projekte über die Pflichtregion absichern.
• Du planst eine App mit Personaldaten: Testdaten statt Echtdaten in den Chat, Login-Methoden im ersten Prompt festlegen.
• Du hast Azure und einen Enterprise-Vertrag in Reichweite: Preview anfragen und vorher die Liste der fehlenden Funktionen verlangen.

Wenn du unsicher bist, welcher Weg zu deiner App passt, schau dir an, wie wir Web-Apps mit Lovable und Supabase bauen, oder sprich uns direkt an.