Id love it if we could roll back the agent to the last deployed version. I had an incident where I asked agent to add something to the database and it erased the existing database (said its unrecoverable) and it started an entirely new database. This was detrimental to weeks of work.
I asked for this exact thing a while back, they couldn’t help. You’re hosed just try to salvage as much as you can. Good luck, eventually you’ll build a process so good that this can’t happen. It’s not the best process but I fork my builds to create new versions.
I also build bulk import/export into my projects so that I always have JSON files backing up my data and can import into forked builds.
Do you use Git? Sounds like your problem could be prevented with better version control.
Did you modify the deployed code directly when you make changes or did you create a branch to work on the feature and test it before bringing it live?
THis is a very good point!
Git to the rescue with version control.
Importing and exporting outside of Git can also be a great failsafe. Replit pushed to my GIT through an automated route, after some scripting errors the GIT ended up mangled and it was easier to clear out and start again
Having a clean workflow is everything.
I totally understand the frustration that you have to constantly back things up.
I am a mechanical design engineer by trade so version control for our design file is something I am very used to. I’ve had built on my design to a point I had to rebuild everything from scratch before.
When I initially felt frustrated by this back up, I consulted my SWE friends and they told me I am learning the ‘why’ for version control through this experience. It’s all part of learning ![]()
Hi everyone,
Since there is already a topic on this, is there no way to restore the deployed code as a starting point for further customizations?unfortunately I have too many changes to get back that far in Git…
No need to fork a bunch, just setup GIT and make new branches at an insane rate.
Agree!!! Replit was not able to implement simple functionality and in the process of trying to troubleshoot why, changed a number of unrelated files and now the workflow will not start. When you close a chat session you lose the checkpoints/rollbacks. Why not save a certain number or limited time period of checkpoints/rollbacks outside of the Chat with some labeling to identify the work / chat that it was associated with? AND/OR, specifically in the case of this thread, roll back to a known deployed version.
This may rollback the deployment but not the code you’re working in? IDK, never actually seen that or used it.
@kody-replit Can you explain what this does exactly? Are we now able to rollback to deployed codebase?
I feel like adding a git commit for the deployment would make a lot of sense. Even if you already committed the code, a separate deployment commit would be nice to rollback to. I’m building so many apps quickly, it’d be nice to have a built in system to ensure I’m not silly and forget which commit I deployed so I can rollback to the versions that I know are working.
Helps a lot with QA for this stuff

