How to Migrate from Replit to AWS, Vercel, or Render

Replit is a brilliant place to start an app. It is a weak place to run one in production. Sooner or later you hit the wall: cold starts, limited control over the runtime, a database you cannot tune, and a bill that climbs as the app grows. The good news is that a Replit project is just code, environment variables, and usually a database, so moving it is a well-defined process rather than a rewrite. This is the step-by-step guide to migrate from Replit to AWS, Vercel, or Render, with the actual commands and config files you need. We migrate apps off Replit for clients regularly, and the part that trips people up is almost never the deploy. It is the database and the secrets, so we spend real time on those.

Quick Answer: Migrating Off Replit

The process is the same for all three targets: push your code to Git, recreate your secrets as platform environment variables, migrate your database, then point the new host at your repository.

Pick the target by app type: Vercel for frontends, Next.js, and serverless APIs; Render for full-stack servers, workers, and cron with managed Postgres; AWS for scale and control.

The hard parts are not the deploy. They are moving the database safely and rebuilding environment variables, so do those carefully and verify before you switch traffic.

Key Takeaways

• Get your code into Git first. Every target deploys from a repository, so this unblocks everything else.
• Secrets never leave Replit in your code. You recreate them as platform environment variables.
• Migrate the database with pg_dump and restore, and verify the data before cutting over.
• Vercel is serverless, so a long-running Express server needs adaptation or a different target.
• Render is the easiest full-stack home, with a single render.yaml describing the service and database.
• AWS gives the most control, with Elastic Beanstalk or App Runner plus RDS, at the cost of complexity.
• Custom domains move by repointing DNS, and SSL is issued automatically once DNS verifies.

Quick Facts

Why Migrate Off Replit?

Replit shines for prototyping, learning, and demos, and tools like it have made it normal to ship a first version in a weekend. Production is a different job. You eventually want predictable performance without cold starts, control over the runtime and scaling, a managed database with real backups, custom domains and infrastructure, and clearer cost control as traffic grows. Migrating gives you all of that while keeping the codebase you already wrote. If you built the app with an AI-first workflow, our piece on vibe coding versus agentic engineering explains why the production hand-off is its own discipline, and our roundup of the top vibe-coded websites shows what teams ship before this step.

Step 1: Universal Prep (Do This First)

These steps are the same no matter which target you pick. Get them right and the platform-specific part is short.

1a. Push Your Code to Git

Open the Replit shell and push the project to a new GitHub repository. First make sure secrets and junk are ignored:

# .gitignore
node_modules
.env
.env.local
.replit
replit.nix
.config
.upm

# in the Replit shell
git init
git add .
git commit -m "Initial import from Replit"
git branch -M main
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO.git
git push -u origin main

If Replit has already linked Git, just commit and push. The goal is a clean repository with no secrets in it.

1b. Inventory the App

Write down five things, because every platform asks for them: the runtime and version (for example Node 20 or Python 3.12), the install command (npm install or pip install -r requirements.txt), the build command if any (npm run build), the start command (npm start or python app.py), and the list of environment variables. This inventory is your migration checklist.

1c. Externalize Your Secrets

Replit Secrets do not travel with your code, which is correct, because your .gitignore keeps .env out of the repository. Capture the names in a committed example file so the set is documented, then recreate the values on the new platform later:

# .env.example  (commit this, no real values)
DATABASE_URL=
SESSION_SECRET=
JWT_SECRET=
PORT=3000
NODE_ENV=production

1d. Make the Port Configurable

Replit injects a port for you. Real hosts set a PORT environment variable and expect your server to read it. Most migration failures we see are an app hardcoded to a port the platform is not routing. Fix it once:

// server.js  (Node / Express)
const express = require("express");
const app = express();

const port = process.env.PORT || 3000;
app.listen(port, () => {
  console.log("Server listening on port " + port);
});

Bind to the platform port and you are portable. Also confirm your package.json has a real start script, such as "start": "node server.js".

1e. Migrate the Database

If your app uses Replit's PostgreSQL, this is the step that matters most. Export the data with pg_dump against your Replit database URL, then restore it into a managed Postgres on your target. Run these from any machine with the Postgres client tools installed:

# 1) Dump the Replit database (custom format)
pg_dump "REPLIT_DATABASE_URL_HERE" --no-owner --no-acl -Fc -f backup.dump

# 2) Restore into the new managed Postgres (Render, RDS, or Neon)
pg_restore "NEW_DATABASE_URL_HERE" --no-owner --no-acl --clean --if-exists -d "NEW_DATABASE_URL_HERE" backup.dump

# Verify a table count before cutting over
psql "NEW_DATABASE_URL_HERE" -c "SELECT count(*) FROM your_main_table;"

If you used the Replit key-value Database instead of SQL, there is no dump file. Export the keys through its API or client library and load them into your replacement, such as a managed Redis or a Postgres table. Either way, migrate and verify the data before you point the live app at the new database.

