On October 5, 2026, Lovable Cloud retired its Test and Live environments. Every Cloud project now runs on a single database, and Lovable's own migration guide puts the consequence in one line: "The data you see while building is the data your published app uses."
That sentence lands differently once you add two features Lovable shipped in September. Its testing agent can now sign in to your app and click buttons. And drafts, the replacement for Test and Live, use your real data too. So the preview, every draft and the agent testing your changes are all pointed at the database your customers are using.
TL;DR
Since October 5, 2026, a Lovable Cloud project has one database, shared by the preview, every draft, the browser-testing agent and the published app. The agent can sign in as your app's only user (usually you, with admin rights) and submit forms. Detached Test databases can be restored on request until November 4, 2026, then they're gone. To test against fake data, remix the project: a remix copies your tables' structure with no rows and no users.
What changed, with dates
| Date | What happened | Source |
|---|---|---|
| March 24, 2026 | New Cloud projects can no longer turn on Test and Live | Lovable changelog |
| September 8, 2026 | Browser testing can sign in and test pages behind your app's login | Lovable changelog |
| September 9, 2026 | Drafts launch, sharing the project's backend and data | Drafts docs |
| September 14, 2026 | Owners of affected projects get an email and an in-project notice | Environments guide |
| October 5, 2026 | Test and Live retired; Test databases detached but restorable | Environments guide |
| November 4, 2026 | Detached Test databases permanently deleted | Environments guide |
Lovable says most projects need no action and that no data was deleted on October 5. There's one exception that will have caught people out. If your data lived only in Test and you didn't move it, the guide says your published app now "runs on an empty Live database" until you move the data over.
Why this is a security change, not just a workflow change
With Test and Live, a test database was a safety margin. You could let the AI try things, break things, and fill tables with junk, and your customers never saw it. That margin is gone, and three features now operate on production data.
The preview
Lovable's preview docs still describe the preview as "your app's staging environment", then add that "the preview and your published app share the same backend and data". It's staging for your code. It isn't staging for your data. A row you create to see how the dashboard looks is a real row.
Editing tables by hand in the Cloud view is the same: the database docs say those edits apply to "the same database your published app uses".
Drafts
Lovable positions drafts as the closest thing to Test and Live, but the docs are blunt: "A draft uses your project's real data, so the information you add or change while testing is real." A draft keeps your code changes separate. Structural database changes, including new rules about who can read or change data, wait until you accept the draft. Data changes don't wait for anything.
The testing agent
This is the one that needs your attention. Since September 8, browser testing can sign in to apps that use Lovable Cloud auth. Per the docs:
- If your app has exactly one user, Lovable signs in as that user.
- Ask it to check something "as yourself" and it signs in as the app user whose email matches your Lovable account.
- Workspace admins and owners can have it sign in as a specific person, after approval in chat, and "Lovable does not use or change that person's password".
- Once in, it can "Click buttons and links" and "Fill inputs and submit forms".
On a brand-new app, the one user is almost always the founder, and the founder account is usually the admin. So the default is an agent holding admin rights, clicking through your app, on production data. The docs' safeguard is a sentence: "Be explicit if there are actions or areas that should not be clicked or triggered." Browser testing can also start without being asked, though Lovable's FAQ says it's "conservative by default". We found no setting to turn it off.
Lovable's browser-testing page hasn't caught up. As of October 9 it still says that when test and live environments are enabled, testing "runs against the project preview in the test environment". The feature that sentence relies on no longer exists. If you read that page and assumed the agent tests on a copy, it doesn't.
Shared preview links
A Share preview link lets "anyone with the link" open your working version with no Lovable account, and on Free and Pro plans the link lasts 7 days. Since the preview runs on live data, a preview link shows a client your real records, not sample ones. Business and Enterprise plans can password-protect these links or set shorter expiry; Enterprise can turn them off.
What to do this week
Check which situation you're in before November 4. Open your published app and confirm the data you expect is there. If it's empty or missing records you only ever created in Test, contact Lovable support now. The restore window closes on November 4, 2026, and Lovable's 30-day backups of affected projects run out around the same time.
Give the agent a test account that isn't you. Create a second user in your app with ordinary, non-admin permissions. Once your app has more than one user, the docs say Lovable asks which one to use before signing in, instead of quietly picking the only account. Point it at the test user, and keep your admin account out of agent sessions.
Name the dangerous buttons out loud. Before you ask Lovable to "verify it works", list what it must not touch: delete actions, anything that sends email or SMS, refunds, payouts, invites. Lovable's docs make this your job. Something like:
Paste before asking Lovable to test
Test this using the test user account only, never my admin account. Do not click any button that deletes data, sends an email or message, charges or refunds a payment, or invites a user. If a flow needs one of those to finish, stop and tell me instead of completing it.
Remix when you need real separation. For a risky change (a new payment flow, a migration, anything that bulk-edits rows), remix the project and test there first. Lovable's Cloud docs say a remix copies the structure of tables and Edge Functions "but not the data itself", and the auth docs say it "starts with no users". It doesn't stay in sync with the original, so you repeat the change there once you're happy. That's more work than Test and Live was, and it's the only built-in way left to experiment on an empty database.
Get your row-level security right before you test, not after. With a test database, a too-loose policy during development leaked nothing real. Now any policy the agent or a draft relies on is the policy your customers' data sits behind. Check that every table with user data has RLS on and that policies filter by the signed-in user, not just "is logged in". Our Lovable + Supabase blueprint walks through the policy pattern, and a scan of your published URL will flag a service_role key shipped in your frontend, the one key that skips RLS entirely.
The bigger picture
Lovable's environments guide says the Test and Live beta "has concluded" and that it's "taking development and production environments in a different direction". Fair enough, and nothing here is a vulnerability. But for a non-technical founder, the practical effect is that the friendliest safety net in the product disappeared less than a month after the AI got the ability to log in and press buttons. Neither change is dangerous alone. Together, they make "let the AI test it" an action on production.
If you'd rather keep a proper staging database, the environments FAQ says you can connect your own Supabase project instead of Lovable Cloud. Export your data first: Lovable says disconnecting Cloud is permanent and there's no one-click migration.
Did Lovable remove Test and Live environments?
Yes. Lovable's environments page says that on October 5, 2026 Lovable Cloud retired the Test and Live split, and every Cloud project now runs on a single database. New Cloud projects hadn't been able to turn it on since March 24, 2026. Existing Test databases were detached, not deleted, on October 5.
Can I get my Lovable Test database back?
Until November 4, 2026, yes. Lovable says it can restore a detached Test database on request until that date, after which it's permanently deleted. It also backed up both environments of every affected project and keeps those backups for 30 days after detachment. Contact Lovable support if you need data that only existed in Test.
Does the Lovable preview use my production database?
Yes. Lovable's preview docs say the preview and your published app share the same backend and data. Since October 5 that's true for every Cloud project, and drafts work the same way, because a draft uses your project's real data rather than a database of its own.
Can Lovable's testing agent change real data?
It can. Since September 8, 2026, browser testing can sign in to your app and click buttons, fill inputs and submit forms. If your app has exactly one user, it signs in as that user, which is usually you. Lovable's docs tell you to be explicit about anything it shouldn't click or trigger.
How do I test a Lovable app without touching real data?
Remix the project. Lovable's docs say a remix copies the structure of your tables and Edge Functions but not the data, and starts with no users, so it gives you a separate empty database to test against. The catch is that the copy doesn't stay in sync, so you repeat the change in the original afterwards.
Your preview is production now
Scan your published Lovable URL for a leaked service_role key, other exposed secrets and missing headers before the agent's next test run touches real data.