Second this - using Dev as QA can be more efficient but it causes issues and also it’s a nightmare if someone else is continuing to develop. As Replit gets more and more into the Enterprise space this is going to be a necessity and follows the standard software development approach. I’d also suggest the ability to easily clone or reverse clone from one environment to another and the same option for the databases to allow you to sync up the latest prod with Dev/QA for example and vice versa as needed.
We’ve definitely felt the “dev as QA” pain. It’s fast until there’s more than one person shipping, then it gets messy fast, especially when someone new picks up the project.
Also +1 on environment + DB clone/reverse clone
Being able to quickly sync prod ↔ dev/QA (when needed) would make QA way easier and a lot more realistic. We would use this to help make a more realistic QA set up for our Business SMEs, and also, it’s easier for dev team working on apps in DEV when they can see better data.
One thing to consider is for now you can do some workarounds. Example: Stripe integration. Use dev keys for testing and prod keys for prod. Make them environment aware so treat differently in dev and prod.
Agree as goes more mid-market. In meantime, another thing to, is Projects feature in Teams works pretty well to make git branches essentially to avoid dev conflicts.
This is the way for now, I’m doing this for both Stripe and GCP. Definitely would love to see a UAT environment though so testing is easier for all environment variables.
+1 to this idea. This isn’t important if you’re just throwing up a quick prototype or quick app, but as vibe coding and stripe and ai integration quickly enter our apps, we have no way of pushing out dev code to production to a live active user base without risking the biscuit.
This is such a good idea and I hope they implement something like this soon. While I’m only currently developing myself, I could definitely see how this would benefit a multi developer environment promoting directly to production.
As a solo non coder, where *I* would benefit the most is coming from the other side of it. I constantly have issues with the agent doing anything on production due the all the guardrails Replit has put up. If there’s an API key issue, a different cacheing function, a database anomaly or any differential between dev and prod where I need to simply query the logs on production, the agent initially pretends it can’t do anything (always reverts to dev) and I’ve got to do a lot of wrestling with it to help me out (rather than it directing me to do all the work). If there was a staging environment in between, Replit wouldn’t need any guardrails on staging, and I could freely use the agent there just like I do on dev. Then I could promote to prod from there with all the guardrails in place and with very little need to use the agent at that point. This would go a long way towards Replit truly enabling us to build production-ready apps.
