Lovable Deploy on Azure: What Moves Into Your Subscription and What Stays With Lovable

What did Lovable announce on October 15?

Lovable introduced Deploy on Azure: apps you build in Lovable run in their own network segment (VNet) inside your Azure subscription. The feature is a private preview, according to Lovable only “for select Enterprise customers”. Lovable does not name a price; access goes through your account team.

Behind this sits the question every app with real data runs into: can an app holding customer or employee data run on a tool vendor's infrastructure? Until now the answer with Lovable was either “pick a region and check the contract” or “export the code and host it yourself”. Azure is now a third option in between.

What runs in your subscription with Deploy on Azure?

App data, app runtime and keys sit with you. According to Lovable, that covers:

• Database: Azure Database for PostgreSQL (Flexible Server)
• Files and logs: Azure Blob Storage, with logs optionally in a Log Analytics workspace
• Published app: static files in Blob Storage, dynamic requests through Azure Functions
• Data plane: the environment where Lovable builds apps and starts previews, on Azure Kubernetes Service (AKS)
• Connector gateway and secrets: credentials for the services your app connects to
• Keys: Azure Key Vault, with your own key (bring your own key, BYOK)

Your components only open outbound connections to Lovable, encrypted with mTLS (TLS where both sides verify each other). Lovable needs no inbound access to your network. The app reaches internal systems such as an ERP through VNet peering, without a detour over the public internet. External connectors still go over the internet.

Setup runs through an ARM template (Azure's infrastructure as code format) that Lovable generates and your team reviews and runs. The container images are first copied into your own container registry so your security team can scan them.

What still stays with Lovable?

Everything you build with stays with Lovable: the editor, the AI agent, chat and project history, workspace settings, sign-in and billing. The most important sentence sits in the fine print of the announcement: “AI model requests made while building are still processed by Lovable's AI service.”

In practice: if you paste real customer data into the chat while building, it still goes to Lovable, no matter where the app runs later. According to the announcement, Lovable encrypts chat history at rest, and with BYOK you can revoke Lovable's access to your key.

On top of that, Lovable itself says that not every feature of the Lovable-hosted version is available on Azure yet and not every component is rolled out in the preview. The text does not say which ones are missing. Clarify that with Lovable before you plan anything.

Which three options do you have, and when does each fit?

For the question “where does the data live?”, Lovable now offers three realistic options:

Lovable Cloud with an EU region: According to the Cloud documentation, you choose between Americas, Europe and Asia Pacific. Country regions such as Germany are only available for Enterprise on request and depending on capacity. The security page states that customer data stays in the selected region by default. On Business and Enterprise plans, Lovable does not use prompts and code for training; on Free and Pro you have to opt out yourself in your account settings.

Self-hosting: According to Lovable's hosting documentation, the frontend runs on any suitable host; on Azure that means Static Web Apps, Container Apps or AKS. Apps created from May 13, 2026 onward use TanStack Start and need a host that runs server code. You move the backend to Supabase, either hosted or self-managed. Lovable explicitly warns: moving only the PostgreSQL database does not bring along auth, file storage, realtime or Edge Functions.

Our take: for an internal tool or a prototype at a mid-sized company, Lovable Cloud with region Europe plus a data processing agreement (DPA) is usually the sensible route. Azure only pays off if you already run an Azure landscape with your own infrastructure team and the app has to talk to internal systems. We recommend self-hosting when the app will live for a long time and you don't want to tie yourself to an Enterprise contract. We walk through the path from prototype to product in our article on MVP development.

Which pitfalls should you check now?

Four points to settle before your next project:

1. Pick the right region the first time. According to the docs, the region cannot be changed once Cloud is enabled, and projects cannot be moved between regions. On Business and Enterprise, an admin can set a mandatory region for new projects. Existing projects stay where they are.
2. Decide on “Sign in with Lovable” on purpose. Since October 15, new login pages in Lovable Cloud apps include this sign-in option by default, next to email and Google, according to the changelog. For an internal tool with company accounts you usually don't want that. Name the login methods you want in your prompt.
3. Export is not a backup. Git sync and the zip download only contain code, no data and no uploaded files. The database export comes as an SQL dump of up to 5 GB, once per project every 24 hours; files you download separately.
4. AI features and connectors run through Lovable. As long as your app uses Lovable's AI features or connectors, those requests go through Lovable and use credits. What an empty balance means for a live app is covered in our article on Lovable credits.

What does this mean for your company?

Deploy on Azure answers the question of where your app data is stored, not where your input goes while you build. For your privacy review you still need the contract with Lovable and the list of subprocessors, which according to the security page Lovable provides on request. Whether that is enough for your case is for your data protection officer to decide, not a blog post.

Concretely, for the coming weeks:

• You already use Lovable: check the Cloud settings of each project to see which region is set. Secure new projects with the mandatory region.
• You are planning an app with employee data: use test data instead of real data in the chat, and define the login methods in your first prompt.
• You have Azure and an Enterprise contract within reach: request the preview and ask for the list of missing features first.

If you are unsure which option fits your app, see how we build web apps with Lovable and Supabase, or talk to us directly.