How to export my Replit app and host it elsewhere

To move your app off Replit, download the code with Download as zip or Git, dump the production database with pg_dump, recreate the Secrets and run the app on your own server with the commands in the .replit file. Then move the domain. The code leaves easily; database, auth and files need care.

Heartscale’s recommendation: run pg_dump on the production database with the app offline, and restore it into an empty database first so you can check the data before cutover. If the app uses Replit Auth, App Storage or Connectors, solve each one before you move the domain; with real users, get the plan reviewed before you start.

Before you start: what leaves and what stays

Replit documents a manual copy of an app in Manually copy a project to another workspace. That guide targets another Replit account, but it shows what does not travel with the code. Off Replit, the list is the same and grows a little:

Part	Where it lives on Replit	How it leaves
Code	Project files	Download as zip or Git
Database	Development and production PostgreSQL	pg_dump and pg_restore
Secrets	Editor and deployment Secrets, kept apart	Recreated by hand
Uploaded files	App Storage (Google Cloud Storage)	Download the objects
Sign-in	Replit Auth or Clerk	A planned switch
Integrations	Tools → Connectors	Replaced with your own
Domain	Publishing → Domains	DNS change or transfer

If the app lives in a team workspace, check with your admin first. With Ban source code export turned on, zip downloads are blocked.

Step 1: get the code

Download as zip (Projects and files): open the three-dot menu at the top of the file tree and choose Download as zip. If it fails, open the Shell and run:

zip -r project.zip .

Projects over 200 MB need a smaller archive. The docs suggest excluding folders that get rebuilt:

zip -r project.zip . -x ".cache/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*"

Do not include .cache in a manual zip. According to the docs, it holds cached Secret values.

Git: link your GitHub account from your account’s connected services, open the Git tool in the project and connect the repository. Auto-sync in the Git pane syncs both ways, and a fine-grained personal access token gives a more reliable connection. Remember that GitHub only receives committed files: ignored files and uncommitted changes stay behind.

Prefer Git. It keeps history and lets the new server deploy on every push.

Step 2: find out how the app runs

The .replit file controls the app’s behavior and is hidden by default (Replit App Configuration). It uses TOML. Look for three things:

• run: the command behind the Run button.
• The [deployment] section: build runs before the deploy and run starts the published app. Those are the commands your new server will use.
• [[ports]]: localPort is the port the app listens on.

replit.nix lists the system packages the project uses, in the deps array. Install the equivalents on the new server.

The deployment type tells you a lot too (Publishing). Static hosts a site that does not change based on user input. Autoscale and Reserved VM run a server. Scheduled runs the app at set times and becomes a scheduled job on the new server.

Step 3: dump the production database

Replit keeps a development database apart from the production database that serves the published app (Development and production databases). Your live data is in production. The $DATABASE_URL in the Shell points to development.

To get the production string (Connection details): in the Tools pane, open Database, select Production Database and open the Settings tab. Production accepts connections from any PostgreSQL-compatible client. Development does not accept external connections.

Take the app offline before the final copy: anything written after pg_dump starts is not in the file. The command from the docs:

pg_dump -Fc "PRODUCTION_STRING" --no-owner --no-privileges -f backup.dump

On the target, a PostgreSQL you control, managed or on a VPS, the docs restore like this:

pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges --exit-on-error -d "NEW_DATABASE_STRING" backup.dump

--clean drops objects with matching names in the target before loading. Run it against a new, empty database. No output means the restore worked. In our reviews, we compare the row count of every table between the Replit database and the new one before we clear the cutover.

backup.dump holds your users’ data. Never commit it to a repository. Keep it somewhere safe and delete stray copies afterwards.

Step 4: recreate the Secrets

Secrets live under + in the editor tab bar → Secrets (Add secrets). Replit keeps development and deployment secrets in separate stores (Deployment and publishing). Check both, because the published app may use different values.

