Shorterst version coming soon, if you want to trade-off controlling Supabase: Lovable Cloud will support it soon. Currently available for beta testers.
Amazing article on branching with AI tools! This overcomes one of the biggest issues in using AI coding - Git versioning isn’t enough. You need this article to fully sever the dependencies beyond the code in Git. Thank you!
Thanks, Amy. This was a problem I personally faced. Lovable just mentions "branching" but I couldn't find any article on how to to make it work it end-to-end.
This involved many failed attempts and suboptimal solutions which I didn't present.
Hi @Paweł, thanks for the very insightful article, I had a couple of quick questions:
1. About Migration File Naming and Archiving (Section 2)
I noticed all my migration files already follow the timestamped naming format (e.g. 20250714123000_add_users.sql), and Supabase processes them correctly.
• Why did you specifically call out the naming convention — is there a scenario where this breaks?
• Also, could you clarify why you mention renaming or moving old migrations to an archive folder?
Wouldn’t we want to keep all migration history intact when working across environments or duplicating the DB?
2. About Supabase Project References (Section 1.7)
• Is the issue in 1.7 mainly about turning the Supabase project ID or URL into a configurable variable?
• If yes, what exactly is the “in-scope variable” that gets reused across environments like production or test?
• If not, how does your frontend or edge functions know which Supabase project to connect to when switching branches?
Great walkthrough.
This seems like an existing project?
How do you seperate the PROD (with database and edge functions) from DEV for a new project?
Short version: https://www.linkedin.com/posts/pawel-huryn_most-vibe-coders-test-on-production-great-activity-7410055494935089154-E6_i
Full version: https://www.productcompass.pm/p/lovable-accredia-digital-certificates
Shorterst version coming soon, if you want to trade-off controlling Supabase: Lovable Cloud will support it soon. Currently available for beta testers.
Amazing article on branching with AI tools! This overcomes one of the biggest issues in using AI coding - Git versioning isn’t enough. You need this article to fully sever the dependencies beyond the code in Git. Thank you!
Thanks, Amy. This was a problem I personally faced. Lovable just mentions "branching" but I couldn't find any article on how to to make it work it end-to-end.
This involved many failed attempts and suboptimal solutions which I didn't present.
I never would have guessed the dependencies and hard-coding until seeing your experience. Thank you for the time figuring this out!
Hi @Paweł, thanks for the very insightful article, I had a couple of quick questions:
1. About Migration File Naming and Archiving (Section 2)
I noticed all my migration files already follow the timestamped naming format (e.g. 20250714123000_add_users.sql), and Supabase processes them correctly.
• Why did you specifically call out the naming convention — is there a scenario where this breaks?
• Also, could you clarify why you mention renaming or moving old migrations to an archive folder?
Wouldn’t we want to keep all migration history intact when working across environments or duplicating the DB?
2. About Supabase Project References (Section 1.7)
• Is the issue in 1.7 mainly about turning the Supabase project ID or URL into a configurable variable?
• If yes, what exactly is the “in-scope variable” that gets reused across environments like production or test?
• If not, how does your frontend or edge functions know which Supabase project to connect to when switching branches?
Thanks
far2ed
@Far2edd
1. About Migration File Naming and Archiving
Cool. Perhaps they've changed it :) If that's the case, you can ignore this.
Anton (tech co-founder) liked my post on X and I tagged him in the comments a week ago: https://x.com/PawelHuryn/status/1942171912169234597
2. About Supabase Project References (Section 1.7)
By default:
- The front end knows it from src/integrations/supabase/client.ts
- We're using RLS policies and the front end queries database / edge functions directly
But my setup was different:
- I'm not using RLS or Supabase authentication
- Instead, I've implemented Clerk authentication
- My edge functions verify user role and whether the user can perform specific operation. Only edge functions can access the database.
I'll describe this setup another time. What's important here, Lovable has hardcoded project ID in multiple other places (front end).
Thanks @Pawel, that helps.
Gonna try to make the hardcoded value in supabase/config.toml and anywhere else a GitHub variable to work around during build time.
Curious to discover your Clerk integration and setup!