The overlooked opportunity with Lovable: how easy it is to choose GDPR-proof email sending.

You picked an EU region for your Lovable/Supabase project. File storage in Frankfurt, hosting in Stockholm, all the good stuff. You feel pretty good about your residency story. Then, a procurement person asks where your transactional emails get processed. The honest answer, for almost every Lovable project, is “I don’t know”.

As an avid vibe coder myself, I am exploring opportunities with tools like Lovable or Claude to build an interface on top of databases/tools that have EU residency at the core of their business. An immediate problem with pretty much any tool I’ve built so far, is how to get emails delivered.

When discussing ’email’ in my short series about Lovable, think of: one-time password emails, registration confirmation, order info email, weekly drilldowns. Anything that makes the app shareable with many requires some involvement with email.

What EU data residency means for a Lovable app

EU data residency isn’t a single setting. It’s a property of every place your application processes personal data. That includes your database, your auth system, your file storage, your email provider, your analytics, and your error tracker. If any one of them routes personal data outside the EU without an appropriate legal basis, you’ve got an international transfer to account for under GDPR Article 44.

A typical Lovable project has four exit points where personal data can leave the EU. Three are easy to get right. One is a quiet trap.

  Database. Supabase offers EU regions (Frankfurt, London, Paris). Pick one at project creation and your user records and application data sit on EU infrastructure.

  Authentication. Supabase Auth runs in your project region. Session tokens, password hashes and OAuth flows stay in the EU.

  File storage. Supabase Storage uses the same regional configuration. Avatars, document uploads and assets stay in-region.

  Email. This is where the wheels come off. Supabase Auth generates the OTP codes, magic links and password-reset tokens, then hands them off to an SMTP provider for delivery. The SMTP provider Lovable nudges you toward, by default and in most of its templates, is Resend.

Resend is a fine company with a fine product. It’s also incorporated in the United States and runs primarily on AWS US-East-1 in northern Virginia. Every transactional email your application sends to a French user, a German user, or a Dutch user gets routed through US infrastructure and processed by a US-based controller.

  Learn why hosting in the EU matters (from a legal perspective)

Why email is often overlooked by app builders

There’s a perfectly understandable reason this gap exists. When founders evaluate residency, they consider where data is stored at rest. Where’s the database? Where’s the file storage? Those questions have quick and simple answers.

Email doesn’t fit that shape. Email is data in motion, outbound by definition, leaving your system whenever it’s sent. So it doesn’t feel like a residency question in the same way a database does.

Under GDPR, it absolutely is one.

The body of a password-reset message contains the user’s email address (a personal identifier), the OTP code (transient but real), and, usually, the user’s name and a contextual reference to their account. When that message is composed, queued, transmitted and logged on your email provider’s infrastructure, your provider is acting as a processor on your behalf. The location of that processing is squarely within the scope of GDPR transfer rules.

If your email provider is US-based, you’re relying on the EU-US Data Privacy Framework or Standard Contractual Clauses to make that transfer lawful. Both are legally workable today. Both have been challenged by privacy regulators and NGOs, and the two predecessor frameworks, Safe Harbor in 2015 and Privacy Shield in 2020, were both struck down by the European Court of Justice.

If you’re building a serious product, especially one you want to sell into EU enterprises, public-sector buyers, healthcare, or fintech, you don’t want your transactional email layer to depend on the durability of those mechanisms.

The cleaner answer: keep the email in the EU to begin with.

Where the common email providers actually sit

Quick reference for the providers Lovable users tend to encounter:

The point isn’t that the US providers are bad. They’re not. They’re good products with thoughtful APIs. But if you’ve gone to the trouble of selecting a Supabase EU region and a European cloud setup, sending your transactional email through a US processor undoes the residency story you’ve built everywhere else.

What “EU-hosted email” should actually mean

Some providers will tell you they have “EU options” while still routing metadata, support traffic or backups through US infrastructure. The marketing page says EU. The diligence reveals otherwise.

The questions worth asking before you commit:

1. Where is the message body processed and stored?
   Including bounce, complaint and engagement logs.
