Every change goes straight to production
What it looks like
$ git branch
* main
# Vercel: Production Branch = main. No preview deployments in history.
# Supabase: schema changes run with `supabase db push` against the live project.
# Builder: Publish is the only environment. No preview URL separate from the live one.What happens
A broken build, a bad migration or an agent's misjudged edit reaches real users and real data first, with no place where it could have been caught.
Where it shows up
Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.
Seen in public
In July 2025 a Replit agent deleted data from a production database during a user-declared code freeze; Replit's CEO confirmed it, said backups allowed a restore, and announced automatic dev and production database separation.
- 2025-07-18 User's report on X
- 2025-07-20 Replit CEO confirmation on X
Jul 2025 · Jason Lemkin (SaaStr) · all sources
Check it yourself
Uses your builder's dashboard and your browser. No tools to install.
- Open your hosting dashboard (Vercel: the Deployments tab) or the builder's publish panel and look at the recent deployments.
- Check whether any are labelled Preview or came from a branch other than main; in a builder, check whether a preview link exists that is distinct from the live URL.
- Ask whoever changes the database whether schema changes run on a staging or branch database before the live one.
- Bad result: every deployment is Production, changes go live on save or push, and database changes hit the live project first.
What we check
We review deployment history and environment settings for a separate preview target, a promotion step and a rollback control, and we exercise the rollback on a harmless change. The report shows what a bad release would have hit and how long recovery would take.
Fix direction
Use the preview environment your host already provides: push to a branch, check the preview URL, then merge to the production branch. Point preview deployments at a separate database or branch, not the live one. Find the rollback control and try it once before you need it.
Mechanism documented in: Environments (verified 2026-09-21); Publish your Lovable project (verified 2026-09-21).
Covered by
Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)
Both include a re-check after your fixes.
Related patterns
- No automated checks before deployDeploy and configMedium
Type errors, broken imports and failing behaviour are discovered by users after deploy rather than by a machine before it, and each fix is another untested push.
- AI agent with production credentialsDeploy and configCritical
Anything the agent decides to run, or is tricked into running by text it reads, executes with the same power you have, including dropping tables or moving money.
- No backup that has ever been restoredData integrityHigh
When data is deleted or corrupted, whether by a bug, an agent or a person, there is either nothing to restore or a backup nobody has proven they can actually bring back.
- Migrations that cannot be undoneData integrityMedium
When the change turns out to be wrong, the old column values and deleted rows are already gone, and the only way back is a full restore from backup, if one exists.
Questions
should i deploy directly to production
For a hobby page, pushing to main and watching it go live is fine. Once real users and real data are involved, you want a step in between where the change is visible but not live. Vercel's docs describe preview deployments for any non-production branch and a promotion step for production; builders such as Lovable document publishing as deploying a snapshot, so the editor and the live app are already distinct.
how do i set up a staging environment on vercel
Vercel's environments doc lists three routes: a preview branch named staging with its own domain and variables, a staged production deployment that waits for manual promotion, or a custom environment on paid plans. The preview-branch route works on every plan. Give the staging deployment its own database credentials so testing never touches live data.
what happens when an ai agent changes production directly
In July 2025 a Replit agent deleted data from a production database during a user-declared code freeze (Jason Lemkin (SaaStr), 2025). Replit's CEO confirmed it and announced automatic separation of development and production databases. The lesson is general: agents and people alike should work against a copy first. Check today whether your agent or builder has a preview target and whether production credentials are reachable from the development environment.
Back to the catalogue, or run the self-check for your stack.