Where Does Your Lovable App's Data Actually Live?

"Where does the data live?" is the first question in every serious procurement review and the first question every DPO asks. On Lovable the answer is more precise than most platforms allow — and more nuanced than "the EU region" on its own. This guide is engineering practice, not legal advice; it is written for the person who has to fill in the questionnaire.

Lovable Cloud's regions

Lovable Cloud supports regional hosting in three regions:

• European Union
• United States
• Australia

When you select a region, application data at rest lives in that region and does not move across regions by default. There is no background replication to a different geography, no silent failover to a region you didn't opt into. The current authoritative statement lives on lovable.dev/security; treat it — not this article — as the source of truth on the day you sign the DPA.

What "residency" actually covers

"Data residency" is a shorthand that hides three distinct states of data, each with its own residency question:

• At rest. Rows in the database, files in object storage, backups. This is what the region setting controls. It is the state most procurement questionnaires are asking about.
• In transit. Data moving between your users, the edge network, and the origin. TLS is table stakes; the geography of the endpoint the traffic terminates at also matters (see the leaks section below).
• In processing. Data sitting in the memory of a service that is acting on it — an AI model scoring a prompt, an error-tracking service parsing a stack trace, an analytics service aggregating an event stream. "In-processing" residency is the state most often overlooked, because it is transient by design.

A defensible residency posture has an answer for all three, not just the first.

The five places data still leaves your region

Regional hosting handles the primary state. Peripheral services on any modern application create their own residency footprint. On a Lovable-hosted application, the five flows to map explicitly are:

1. Transactional email. Password resets, magic links, notification emails. The recipient address and the message body leave your database the moment they're handed to the mail provider. If the provider's sending infrastructure is in a different region, the email content is processed there.
2. Error tracking. Stack traces carry whatever was in memory at the moment of the crash — request payloads, headers, user identifiers, sometimes personal data by accident. The error-tracking service's ingestion region is where those traces are processed and stored.
3. Analytics. Event streams routinely include user IDs, IP addresses and funnel context. The analytics vendor's collector endpoint and its warehouse region are both residency-relevant.
4. AI / model API calls. A prompt containing personal data is a disclosure to the model provider. The endpoint region, the retention policy and whether the endpoint is a zero-retention variant all belong in your record. This is often the largest cross-region flow in a modern application, and the one most likely to change as providers add regions.
5. Edge / CDN termination. Static assets, API traffic and (increasingly) server-rendered HTML terminate at edge points-of-presence around the world. A request from an EU user often terminates at an EU PoP and stays in region; the same request from a traveller may terminate elsewhere. The CDN's TLS-termination behaviour is a residency question, not just a performance one.

None of these five are unique to Lovable — they exist on every stack — but they are the flows that a "we're in the EU region" answer alone will fail to cover. The current sub-processor list, including where each of these services sits, is on Lovable's Trust Center.

Documenting the flows for a procurement questionnaire

A procurement questionnaire is not asking for a diagram — it's asking whether you can answer, per data category, where the data goes. A workable format is a short table with one row per flow:

• Data category (customer PII, message content, uploads, telemetry).
• Primary storage region (the region you selected in Lovable Cloud).
• Peripheral services touching this category (from the five above).
• Each peripheral service's processing region.
• Transfer mechanism if a region falls outside the EEA (SCCs, adequacy decision).
• Retention window in each location.

Keep the table versioned in the same repository as the code. When a sub-processor changes, the table changes in the same pull request. This is the only cadence that stays true as the product grows, and it is what turns "we selected the EU region" into an answer a procurement team can accept.

Choosing a region per customer, not per company

Companies with a global footprint often make the same early mistake: pick one region for the whole business and accept a cross-region transfer for every customer who lives elsewhere. It works until a US healthcare buyer asks for in-region processing, or an Australian retailer needs latency their EU-hosted instance can't deliver.

Arino One deploys per-region globally instead. Every client runs on a dedicated, single-tenant instance in the region that fits their regulatory scope and their users' latency — EU by default, with North America and APAC available. GDPR-native controls, consent capture and erasure ship in every instance regardless of region, because building to the strictest standard once and then deploying it everywhere is cheaper and safer than maintaining three parallel stacks.

See Global coverage for the regional deployment detail and EU data residency for the EU-specific alignment.

This guide is engineering practice, not legal advice. Verify every residency claim against Lovable's Trust Center at the time you sign a DPA — sub-processor lists and regional offerings are living documents.