A real staging environment for your Lovable app

What staging has to do

• Its own database with realistic (copied or seeded) data, so a bad migration cannot touch a customer.
• Its own auth users, storage bucket, secrets and webhook endpoints — Stripe test mode, not live.
• A URL you and your testers can click through before anything ships.
• A repeatable way to refresh it from production without leaking real personal data.

The setup I use

The code side is easy and Lovable already supports it: GitHub sync, main as production, feature branches for work in progress. The data side is where Lovable Cloud falls short, so the app moves to your own Supabase organisation with two projects — production and staging — or to Postgres on Google Cloud with two databases.

• Migrations live in the repo and run the same way in both environments; nothing is changed by hand in production.
• Preview deployments (Vercel or Cloud Run) point at staging by default; only main points at production.
• A nightly job copies a masked snapshot of production into staging, so tests run against realistic data.
• Checks run on every pull request — types, tests, a scan for committed secrets and missing RLS — and block the merge if they fail.
• You keep building in Lovable or Claude Code against staging; promotion to production is a reviewed merge, not a prompt.

Before October 5

If you rely on the Test environment today: anything in the Test database that you want to keep has to be moved before the retirement date (Lovable says test databases stay restorable until November 1, 2026). The cleanest path is to make the move now — into your own staging project — rather than migrate twice.

Questions