How to host a Replit app somewhere else

A Replit app can combine code, publishing, a database, authentication, file storage and secrets. Moving it to another host is more than copying files: first find out which services it uses and which ones the new destination must keep running.

If you are still choosing a hosting type, see what hosting an AI-built website needs. If your general question is how to move a project from localhost to a public URL, start with our localhost publishing guide.

1. Sync the code and keep a rollback path

In Replit, review the Git pane and confirm that the connected repository contains the latest changes you intend to deploy. Replit’s version control documentation explains GitHub, commits and branches. Agent checkpoints are part of the Git history; still, check the latest commit and confirm GitHub sync has finished before deploying.

Before changing destinations, create an identifiable commit and a secure backup of any data you need to keep. Do not add .env files, credentials, private keys or customer exports to the repository. Do not shut down the current deployment yet; it is a reference while you test the replacement.

2. Inventory services, not just files

Inspect package.json, the start command, .replit, Dockerfiles and project documentation. Record what each part does:

• The frontend may build static files or depend on a running Node server.
• Login may depend on callback URLs, credentials or an identity provider configured in Replit.
• The app may connect to a database, store files or call external APIs.
• Replit secrets need to be configured securely in the destination environment.

Test the project locally or in the target environment, outside Replit’s preview. Check its build and start commands, port, routes and required variables for each process. If it is only a static frontend, do not buy a server just because Replit created the project. If it needs an API or persistent jobs, a dist directory alone is not enough.

3. Migrate the database and files carefully

Identify where development and production data live before changing DATABASE_URL. Replit separates these databases (development and production documentation) and documents its SQL database. Those pages describe the service within Replit, not a complete migration to another provider. For an external move, follow procedures compatible with the database engine and destination, and verify schema, extensions, roles and data. Make a verified backup before restoring; never test destructive commands on production.

Plan a short write freeze or final sync, create a backup, restore to the destination and validate users, records and relationships with test data. If you are moving PostgreSQL to another managed database, use our pg_dump and pg_restore migration guide. App Storage files, sessions and other service data need their own migration procedures.

4. Choose a destination by runtime and responsibilities

Hostbrid Projects can publish Git projects and run Docker services within plan quotas. Check runtime, storage, ports and resources before ordering; Dev serves static projects, while persistent services require a paid plan. Review current plans and limits.

If you need root access, operating-system control or network services and processes beyond Projects, consider a VPS, which you will administer. For WordPress or other managed PHP services, see Sites. Replit’s official custom domains guide explains its current setup; when moving a hostname, also review allowed domains and login callback URLs.

5. Test before moving the domain

Deploy first to a temporary URL. Check login, password recovery, data reads and writes, file uploads, email, callbacks and internal routes. Compare error logs and make sure no production request accidentally still points to the old service.

After validating the new version, change DNS using the destination’s instructions and check HTTPS. Keep the old version available during the transition. Decide what change would restore the old domain and what data must be synced before rolling back.

Moving an app can give you control over its code, destination and costs, but it does not guarantee a lower bill or automatic migration of Replit-connected services. If you cannot identify its backend, database or authentication, tell us the framework and dependencies before choosing a plan; do not send secrets or data dumps.