2. Where are the sub-processors?
   A provider can be European on paper but use AWS US for storage, or a US relay for SMTP delivery, under the hood.
3. Where does support access the data from?
   A support engineer in California opening a ticket to debug your message logs is, technically, an international transfer.
4. Where are the backups?
   Disaster-recovery copies often reside in a different region than the primary processing environment.
5. Where is the contracting entity?
   Some “EU options” still contract through a US parent and apply Standard Contractual Clauses to bridge the gap. The contract matters as much as the infrastructure.

For Spotler SendPro, the entire stack sits in the EU. Primary processing, logs, sub-processors, support, and contracting all stay in-region. There’s no US fallback path for message data. It’s the kind of detail that matters when an enterprise customer’s data protection officer is reviewing your subprocessor list.

Spotler SendPro is the email API of choice for many European companies that take email deliverability seriously. Trusted by companies ranging from vibe coding start ups to multinationals sending millions of emails per day, SendPro provides the backbone of your email infrastructure.
Learn more about Spotler SendPro

How to plug SendPro into a Lovable project

This is the practical (and fairly technical) bit. Supabase Auth in your Lovable project needs an SMTP or API-based email provider to deliver OTPs, magic links and confirmation emails. Swapping the default for SendPro takes one prompt and five environment variables.

A prompt that gets it right on the first ask – assuming you have a feature that triggers emails already:

“Replace the email sending in this project with Spotler SendPro using OAuth2. Use API documentation found here: https://flowmailer.com/apidoc/sendpro-api.html“

What Lovable hands back is a clean implementation: an in-memory token cache with a safety margin on the TTL, a 401 auto-retry, and a graceful fallback that logs to console if credentials are missing, so development doesn’t break when you haven’t filled them in yet.

You’ll then need to provide the five environment variables:

• SENDPRO_CLIENT_ID. From your SendPro dashboard, OAuth applications section.
• SENDPRO_CLIENT_SECRET. Paired with the client ID.
• SENDPRO_ACCOUNT_ID. Your account identifier.
• SENDPRO_FROM_EMAIL. Your verified sender address.
• SENDPRO_FROM_NAME. The display name on outgoing messages.

If you’re routing auth-system emails through Supabase’s built-in flows (confirmation, password reset, magic links), point your Supabase project’s SMTP settings at SendPro’s SMTP relay separately, so those messages go through the same provider as your application-level transactional emails. Both paths lead to the same EU infrastructure.

An EU residency checklist for Lovable apps

Before you take a Lovable project to a serious EU customer, walk through these:

1. Supabase region. Confirm your project sits in an EU region. Visible in the Supabase dashboard.
2. Database backups. Check that automated backups are restricted to your region under your current plan.
3. File storage. Confirm Supabase Storage is configured to the same region.
4. Auth. Built into your Supabase project region. No separate action needed.
5. Email provider. Verify your provider’s processing region, sub-processors, and contracting entity. Not just the marketing claim. The data-processing agreement.
6. Analytics. PostHog has an EU instance. Google Analytics does not, in any meaningful sense.
7. Error tracking. Sentry has an EU region. Check yours is set to it.
8. AI APIs. If your app calls OpenAI, Anthropic or similar, those calls route to the US. Document that flow, and look at zero-data-retention agreements where they’re available for sensitive use cases.
9. Hosting. Your Lovable-deployed frontend likely runs on a US-based edge network. Most edge networks process minimal personal data, but it’s worth documenting.
10. DPA. Make sure you have a current data processing agreement signed with each processor on the list. SendPro provides one as standard.

Email sits at number 5 on that list. It’s also the one most likely to catch you out, because it’s the only item where the default suggestion from your AI builder might actively work against your residency story.

The summary, in a sentence

A serious EU-resident Lovable app is entirely possible (Supabase EU, SendPro, an EU analytics and error-tracking stack), but it requires picking each layer deliberately, and the email layer is the one almost everyone misses by default.

If you want to dig into how SendPro fits into a Lovable project specifically, the SendPro product overview covers the EU hosting story, and the API documentation has the OAuth2 details Lovable will work from.