Replit app to production

What you can take out of Replit

The code comes out easily. Push it to GitHub from the Git panel, or download the project as a ZIP. Either way you get the full source.

Two things do not travel with it. Database contents stay behind, so you export them separately, for example with a pg_dump of the built-in Postgres database. Secrets stay behind too. List every name in the Secrets tool before you leave, then recreate them as environment variables in the new host. Never paste their values into the repository.

Replit-specific files such as .replit and replit.nix only matter on Replit. Replace them with a normal start command, a Dockerfile or your host's build settings.

What breaks first in a Replit app

• Replit Auth. If users sign in through Replit Auth, that login is tied to Replit. Moving off means a new auth provider and a plan to move existing accounts without locking anyone out.
• The built-in database. Convenient for a prototype. For production you want a managed Postgres you control, with backups, point in time recovery and a staging copy.
• No separation of environments. Development and production often share 1 database, so a test run can change real customer data.
• Generated code with no tests. The agent changes many files at once. Without tests you cannot tell what a change broke until a user tells you.
• Permissions in the UI only. Hiding a button is not access control. The server has to check every request.

Step by step: Replit to production

1. Push the code to a GitHub repository your company owns.
2. Export the database with pg_dump and restore it into a managed Postgres. Verify row counts table by table.
3. List every secret by name, recreate it in the new host and rotate anything that may have leaked.
4. Replace Replit Auth with a provider you control and migrate existing users by verified email.
5. Remove .replit and replit.nix, add a standard start command or Dockerfile, and deploy to staging first.
6. Add server side permission checks and tests for your 3 most important workflows, then CI.
7. Point the domain at production only after staging has run cleanly with real data.

The 3 ways to production, and what each costs

• Harden in place, from $5,000, 2 to 3 weeks. Lock down the database, fix auth, move secrets to the server, add monitoring. The frontend stays as it is. Right when you have under a few hundred users and the product still changes weekly.
• Rebuild the backend, keep the front, $15,000 to $25,000, 6 to 8 weeks. New API layer, cleaned data model, real permissions, integrations moved server side, tests and CI. Right when users like the product but the plumbing cannot be trusted with money or personal data.
• Full production rebuild, $25,000 to $35,000, 8 to 10 weeks. Same product decisions on a new stack, UX fixes from real usage, AI features designed in. Right when you are charging money, growing, and know exactly what version 2 should be.

When you should not move yet

If the app has no paying users yet, Replit Deployments can carry you for a while. Separate the development and production databases now, keep shipping, and move when revenue makes downtime expensive.