How to Move a Replit App to Your Own Hosting

Replit makes the first version of an app remarkably easy: an agent that builds it, an editor in the browser, and a Publish button that puts it online. For plenty of projects, that's where the story ends, and that's fine.

But people move off Replit for real reasons. Costs that are hard to predict once usage grows. Wanting a standard hosting setup a developer can take over. Wanting the database somewhere they control. Or simply wanting the app and the tool that built it to be separate decisions.

This is how to move, and what tends to break when you do.

Replit's products and pricing change often; details below reflect September 2026. Check Replit's docs for current specifics.

First: do you need to move at all?

Replit has several deployment types — Static, Autoscale, Reserved VM, and Scheduled — and choosing the right one fixes a lot of complaints without moving anything:

Autoscale scales down when idle, which keeps costs low for quiet apps but means cold starts.
Reserved VM is always on at a fixed monthly price — better for apps with steady traffic, websockets, or background work.
Static is cheapest for frontends with no server.

If your problem is "my app is slow to wake up" or "the bill is unpredictable," try switching deployment type first. If your problem is control, portability, or wanting to own the stack, read on.

Step 1: get the code out

Two ways:

GitHub (recommended): connect GitHub from Replit's version control panel and push the project to a repository. This keeps history, and you can keep editing in Replit while deploying from GitHub if you want to move hosting without moving your workflow.
ZIP download: from the file tree menu. Fine for a one-off, but you lose history.

Once it's on GitHub, clone it on your own machine and try to run it. This is the most useful thing you'll do in the whole migration, because it shows you everything that only worked because of Replit.

Step 2: find the Replit-specific parts

Things that commonly work on Replit and break elsewhere:

Secrets. Replit stores secrets in its own panel and injects them as environment variables. They are not in your code — which is good — so you need to list every one and recreate it on the new host. Search the code for process.env. or os.environ to find them all.
The .replit and replit.nix files. These tell Replit how to run your app and which system packages to install. Elsewhere they're ignored, so translate them: the run command becomes your start command, and Nix packages become whatever your new host uses (a Dockerfile, a buildpack, or a runtime version setting).
Hardcoded ports and hosts. Apps often assume a specific port. Most hosts tell your app which port to use through a PORT environment variable; make sure the app reads it and binds to 0.0.0.0.
Replit's database and storage services. If your app uses Replit's key-value store or object storage through Replit's own SDK, that code needs rewriting against a standard service. If it uses Replit's PostgreSQL, the data needs exporting (next step).
Replit Auth. If users sign in with Replit accounts, you'll need a different auth provider — and a plan for existing users.
Development vs production databases. Replit separates development and production databases. Make sure you export the production one.

Step 3: move the data

For a Postgres database, the standard tools work:

# Export from the source database
pg_dump --no-owner --no-acl "$SOURCE_DATABASE_URL" > backup.sql

# Import into the new one
psql "$TARGET_DATABASE_URL" < backup.sql

Then check it actually arrived: compare row counts for your important tables between the old and new databases. Do a practice run days before the real move, so the final cutover is a rehearsed step rather than an experiment. (More on doing this safely in How to Back Up a Postgres Database.)

If your app is live and taking writes, plan a short maintenance window: stop writes, take the final dump, import, switch over. For most small apps that's minutes.

Step 4: pick where it goes

If your app is…	Consider
A frontend only	Vercel, Netlify, Cloudflare Pages
A web app with a server and a database	Railway, Render, Fly, or a managed development platform
Something you'll keep building with AI	A platform where the agent works against the running app
Something you want total control over	A VPS — if you're ready to run it yourself

Whatever you choose, make sure it provides a managed database with backups, automatic HTTPS, environment variables for secrets, and deploys from GitHub. Those four cover most of what Replit was quietly doing for you.

Step 5: cut over

Deploy to the new host and test everything on its temporary URL — sign-up, login, the main flows, payments in test mode.
Set up the production database and do the final data migration.
Update anything that references the old URL: OAuth redirect URLs, payment webhooks, email links.
Point your domain at the new host. (If your domain was connected to Replit, you'll be changing DNS records — see How to Connect a Custom Domain to Your App.)
Keep the Replit deployment running, read-only, for a few days in case you need to roll back.
Once you're confident, shut it down so you stop paying for it.

The honest trade-off

Leaving Replit means giving up a lot of convenience. The editor, the agent, the hosting, and the database lived in one place, and now they don't. You gain control and portability, and in exchange you take on — or pay someone else to take on — the infrastructure Replit was handling.

If that trade makes sense for your app, the move itself is rarely more than a day's work. The part that takes time is finding everything that "just worked" — which is why the first thing to do is run it somewhere else and watch what breaks.

EasySpawn is a place to move an app you're still actively building: managed Postgres with daily backups, automatic SSL, your own domain, and Claude Code working in the same environment the app runs in. We're pre-launch — see how it works for AI-built apps or join the waitlist.