{"id":250101,"date":"2026-05-27T11:40:32","date_gmt":"2026-05-27T09:40:32","guid":{"rendered":"https:\/\/spotler.com\/blog\/eu-residency-for-lovable-emails"},"modified":"2026-06-03T18:13:39","modified_gmt":"2026-06-03T16:13:39","slug":"eu-residency-for-lovable-emails","status":"publish","type":"blog","link":"https:\/\/spotler.com\/en-gb\/blog\/eu-residency-for-lovable-emails","title":{"rendered":"The overlooked opportunity with Lovable: how easy it is to choose GDPR-proof email sending."},"content":{"rendered":"

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”.<\/strong><\/p>\n

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. <\/p>\n

When discussing ’email’ in my short series about Lovable<\/a><\/strong>, 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.<\/p>\n

What EU data residency means for a Lovable app<\/h2>\n

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.<\/p>\n

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.<\/p>\n

<\/i>  Database.<\/strong> Supabase offers EU regions (Frankfurt, London, Paris). Pick one at project creation and your user records and application data sit on EU infrastructure.<\/p>\n

<\/i>  Authentication.<\/strong> Supabase Auth runs in your project region. Session tokens, password hashes and OAuth flows stay in the EU.<\/p>\n

<\/i>  File storage.<\/strong> Supabase Storage uses the same regional configuration. Avatars, document uploads and assets stay in-region.<\/p>\n

<\/i>  Email.<\/strong> 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.<\/p>\n

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.<\/p>\n

<\/i>  Learn why hosting in the EU matters (from a legal perspective)<\/a><\/p>\n

Why email is often overlooked by app builders<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Under GDPR, it absolutely is one.<\/p>\n

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.<\/p>\n

If your email provider is US-based, you’re relying on the EU-US Data Privacy Framework<\/a> 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<\/a>, were both struck down by the European Court of Justice.<\/p>\n

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<\/a> to depend on the durability of those mechanisms.<\/p>\n

The cleaner answer: keep the email in the EU to begin with.<\/strong><\/p>\n

Where the common email providers actually sit<\/h2>\n

Quick reference for the providers Lovable users tend to encounter:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Provider<\/th>\nPrimary hosting<\/th>\nEU-only data option<\/th>\n<\/tr>\n<\/thead>\n
Resend<\/td>\nUS (AWS)<\/td>\nNone at time of writing<\/td>\n<\/tr>\n
SendGrid<\/td>\nUS (Twilio, AWS)<\/td>\nLimited; data still touches US<\/td>\n<\/tr>\n
Mailgun<\/td>\nUS default, EU endpoint available<\/td>\nYes, on a separate endpoint<\/td>\n<\/tr>\n
Postmark<\/td>\nUS default<\/td>\nYes, separate EU data store<\/td>\n<\/tr>\n
Amazon SES<\/td>\nPer-region; default US<\/td>\nYes, if you explicitly use an EU region<\/td>\n<\/tr>\n
Mailjet<\/td>\nFrance (Sinch)<\/td>\nYes, by default<\/td>\n<\/tr>\n
Spotler SendPro<\/td>\nNetherlands (prev. Flowmailer)<\/td>\nYes, by default. EU-only infrastructure.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/div>\n

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<\/a> and a European cloud setup, sending your transactional email through a US processor undoes the residency story you’ve built everywhere else.<\/p>\n

What “EU-hosted email” should actually mean<\/h2>\n

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.<\/p>\n

The questions worth asking before you commit:<\/p>\n

    \n
  1. Where is the message body processed and stored?<\/strong>
    Including bounce, complaint and engagement logs.<\/li>\n
  2. Where are the sub-processors?<\/strong>
    A provider can be European on paper but use AWS US for storage, or a US relay for SMTP delivery, under the hood.<\/li>\n
  3. Where does support access the data from?<\/strong>
    A support engineer in California opening a ticket to debug your message logs is, technically, an international transfer.<\/li>\n
  4. Where are the backups?<\/strong>
    Disaster-recovery copies often reside in a different region than the primary processing environment.<\/li>\n
  5. Where is the contracting entity?<\/strong>
    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.<\/li>\n<\/ol>\n

    For Spotler SendPro, the entire stack sits in the EU<\/a>. 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.<\/p>\n

    Spotler SendPro is the email API of choice<\/strong> 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<\/a><\/strong> <\/i><\/p>\n

    How to plug SendPro into a Lovable project<\/h2>\n

    This is the practical (and fairly technical) bit.<\/strong> 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<\/strong>. <\/p>\n

    \n
    \"\"
    Lovable’s (partial) reponse when asked “How does the Spotler SendPro integration work?” <\/em><\/figcaption><\/figure>\n<\/div>\n

    A prompt that gets it right on the first ask – assuming you have a feature that triggers emails already:<\/p>\n

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

    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.<\/p>\n

    You’ll then need to provide the five environment variables:<\/p>\n