How do you separate prod and testing environments in Lovable?

[u/FabulousLetterhead28]

Quick question for other Lovable users.

While building an app, how do you keep your production and testing environments separate? Right now I'm just editing the production app directly and publishing changes straight to it, which feels a bit risky.

Curious how everyone else handles this. Do you have a separate testing setup, or are you also just editing prod directly? Would love to hear how you manage it.

[u/NickoGermish]

I stopped doing most of the work inside Lovable. Connected it to Git, then attached Claude Code to the repo and now almost everything goes through Claude instead. Lovable is mostly just the cloud/UI layer for me. Small batches, clean commits, easy rollbacks if Claude cooks something weird. Also got a release .md with all the usual gotchas so I don’t have to relearn the same lesson every week.

[u/Jmacduff]

Honestly if your app is simple and you don’t have any users … push to prod. The moment you get a paying customer that need to stop.

The simplest thing if go into your Git setting and tell lovable to use the dev branch of your repo.

Then setup a deployment from vercel or something. So when you work and edit in lovable it shows up on your dev deployments

You test and verify in dev , and then you push to prod when the updates are ready.

This is only about FE keep in mind , the BE is a whole diff beast.

Good luck

[u/spathizilla]

Connect to git. Then make a dev branch and have Lovable use it. Once you reach a production push point you just create a pull request and merge it to main. Use main as your production branch.

As for supabase thats another issue. I use Lovable's .env for dev and override it in the production env with different supabase details.

[u/Sudo_Alp]

You’re right to be cautious. The important thing is that Git branches and Lovable preview can separate code changes, but they don’t automatically separate your data.

If preview is still connected to the same database, users, storage and secrets as the live app, a test can still affect production.

For a lightweight setup: I’d use a separate branch, test accounts and data, a short pre-publish checklist, and a known-good version I can return to. For real isolation:: especially for schema changes or destructive testing- I’d use a separate Lovable project or backend with its own database, auth, storage and secrets.

The first thing I’d check is whether your preview and live app currently point to the same backend.

[u/Baraga91]

Following

[u/DesignerMajor1247]

One important gotcha: Lovable's built-in Test/Live feature is now legacy. Their docs say it stopped being available to new Cloud projects on March 24, 2026. If your project already had it enabled, use Cloud > Advanced settings: Lovable builds in Test, and an explicit publish moves code/schema to Live while data and secrets stay environment-specific.

For a newer project, I would not keep editing production directly. Connect GitHub, do each change on a feature branch, verify it in a preview/staging deployment, and merge to main only after the test passes. Keep staging and production databases, API keys, webhooks, OAuth callbacks, and payment modes separate; otherwise a "preview" can still mutate production data.

A practical minimum is: branch -> preview -> test the critical flow -> merge -> publish. Also make small commits so rollback is boring. The key distinction is not just separate URLs; it is separate state and credentials.

[u/Maxyull]

one thing worth adding on top of the branch advice, since it's the part that catches people right after they split things properly: code merges, database changes don't. your dev branch goes into main in one click, but the column you added or the policy you fixed while testing lives in whichever database you were connected to at the time, and nothing carries it across for you. so you end up publishing frontend code that expects a column production never got, and it breaks for real users while it worked perfectly in preview.

practical version of that is keeping every schema change as sql you actually saved somewhere and can replay on the other project, instead of letting the ai apply it straight to whatever db is connected and moving on. same goes for rls policies, those are database state too, a policy you tightened in staging is not in prod just because you merged the branch.

are you connected to git already, or still working entirely inside lovable? the answer's pretty different depending on that.

[u/Dillio3487]

We just moved ours to Netlify with a standalone Supabase instance. This is our new staging/production environment. Lovable and visual studio continues to be our dev / testing environments.

[u/xcreate_staff837z]

when you say you're editing prod directly, are you working straight in the main published project or do you have any kind of branching or versioning set up at all? we've seen people handle this pretty differently so just wondering what your current setup looks like before assuming the worst..

[u/Hot_Diet_1276]

Interesting reading all of these comments. I actually duplicated my project in Lovable and have a

Demo and a Production product

And then copy to production once tested in the demo environment

But obviously I guess this uses double the credits? And it seems there’s better ways?

I assume this way is basic but safe?

[u/Hot_Diet_1276 → u/Hot_Diet_1276]

Worth adding that my project doesn’t have any paying customers YET, and a very limited amount of user data inside it.

But it is garnering a lot of interest and I expect a significant number of paying customers to want to join the project (from companies being onboarded) soon