Step 2: Choose Your Target

The fastest way to decide is to match the app to the platform.

Step 3a: Migrate to Vercel

Vercel is the best home for frontends, Next.js, and serverless APIs. If your app is a Next.js or static site, this takes minutes. Install the CLI and deploy:

npm i -g vercel
vercel login
vercel link            # connect this folder to a Vercel project

# add each secret from your inventory
vercel env add DATABASE_URL production
vercel env add SESSION_SECRET production

vercel --prod          # deploy to production

For a Next.js app you usually need no config at all. For a plain Node API deployed as serverless functions, add a small vercel.json so Vercel knows how to build and route it:

{
  "version": 2,
  "builds": [{ "src": "server.js", "use": "@vercel/node" }],
  "routes": [{ "src": "/(.*)", "dest": "server.js" }]
}

One caveat that catches people: Vercel runs serverless functions, not a persistent process. A traditional always-on Express server, websockets, or in-memory sessions will not behave the way they did on Replit. If your app truly needs a long-running server, use Render or AWS instead, or move session and real-time state into a managed store.

Step 3b: Migrate to Render

Render is the closest experience to Replit for a full-stack app, and usually the smoothest migration. You can click through the dashboard, but the repeatable way is a render.yaml blueprint committed to your repo, which provisions the web service and the database together:

# render.yaml
services:
  - type: web
    name: my-app
    runtime: node
    plan: starter
    buildCommand: npm install && npm run build
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
          property: connectionString

databases:
  - name: my-db
    plan: starter

Push that file, then in Render choose New, Blueprint, and connect the repository. Render reads render.yaml, creates the Postgres database, wires DATABASE_URL into the web service automatically, and deploys. Restore your data into that database using the pg_restore step from earlier. If you prefer full control of the image, Render also builds from a Dockerfile:

# Dockerfile
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

Step 3c: Migrate to AWS

AWS gives the most power and the most knobs. For a web app coming straight from Replit, Elastic Beanstalk is the gentlest on-ramp because it handles the servers, load balancer, and scaling for you. Install the CLI, initialize, and create an environment:

pip install awsebcli

eb init -p node.js my-app --region us-east-1
eb create my-app-env

# set your secrets as environment variables
eb setenv NODE_ENV=production DATABASE_URL="NEW_DATABASE_URL_HERE" SESSION_SECRET="..."

eb deploy
eb open

For the database, create a managed Postgres with Amazon RDS rather than running one yourself:

aws rds create-db-instance   --db-instance-identifier myapp-db   --db-instance-class db.t3.micro   --engine postgres   --master-username appuser   --master-user-password "CHANGE_ME_STRONG"   --allocated-storage 20   --publicly-accessible

Then restore into it with the same pg_restore command as before, and point DATABASE_URL at the RDS endpoint. Two alternatives are worth knowing: AWS App Runner deploys a container directly from your Dockerfile or image with very little setup, and AWS Amplify is the frontend-focused option that mirrors what Vercel does for static and Next.js apps. Pick Beanstalk or App Runner for a server, Amplify for a pure frontend.

Step 4: Post-Migration

• Custom domain. Add your domain in the platform, then at your registrar set a CNAME for a subdomain (www) and an A or ALIAS record for the apex to the target the platform provides.
• SSL. All three issue a free certificate automatically once DNS verifies, so allow a short propagation window.
• Environment variables. Recreate every secret from your .env.example inventory, and confirm the app boots cleanly with them.
• CI/CD. Connect the platform to GitHub so a push to main auto-deploys. Vercel and Render do this by default; for AWS, add a GitHub Actions workflow that runs eb deploy or the AWS CLI.
• Monitoring and backups. Turn on logs, basic alerts, and automated database backups before you announce the move.

Common Pitfalls

• Hardcoded port. The app must read process.env.PORT, or the platform health check fails.
• Secrets committed to Git. Confirm .env is in .gitignore before the first push, and rotate any key that leaked.
• Forgetting the database. Deploying the code without migrating the data gives you a live app with an empty database.
• Choosing Vercel for a stateful server. Serverless does not keep websockets or in-memory sessions; pick Render or AWS for those.
• Replit-specific files. .replit and replit.nix are harmless but pointless on the new host; ignore them.
• Surprise AWS bills. Set a billing alarm on day one, because AWS bills every resource separately.

Why Teams Migrate With Make An App Like

Make An App Like has shipped 500+ apps for founders in 40+ countries since 2016, reaches a 50,000-reader audience through our publishing platform, and has been featured by TechCrunch as a leading partner for non-technical founders. We move prototypes from tools like Replit onto production infrastructure regularly, so the steps here come from real migrations, including the database and secrets work that the quick tutorials skip.

Estimate Your Migration or Build

