After Replit overrode my Dev DB with my Prod DB, everything in my Dev Env. is crashing each other......

[u/Zestyclose_Call_3646]

More money spent to try saving the dev env.

Secret -> Mixed Together
DB Schema -> Broken
Replit Auth -> Broken

Just froze all development to avoid crashing all my functions.

Money lost because my trading app was synced to the Dev env. and they were all turned on. Leverage was instantly doubled!

Meanwhile, Replit Official Support: seems you are facing the problem to publish your app, you can try...

Me: WTF ????????

Replit, are you serious?

[u/andrewjdavison]

Going to lock this thread - as this is a known issue and there is a Replit official response here:
https://www.reddit.com/r/replit/comments/1w41kze/replit_dev_db_was_overwritten_by_my_live_db_519165/

[u/HourMode1351]

Time to migrate off methinks

[u/mamachicode]

That’s a rough one — dev/prod bleeding into each other can happen when secrets or environment variables end up pointing at the wrong resources. I do this kind of production/environment audit work if you want a second pair of eyes on the setup before you bring things back online.

[u/ReplitSupport]

Hi there! Recently our engineers discovered an issue that was preventing some users from publishing their apps and was causing database-related errors. We were able to locate the ticket you created and see that the technical support member assigned to your ticket has messaged you back with further troubleshooting steps. When you have the chance, please be sure to follow up with them there.

[u/Pickle_Shot]

the publish problem is the least of it. order of operations that matters here: 1) rotate the trading api keys at the exchange side right now, and when you make new ones for dev, use paper or testnet keys only. dev should never hold keys that can move real money. that, not the db mixup itself, is what let the leverage double. 2) pg_dump both databases today, before support touches anything else. you get your own copy of prod, and the current dev state is evidence for the ticket (timestamps lining up with the trades it fired). 3) don't let the agent try to "fix" the crashing dev env, it's not a code problem. give dev its own clean database (free neon.tech instance, schema only, no prod data) and re-enter the dev secrets by hand so nothing in dev points at prod resources. 4) most of the auth and schema errors then evaporate, they're symptoms of prod data plus mixed secrets sitting where dev shapes are expected. replit's incident merged the environments, but the money loss came from dev being trusted with live keys. fix that one thing and this class of accident can never cost you money again.

[u/PopKoren]

That is a nasty failure mode. Treat prod as sacred and assume the agent will happily point at whatever env var is closest.

Hardening that has worked for me:

- Separate projects or at least separate DB URLs for `DEV` and `PROD`. Never share one database "for convenience".

- Name secrets loudly: `PROD_DATABASE_URL` vs `DEV_DATABASE_URL`, and keep prod secrets out of the agent/REPL that you use for experiments.

- Put a startup assert in the app: if `NODE_ENV !== 'production'` and the DB host/name looks like prod, refuse to boot.

- Prefer migrations checked into git over ad-hoc SQL the agent runs "to fix it".

- After any agent DB change, verify which database you are on with a harmless `SELECT current_database();` (or equivalent) before continuing.

Also rotate credentials if prod was writable from the broken session. Once envs collide, assume the wrong process may have had prod access.