How to deploy a Replit app to production, step by step

On Replit, "deploy" is a button. That's the good news, and also the trap: the button works whether or not your app is ready for real users. This guide is the runbook we follow when we take a client's Replit app live.

Step 0: Is the app ready to publish?

Before touching deployment settings, run through our Replit Agent security checklist. At minimum, confirm three things:

• No API keys in the code or in the frontend bundle.
• Every private API route checks who is asking and whether they own the data.
• You can log in as two different users and each sees only their own data.

Step 1: Choose the deployment type

Replit offers several deployment types. The short version:

Your app	Choose
Web app or API with normal, uneven traffic	Autoscale
Must never sleep: bots, websockets, queues, long jobs	Reserved VM
Pure HTML/CSS/JS, no server	Static
A task that runs on a schedule (reports, syncs)	Scheduled

The full trade-offs, including cold starts and costs, are in Replit Autoscale vs Reserved VM vs Static vs Scheduled.

Step 2: Make the app production-aware

• Bind to the right port and host. Listen on 0.0.0.0 and the port Replit provides, not localhost.
• Use a production build. The run command for the published app should start the built app (for example npm run build then npm start), not a dev server with hot reload.
• Detect production in code. Replit sets environment variables in published apps (such as REPLIT_DEPLOYMENT) that let you switch off debug output and dev-only routes.
• Answer the publish health check fast. When you publish, Replit checks that your homepage (/) returns a 200 response within about five seconds. Slow startup work (database migrations, big data loads, missing secrets) makes publishing fail at the last step. Keep / fast and move heavy startup work to the background. See Replit's publishing troubleshooting.
• Add a health route. A simple GET /health that returns 200 when the app and database are reachable makes monitoring trivial.

Step 3: Set production secrets

Open the publishing settings and confirm every secret the app needs is present for the published app. Use live keys in production and test keys in development (Stripe, email providers). Rotate any key that has ever appeared in code or in a chat with Agent.

Step 4: Prepare the production database

Published apps get a production database that is separate from the development database Agent works on. On first publish it gets the schema but not your test data. Decide what reference data (plans, categories, admin user) needs to exist in production and how you'll create it. Read how Replit's development and production databases work before your first launch.

Step 5: Connect your domain

1. Publish once to get the .replit.app URL and check that it works.
2. In the publishing settings, link a custom domain. Replit shows the DNS records to add.
3. Add those records at your registrar or DNS provider (Cloudflare, Namecheap, GoDaddy…). If you use Cloudflare, follow Replit's instructions on proxy settings while the domain verifies.
4. Wait for verification and HTTPS, then test both the apex domain and www.

Step 6: Monitoring and alerts

• Uptime: point a free uptime monitor at your /health route and alert by email or Slack.
• Errors: add an error tracker (Sentry or similar) so you hear about failures before customers do.
• Logs: check the published app's logs after launch, and log enough context (route, user ID, error) to debug without guessing.
• Costs: set spending alerts on Replit and on every paid API the app calls.

Step 7: A release routine you can repeat

1. Make changes in the workspace and test them there, ideally with two test users.
2. Back up production data before any change to the database schema.
3. Publish.
4. Smoke-test the live app: login, the main workflow, one payment in test mode if relevant.
5. If something breaks, republish the last good version first and debug second.

Launch-day checklist

• Security checklist passed, no must-fix items open
• Correct deployment type and a production run command
• Production secrets set, live keys in production
• Production database ready, with a tested restore
• Custom domain and HTTPS working on apex and www
• Uptime monitor, error tracking and spending alerts on
• Rollback plan written down

Not sure where you stand? The free Replit Readiness Score gives you a score in two minutes. Or let us review it for $199, or ship it for you in 5 days with the Ship-It Sprint.

FAQ

What is the difference between running and publishing on Replit?

Clicking Run starts your app inside the workspace for development. Publishing creates a snapshot of the project that runs on Replit's cloud infrastructure with its own URL, and it stays unchanged until you publish again.

Which Replit deployment type should I choose?

Autoscale for most web apps and APIs with variable traffic, Reserved VM for apps that must always be on (bots, websockets, background workers), Static for sites without a backend, and Scheduled for recurring jobs. See our comparison guide for details.

Can I use my own domain on Replit?

Yes. Published apps get a replit.app subdomain by default, and you can link a custom domain from the publishing settings by adding the DNS records Replit gives you at your domain registrar.

How do I roll back a bad deployment on Replit?

Keep the last known good version identifiable, test changes in the workspace before publishing, and republish from a checkpoint if a release breaks. For database changes, back up before publishing, because rolling back code does not automatically roll back data.