Want a fast, line-item budget to migrate or rebuild your app for production? Use our free calculator: https://makeanapplike.com/tools/app-cost-calculator

Launch Faster With a Ready-Made Foundation

Skip months of setup with a white-label, production-ready app or SaaS foundation: https://makeanapplike.com/buy-white-label-apps

Conclusion

Migrating off Replit is a process, not a rewrite. Push your code to Git, externalize your secrets, make the port configurable, and migrate your database with pg_dump and restore. Then pick the target that fits: Vercel for frontends and serverless, Render for full-stack apps that need a real server and managed Postgres, and AWS when you need scale and control. Do the database and secrets carefully, verify before you cut traffic over, and wire up auto-deploy so a push to Git ships to production. The codebase stays the same; what changes is that you now run it on infrastructure you control. For a sense of the wider cost picture once you are in production, our breakdown of what a SaaS MVP really costs is a useful next read.

Frequently Asked Questions

1. Can I move my Replit app to AWS, Vercel, or Render?

Yes. A Replit project is just code plus environment variables and usually a database, so it ports to any standard host. The work is exporting your code to Git, recreating your environment variables as platform secrets, migrating your database (typically a pg_dump and restore for Postgres), and pointing the new host at your repository. Frontends and Next.js apps suit Vercel, full-stack servers suit Render, and AWS suits anything needing scale or fine control.

2. How do I export my code from Replit?

The cleanest path is Git. In your Replit shell, initialize a repo if needed, commit everything except secrets, and push to a new GitHub repository. You can also download the project as a zip from the Replit files menu, but pushing to Git is better because every target platform deploys directly from a Git repository. Make sure your .gitignore excludes .env, node_modules, and the Replit-specific files before you push.

3. Which is the best platform to migrate to: AWS, Vercel, or Render?

It depends on the app. Choose Vercel for frontends, static sites, Next.js, and serverless APIs where you do not need a long-running process. Choose Render for full-stack apps, background workers, cron jobs, and anything that needs a persistent server, with the bonus of managed Postgres. Choose AWS when you need maximum scale, control, or specific services, accepting that it is the most complex of the three to set up and operate.

4. How do I migrate my Replit database?

If you used Replit's PostgreSQL, export it with pg_dump against your Replit DATABASE_URL, then restore it into a managed Postgres on your target (Render Postgres, AWS RDS, or Neon) with pg_restore or psql. If you used the Replit key-value Database, there is no SQL dump; you export the keys through its API or client library and load them into your replacement store. Always migrate and verify data before you switch traffic over.

5. What happens to my Replit secrets and environment variables?

Replit Secrets do not travel with your code, and they should not, since your .gitignore keeps .env out of the repository. You recreate each secret as an environment variable on the new platform: Vercel with vercel env add or the dashboard, Render in the service settings or render.yaml, and AWS with eb setenv or parameter store. Keep a .env.example in the repo that lists the variable names without values so the set is documented.

6. Will my Replit app work on Vercel?

Frontends, static sites, and Next.js apps work great on Vercel. A traditional long-running Express server needs adaptation, because Vercel runs serverless functions rather than a persistent process, so websockets and in-memory state do not survive between requests. You either restructure the API into serverless functions or, if you need a persistent server, choose Render or AWS instead. Check what your app actually needs before picking Vercel.

7. How do I keep my custom domain after migrating from Replit?

Your domain is independent of the host, so you keep it by repointing DNS. Add the domain in your new platform, then update the DNS records at your registrar: usually a CNAME for a subdomain like www, and an A or ALIAS record for the apex domain to the target the platform gives you. Each platform issues a free SSL certificate automatically once DNS verifies, so plan for a short propagation window.

8. How much does it cost to host on AWS vs Vercel vs Render?

All three have free or low-cost entry tiers and then scale with usage. Vercel and Render are simple per-usage or per-service pricing that is easy to predict for small apps. AWS is granular pay-as-you-go across many services, which is the most flexible but also the easiest to misconfigure into a surprise bill. For a small production app, Render or Vercel are usually cheaper to operate; for large scale, AWS often wins on unit economics.

9. Do I need Docker to migrate from Replit?

Not always. Vercel and Render can build directly from your repository using a detected runtime and your build and start commands, no Dockerfile required. You add a Dockerfile when you want full control over the runtime image, when your app has unusual system dependencies, or when you deploy to container services like AWS App Runner or ECS. A simple Node or Python app usually migrates fine without Docker.

10. How do I set up CI/CD after migrating from Replit?

The easiest CI/CD is built in: connect the platform to your GitHub repository and it will auto-deploy on every push to your main branch, which Vercel and Render do out of the box. For more control, add a GitHub Actions workflow that runs tests and then triggers the deploy, or uses the AWS CLI or eb deploy for AWS. Either way, the goal is that pushing to Git ships to production, which is the workflow Replit hid from you.