The values do not travel with a copy. List every Secret’s name, including Account Secrets linked to the project, and recreate them as environment variables on the new server. The new database string replaces the old one, under the name the code reads, usually DATABASE_URL.

Step 5: move files and replace integrations

App Storage runs on Google Cloud Storage (App Storage). To download, open the App Storage tab, go to Objects and use the download icon next to each file. Replit’s official client libraries authenticate automatically inside Replit. The docs do not say whether the bucket answers from outside. So plan your own storage and update the code that reads and writes files.

Integrations under Tools → Connectors must be reconnected even in a copy inside Replit. Off Replit, replace each one with your own integration and your own keys.

Step 6: sort out sign-in

Replit Auth uses Replit’s login system and infrastructure, and users sign in with Replit accounts (Replit Auth). The docs do not say whether it works with the app hosted elsewhere. Treat it as a dependency and solve it before cutover.

Replit offers an Agent-run migration from Replit Auth to Clerk that moves your users’ identity data (Migrate from Replit Auth to Clerk). The Clerk tenant it creates is managed by Replit. You can also wire up your own Clerk app, but the docs warn that deleting the managed app removes its tenant (Clerk Auth). Test sign-in with real users on a copy before you delete anything.

Step 7: deploy to the new server

With the commands from step 2, the path is the same as for any Node or Python app: install dependencies, run build, start with run behind a reverse proxy with HTTPS. If you prefer a dashboard, Coolify installs on a Linux VPS with at least 2 CPU cores and 2 GB of RAM and deploys from GitHub.

For a Static deployment, serving the build output is enough.

Step 8: test before you switch

• Open inner routes directly by URL and reload.
• Sign in and out with a real user.
• Read, write and upload a file.
• Check that each integration responds with the new keys.
• If you had a Scheduled deployment, confirm the job runs once, on the new server only.

Step 9: move the domain

Domain from another registrar. On Replit, it uses an A record and a TXT record, set up under Publishing → Domains (Custom domains and DNS). At cutover, disconnect the domain from the app on Replit and point the A record at your DNS provider to the new server.

Domain bought through Replit. Transfers to another registrar go through Replit Support, after ICANN’s 60-day wait (Domain purchasing). Meanwhile, you can edit DNS under Tools → Domains → Replit Cloud, which accepts A, TXT and MX records. Renewal has its own Auto renewal toggle.

Step 10: wrap up on Replit

1. In Publishing, use Unpublish. The app goes offline and stops incurring deployment charges, but files, code and database stay (Deployment and publishing).
2. If something goes wrong, Publish on the old project brings the app back with its data from the moment it went offline.
3. Once you have checked the new database, remove the old one under Database → Settings → Remove database. There is a 7-day window to recover it through support; after that, it is gone.

How long it takes

Replit’s docs plan for 15 to 60 minutes of downtime at cutover for a copy between accounts. Off Replit, add the time to replace sign-in, storage and integrations. The steps are close to those for exporting a Bolt.new project and leaving Lovable. See also our platform migration service.

Do it yourself or hire help?

This guide is enough when the app is simple; the table shows when it pays to have a team alongside you.

Situation	Path
A Static deployment or an app with no database, and someone on the team who can run a Node or Python server	Do it yourself with this guide
A production database with real users’ data	Bring in a team for the pg_dump, the restore and the checks at cutover
Replit Auth, App Storage or Connectors in the app	Request a Heartscale diagnostic: it lists each dependency and the cutover risks
A tight deadline, or no one technical on the team	Hire the migration at a fixed price

Request a Heartscale diagnostic

Our team maps what your app uses from Replit: production database, Secrets, App Storage, Replit Auth and Connectors. You get a migration plan, the cutover risks and a fixed price.

The launch-price diagnostic costs US$ 19 (was US$ 79) and is credited toward the migration if you go ahead. We only work on apps whose owners can prove they own them.

Request the diagnostic