One of my favorite things about Replit is that the database, hosting, etc are all in house. But I want to start making projects for clients.
Ideally they would just pay me a monthly fee and we keep things on Replit. But some folks will want to migrate and host their site elsewhere. What are some easy options for this?
I imagine you would want to start out using an external database service like Supabase in this case.
Any helpor thoughts with this would be greatly appreciated!
Dennis
Are you more concerned about deployment or database? You’re not bound to replit if using the in-house database. It’s using Neon. Sou you could deploy elsewhere and still use the same database.
This is the approach I’m taking as well. The agent did a fantastic job building actions for my GitHub account that ultimately deploy to AWS and Neon when I push commits to git.
If you have experience with cloud-based technologies, it’s fairly straightforward to leverage the agent to deploy to those platforms.
It even did a solid job generating a cost assessment to ensure the solution was deployed using the most cost-effective SKUs.
That said, if you’re not familiar with these environments, it’s important to proceed with caution. Take your time auditing what the agent is doing—because without enough context to spot issues, it’s entirely possible it could lead you into trouble.
A perfect example of this playing out is the recent news about the Replit agent deleting a production database.
Have a healthy fear of what the agent is capable of, because there is truly no way to know when it may go rouge one.
Concerned about both, did not realize that about Neon so thanks.
I am not familiar with deploying to AWS but I could learn.
So what you are saying is that you can build on Replit and then, when you push to git, these changes can go live hosted on AWS?
If I understand you correctly, I like this a lot. I thought I would have to dump the code off of Replit and then deploy elsewhere – and not be able to use Replit for further updates.
Correct.
I gave Replit access to a repo on my GitHub account via token/ssh, and the CI/CD pipeline in GitHub owns all of my AWS secrets and ability to deploy.
Then I asked Replit to build the action yamls for me that will deploy via GitHub pipeline.
What is nice about this is, there are clear separation of concerns. Replit does not have direct access to my deployment pipeline, and nothing is deployed unless I manually choose to deploy it.
This also offers a safe guard so that I can conduct thorough code reviews and have a chance to correct any issues I might spot.
It also acts like a backup of sorts, because now the project code is not only in Replit, but there is a copy in my GitHub account as well.
Replit git feature and GitHub integration are underutilized. Understanding version control hands on can save a lot of headaches vs relying on Agent checkpoints.
I completely agree 
Great thread here and good discussion so far.
One thought I had, is could there be a benefit to setting up a dedicated Replit account for the client?
Everything could be in one account and transferring ownership to the client would be very easy that way.
Overall - this seems like a problem to be solved as Replit scales and more people turn to the platform for client work.
Very interesting idea… I like it @mark
I’ve set up deployments in GCP that I’ve built in Replit and it wasn’t hard setting it up. I think the idea with their integration with Azure is to make it easy to bring it from MVP to production app by scaling the resources available to it.
I would love to hear how people do this. I am new to this and created a new app for my club. However because it is a new app and I am still developing it there are constant database changes which break the deployed app, so separating them would be ideal. I tried to get Agent to code in separate databases but then the Agen kept forgetting about this and it all ended up too problematic. So now I have gone back to one database but am looking at a separate deployment platform to solve this.
This is why I’ve gone with supabase for all my auth, dB and file storage. My prod deployment uses a secret to point at a prod supabase project. And the dev app points at a dev one.
Whenever I release a new app change to prod, I ask agent to confirm if there are any dB schema changes, and if so to give me the sql to run in the prod supabase to update it. I run this manually at the same moment I deploy the app code to prod.
I do think we also need a staging version of the app too and hopefully replit will offer this at some point.
This should now be rolled out to everyone as far as I know.
I am interested in this. Being new to Replit and modern coding I would like to heard more details about how you are doing this? I can see the secrets in Replit but I’m not sure how to use different ones in production. Or what specifically prompt to use during the deployment to get those sql scripts etc to ensure migration works.
Deployed/production secrets: @CraigRT - so you can see in the screenshot the Deployments tool. You will see it has a list of secrets, and these are copies of the ones in your dev.
It’s been a while since I started a fresh new app, but I recall it asks you to confirm you want to copy the dev ones. you can then keep them synced, or you can click the 3 dots next to each one to edit it to unsync it and have a different value for the deployed version of the secret.
The link symbols down the left hand side show if each one is synced or not with dev. You can see most of mine are synced, but the Supabase ones are not - because they have different values, pointing at my Production Supabase project instead of the dev one.
Getting sql from Agent: just ask agent/assistant “I am about to deploy the app to production. Have we changed any of the DB schema? If so, please show me the SQL for me to modify my production DB. Do not run this yourself, I will run it myself manually”.
Note, this is something you must do carefully once your production system is live. Remember, you will have real users on there, so the DB changes need to sync with you doing a deployment of the new code, or things will break. So practice the whole workflow a few times before you start getting real users onboard.
Ok, so I can see secrets in the secret panel and also in the deployments panel. They are both initially linked, but in the deployment panel you can unlink them and so then enter a different value to use in the deployed app. Correct?
That is not obvious from reading the documentation.
Yes you can. Click the 3 dots next to each secret in deployment panel.
I can’t see how to do that in my setup. Do you have it? Should I get in touch with support to try and get in enabled for my account?
Currently only supported for new deployments. I believe the Replit team is working on enhancement to support existing deployments. @victoria-replit may be able to shed more light. Doc: Replit Docs
My concern with that would be similar to when I worked at a legal SaaS company and would talk to attorneys - most would say something like “If my client would find out how easy it is, that could take revenue off the table” (if they know you’re using a solution that allowed you to create in an hour, why are you billing a normal rate?)
The other day I was talking with a friend who had quotes from engineers from $20-50k for a solution she was trying to build for her company (she was trying to build attribution software). I had it 80% of the way to her requirements in <30-minutes, so if people saw that and they’re a little tech savvy, they might walk away and build on their own. If I were shipping custom software, I honestly wouldn’t want them to see anything Replit in the URL as it could eat my revenue stream.
