How to move your app off Replit to your own hosting

Moving an app off Replit takes four jobs: list everything that only works on Replit, get the code into a GitHub repository, copy the database and stored files to services you control, and switch your domain once the new copy has been tested. The code itself usually moves easily. The work is in the Replit-specific pieces, especially login, file storage and the database, and in doing the switch without losing data written during the move.

This guide gives you the order to do it in, the checks that catch the usual surprises, and a cutover plan that keeps the old app running until the new one has proven itself.

Should you move at all?

Moving costs time, and Replit's hosting is fine for many apps. Good reasons to move include needing infrastructure your team or investors already use, wanting a staging environment with its own data, hitting limits of the deployment types, or wanting everything (code, data, domain, billing) under your company's own accounts. If the real problem is a slow start or a failing publish, fix that first: our guides on apps that go to sleep and failed deployments cover both.

Step 1: What in my app only works on Replit?

Before touching anything, make an inventory. Search the code for these and write down each one you find:

• Replit Auth. If users sign in with Replit's built-in login, their accounts live with Replit. This is usually the biggest piece of the move.
• Replit's storage services. Look for packages under @replit/ in package.json (or replit in Python requirements), such as the object storage client or the key-value database.
• The PostgreSQL database. Read through DATABASE_URL.
• Secrets. Every value in the Secrets tool, and the separate production Secrets in the Publishing pane.
• Environment variables Replit sets for you. Search for REPLIT_ in the code; anything that reads those will need a replacement value.
• Run configuration. The .replit file holds your run and build commands and ports. On the new host, you'll set these in its own settings.
• Scheduled deployments. Any timed job needs a new home, such as the new host's cron feature.

The inventory is also the start of your handover document. Our guide on documenting your app for handoff shows what else to record.

Step 2: How do I get the code out?

Use Git, not a one-time download. In your Replit app, add the Git tool, connect it to GitHub and push to a new private repository under your own account or organization. From then on, the repository is the source of truth. Replit's docs recommend a personal access token rather than a password for private repositories.

Then prove the code runs somewhere other than Replit:

1. Clone the repository on a computer or a fresh cloud environment.
2. Install dependencies from the lock file (npm ci for Node).
3. Create a .env file with test values for every variable in your inventory.
4. Run the build and start commands from .replit and open the app.

Anything that fails here would have failed on the new host too, and it's much cheaper to find it now.

Step 3: Where should the app run?

Match the host to what the app is, not to what's popular:

Whatever you choose, recreate three things from .replit: the build command, the start command and the port. Most hosts tell your app which port to use through a PORT environment variable, and the server must listen on it, on 0.0.0.0.

Step 4: How do I move the database?

Replit's databases run PostgreSQL 16, so standard Postgres tools work. Create the new database on a version that's the same or newer, then dump and restore. In your production database's settings, check the connection details and whether your setup allows connecting from outside the app.

pg_dump --format=custom --no-owner --dbname "$OLD_DATABASE_URL" -f prod.dump
pg_restore --no-owner --dbname "$NEW_DATABASE_URL" prod.dump

Do a practice run first. Restore into the new database, point a test copy of the app at it, and check row counts on your main tables against the original. Use the production database, not the development one: they're separate on Replit, and the development database holds test data.

Keep the dump file private. It contains every user's data.

Step 5: What about uploaded files and logins?

Files. Anything stored in Replit's object storage must be copied to the new storage service, and the paths saved in the database must be updated to match. Remember that files written straight to disk in a published Replit app don't survive a publish, so if users report missing uploads today, that data may already be gone.

Logins. If the app uses Replit Auth, choose the new login provider first (for example, the auth built into your new database platform, or a dedicated auth service). Then decide how existing users carry over. Most apps match users by email: create the accounts in the new system, keep the same internal user IDs so their data stays linked, and ask everyone to set a password or use a magic link on first sign-in. Tell users before the switch.

Step 6: How do I switch over without downtime?

1. A few days before: lower the TTL on your domain's DNS records so the change spreads quickly. Our guide to DNS records explains TTL.
2. Deploy the new app with production settings on its own temporary address and test the full flow: sign up, log in, pay, upload.
3. Announce a short maintenance window and stop writes on the Replit app (a maintenance page or read-only mode).
4. Take the final database dump, restore it, and recheck row counts.
5. Update DNS to point at the new host, then update webhook URLs (Stripe, email providers) and login redirect URLs.
6. Keep the Replit app and its database untouched for at least a week, in case you need to compare something.
7. Only then remove the Replit deployment, after exporting one last backup.

Quick answers

Can I export my code from Replit? Yes. Connect the Git tool to GitHub and push to a repository you own. That's the cleanest way, and it keeps history.

Can I take my Replit database with me? It's PostgreSQL, so you can dump it with pg_dump and restore it into another Postgres database, provided you can connect to it.

What's hardest about leaving Replit? Usually Replit Auth and stored files, because user accounts and uploads live in Replit's services rather than in your code.

Will my users notice the move? Not if you test on a temporary address, keep the maintenance window short and handle logins carefully.

Want help planning the move?

A migration is a good time to fix what's fragile instead of copying it to a new place. Our Replit app rescue can review the code and plan the move, and our custom software development team can take on bigger rebuilds of the parts that need it. You can also check who owns code made with AI before you move, or contact us with your inventory from step 1.