@jpascucci2, this is one of the most widely asked things by non-tech people in the vibe coding world, and here in Replit’s community: development versus production (often shortened to dev and prod).
And it is why Replit have been working on a dev/prod database structure, although I honestly don’t think the rollout is being done right. It’s a case of here are some tools, but no real understanding of why or how to use them.
To existing software folk, this is all second nature. But in vibe coding land there needs to be more support for non-techs to understand these critical ideas, processes and workflows. The vibe coding is the easy bit (as you’ve found out), but all this other stuff like managing dev versus prod is tough without the learning and training.
So,… whilst there are different models (did I say there was just one simple way? 
) here is how I would do it - sorry if it’s a bit high level, happy to drill down if you have questions…
-
develop in your Replit dev environment. Add new features as you wish. The secrets include ones that point to a development DB (database)
-
when you deploy to production in Replit, your deployment version of those secrets would point to a different production DB. You have to make sure that if there are any changes to the structure of the DB (the schema) that you deploy these changes at the same time as the new code
-
you can then carry on adding new features, fixing bugs, etc in the development version of the code, knowing that it will not affect anything in the deployed production version - including your production DB
-
your production users are totally unaware of the new features and work you are doing in development, until you are ready to formally deploy them to production. A process by the way, that is worth an entire post in itself, as it is something you clearly have to do very carefully (big systems automate this, and employ people whose sole job is to manage the process)
Notice in the above that you never remixed to a new app. It is all done in a single app. Although there are reasons why you might remix sometimes.
There are also very strong arguments that Replit’s new dev/prod DB and the existing dev versus deployed (prod) environments is still very limiting. Many of us old-timers would ideally want at least 3 phases: dev, staging, and prod. The staging is one where you release your newly developed features/bug fixes into a carefully controlled middle ground, so that invited testers can check it all works properly (and away from the dev area where you are still hacking more changes). And then only when it passes all your staging tests would you move it on to the production area.
I appreciate all this may initially sound complicated (and I have only given you a taster!). But it is why there is a big argument from existing software developers saying “sure, vibe coding looks fun, but all this other stuff we trained for years to do is why vibe coding will not succeed”. An argument that I am dead against, because I believe the critical parts can be taught, and platforms like Replit will eventually support.
Very quickly, your other points:
-
I personally have an instruction in my replit.md that tells Replit agent never to modify my DB structure or schema. I think allowing the agent to make changes is madness. I ask agent that any changes to the schema are added to an SQL script, which I can then take and manually run myself, in a controlled way
-
Github - yes, you need to get a handle on this and Replit’s Git tool. It is critical for backing up your app and having access to previous versions. It’s another subject though that needs a full post in itself
