Andrea OrrĂč

How do you manage Dev vs Prod in Lovable?

Hey everyone! 👋

I’ve been using Lovable to build and test ideas, and it’s been awesome. I’ve never coded before, but I can create and deploy stuff fast, sometimes I even ask ChatGPT for tips on GitHub or Supabase. 😅

But I have a question: how do you handle development vs production?

Code: I can use GitHub branches (main / dev ).

Database: I’m on Supabase, but it’s just one database. If I add tables or columns in dev and something goes wrong, how do I roll back without hurting production?

Do you


  • Duplicate the entire database and deploy by hand, maybe with Vercel or similar?

  • Use Lovable to manage separate “dev” and “prod” setups, if so, how?

Or something else?

Would love to hear your simple workflows or tips. Thanks!

146 views

Add a comment

Replies

Best
Salman Malik

Having separate environment branches is great. I use lovable to connect only to my dev branch, and I manually merge code changes to prod after I am happy with it.

You also need to create a supabase dev environment and a prod environment. This can be a little tedious, you'd need to use your cli to make updates to prod. But it's way safer than letting lovable make changes to your production environment directly.

Hope this helps, ping if you have more questions.

Andrea OrrĂč

@maliks786 I see the value of keeping dev and prod Supabase separate
 even if it’s a bit more work, sounds way safer. I’ll start looking into using CLI for that. Thank you :)

Pep Parera

Hola Andrea, realmente es genial, a veces alucina, pero es tremendamente fĂĄcil de usar y puedes crear cualquier cosa que tu imaginacion te de, un 10 por Lovable. Estoy desarrollando Mapoo.app.

Andrea OrrĂč
@tiser @tiser estoy de acuerdo contigo que es sĂșper fĂĄcil de usar y para mĂ­ que nunca he estudiado cĂłdigo es impresionante como me ayuda a “crear” lo que tengo en la cabeza 😊 Es cierto que para crear algo un poco mĂĄs seguro y que no se pueda liar con un prompt hay que saber gestionar los branch en GitHub y supabase! Pero
 vale la pena aprender 😎 Mucho Ă©xito con tu idea 💡
Dhruv Bansal

hey andrea, it's better to not connect github to project until you're all ready, if you want to move in prod, create a backup and perform remix and then connect github and move to prod. if you connect supabase, any changes will not rollback, you'll need to manually edit, or pro tip: use another account, remix project and drop a prompt to create database tables based on required iteams in project. lovable uses mock data in many instances so always cross verify if using API or LLMs

Andrea OrrĂč

@sobarinetech I hadn’t thought about waiting before connecting GitHub or using remix that way, great tip, thanks! Using another account to test safely is also a smart move. As for the mock data, yeah I had noticed that before and I always make sure to remove it so I don’t forget later...eheh

Mohammed Zaid
How I make it work is use lovable to prototype and it usually requires lot of tinkering to get it right according to your requirement. Then once I’m happy with the output I have a separate environment for production, I copy paste the whole code from lovable to production and change the content according to my liking. All major changes are done in lovable itself. All additional minor changes are adjusted in my production environment.
Andrea OrrĂč
@themzaid your system is where you have the best control for sure. In my case I don’t know how to code, so I do everything inside Lovable and try to not move things too much. 😅
Matthieu Crétier

I work with 2 branches: main and prod. Prod is what's deployed. When I am satisfied with the state of main I update prod... using the UI of GitHub tipically.

Hosting in Vercel - it gets only updated when prod is deployed.
aaaand I am using only one DB for now. Very nasty, but I am the only one touching it... and I am extra paranoid.

Andrea OrrĂč
@originalmatth I also thought about using main and prod like you. But the problem for me is the database, if I change something and lovable make a mistake (or my prompt is bad), it’s the same DB as production, and I can’t fix it easily. So it’s a bit risky for me. 😬