Moving your app off Replit
Moving an app off Replit means moving four things, and only one of them comes along by itself. The code exports in a click. The database, the secrets and any uploaded files have to be moved by hand, and if the app signs people in with Replit's built-in login, sign-in has to be rebuilt. Replit was also doing jobs you may not have noticed: hosting, deploys, checkpoints you could roll back to, and the security scan. Each needs a new home before customers move.
For a small app with no users it is a short job. For an app with customers it is a planned move with a backup first and a short maintenance window at the end. Done in the wrong order, you end up with half-moved apps or a live database nobody has a copy of.
Below: what exports and what does not, the order, what changes if you are moving to Claude Code or Cursor, and what to have in place before you tell anyone.
In founders’ words
“I don't have to use any other apps, I don't have to use GitHub, Veracell or any of these other apps. Even to this day, no idea what they are or how to use them.”
“please let me know how you recommend the best way to move my 10+ projects over to Claude Code or GPT in a way that gets the same results, cheaper, better, faster, etc.”
“I have an original Replit project and a remix/test copy and read only checks show the same PostgreSQL system identifier and database OID for both.”
What exports, and what does not
The code is the easy part. Download as zip from the file tree, or better, push it to GitHub from the Git pane, which also gives you history from here on. Delete the .replit and replit.nix files in the same commit; they tell Replit how to run the app and mean nothing elsewhere.
The database depends on which one. Every Replit app has a development database, which Replit says is "only accessible from within your app", and a production database created when you publish, which has a connection string in its Settings tab. You export the production one with pg_dump from any machine, and the development one from Replit's Shell. Older Neon-era apps may still share one database for both, which is its own risk.
Secrets copy out of the Secrets pane as a .env file, but any key that Replit issued for a Replit-managed service has to be reissued at the destination. Files in App Storage come down one at a time; there is no documented bulk download, so ask the agent to write a script that lists and fetches them.
The order that keeps your data safe
- Push the code to GitHub first. Nothing else until a copy exists outside Replit.
- Back up the production database now with pg_dump, then restore that file into a fresh database somewhere else once. A backup you have not restored is a guess.
- Pick one host and one database provider, and use them for every project you move. One setup to learn, not ten.
- Create the new database, run the app's migrations there, and import the backup. Check the row counts match.
- Put the secrets in the new host's environment settings. Reissue any Replit-managed keys.
- Deploy to the new host with a copy of the data, and click through sign-up, login, payment and the main thing the app does.
- For the switch: a short maintenance window, a final export, import, point the domain, and keep Replit running untouched for a week as the fallback.
If you are moving to Claude Code or Cursor
Replit was your editor and your host in one place. Claude Code and Cursor are only the editor. They do not run the app for anyone else, so you still need the host, the database and the secrets above, and that is the step most people miss when a friend says "just use Claude Code".
Move one project at a time, starting with the least important, and give each a short rules file in the repository: the stack, how to run it, how to run the tests, and what not to touch. The agent reads it every session, so you stop re-explaining. Replit's security scan covered the old setup; the moved version needs its own check.
You can also split the move in two: keep Replit as the host for now and do the editing in Claude Code through GitHub. That lets you leave the agent you are unhappy with before you take on hosting.
What Replit was doing for you
Each of these needs a replacement at the new home, or you will notice its absence the first time something goes wrong.
- Checkpoints and rollback. Git history replaces them, as long as every change is a commit.
- Separate development and production databases on newer apps. A staging copy with its own database replaces it. Confirm you have it; older Neon-era apps shared one.
- Deploys and HTTPS. The new host does both once it is connected to GitHub.
- The security scan. A scan on the repository, plus a two-account test that one user cannot read another's records.
- Secrets kept out of the code. The host's environment settings, with the rule written into the agent's file.
- Built-in login. Replit Auth signs people in with a Replit account and, by Replit's own docs, an app hosted elsewhere needs its own sign-in. A managed auth provider replaces it, and users sign in again once.
Before you tell customers
Scheduled backups on the new database, and one restore already done. Error alerts to your phone or email. A staging copy the agent works in, so the live app only changes after staging works. A billing alert on every new service. Password reset and any email the app sends tested from the new domain, because that is where the first support messages come from.
If the app has no customers, none of this needs an outside hand; the steps on this page and a coding agent are enough, and you will know your own setup afterwards. If a business runs on the app, the move is the moment to get the whole thing read by someone who has run software, because the cheap time to fix structure is before it is live in a new place. We do that read, and it starts with a free call.
| What | Comes with the code export? | How to move it |
|---|---|---|
| Code | Yes | Push to GitHub from the Git pane; delete .replit and replit.nix |
| Production database | No | pg_dump with the connection string from its Settings tab; restore into the new provider |
| Development database | No | pg_dump from the Replit Shell; it is not reachable from outside the app |
| Secrets | No | Copy the Secrets pane as .env; reissue any Replit-managed keys |
| Uploaded files (App Storage) | No | Script that lists and downloads every object; upload to new object storage |
| Built-in login | No | Rebuild with a managed auth provider; users sign in again |
| Checkpoints and chat history | No | Git history from now on; copy any decisions from the chat into a notes file |
Questions
Can I just download the zip and upload it somewhere?
The zip gets you the files and nothing else: no database, no secrets, no uploaded files, no history. It will not run on another host until those exist and the Replit-only files are removed. Pushing to GitHub instead gives you the same files plus a record of every change after.
Where is my Replit database and how do I get the data out?
Replit gives each app a development database and, once published, a production one. The production database has a connection string in its Settings tab, and pg_dump against it from any machine gives you a file you can restore elsewhere. The development database is only reachable from inside the app, so run pg_dump from Replit's Shell. If both report the same database identifier, they are one database.
Do I lose my checkpoints and chat history?
Yes. Checkpoints are Replit's, and the chat does not export. Before you leave, paste the decisions that matter, such as why a table is shaped the way it is, into a notes file in the repository. Git history takes over from the first commit.
Will an app the Replit Agent built run outside Replit?
Mostly. The parts that do not are the ones tied to Replit services: the built-in login, App Storage, and any package that starts with replit. Ask the agent to list every import and setting that mentions Replit, and swap each one before the first deploy. Ports and start commands also change with the host.
Should I keep Replit for hosting and only change the coding tool?
It is a reasonable first step if the complaint is the agent and not the hosting. Connect the project to GitHub, edit in Claude Code or Cursor, and let Replit pull and deploy. You get one change at a time instead of two, and you can still move the hosting later with the code already in GitHub.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.