Deploy a Replit app to production: what to check before and after you publish

Symptom

Agent built the app, Preview works, and you press Publish. Then:

• The build succeeds but publishing fails at the last step, or the live URL returns 500 or 502.
• Sign-in, payments or API calls fail only on the published URL.
• Uploaded images disappear after the next publish.
• The Publish pane stops with "Migrations failed validation, please review".

Replit now hosts new development databases on its own infrastructure. Code that forces SSL on every connection shows this on startup:

Why it happens

Preview and production are two different places. When an app works in Preview but not at the published URL, Replit's troubleshooting guide says to compare secrets, database settings and webhook or redirect settings. The differences that bite:

• Secrets. Production has its own list under Publishing, Adjust settings, Production app secrets. Replit's docs disagree with themselves here: the Publishing page says secrets sync on publish, while the troubleshooting guide says they don't carry over. I don't rely on either. I check the list.
• Database. Your published app gets its own production database and its own DATABASE_URL. Agent can read production through a read replica but can't change it.
• Files. The published filesystem is not persistent and resets every time you publish.
• Network. The server must listen on 0.0.0.0. Autoscale and Reserved VM expose a single external port.
• Health check. Replit requests your homepage before going live. If it takes more than five seconds, publishing can fail at the final step.

The deployment type matters too:

Static is not an option for an Agent-built app, because Agent builds full-stack apps that need a server.

The fix

1. Fix Preview first. If Preview is broken, publishing won't fix it.

2. Choose the type. In Publishing, Adjust settings, pick Autoscale unless the app needs to stay awake. Expect a short cold start on the first request after Autoscale scales to zero.

3. Set production secrets. Go through every key your code reads and confirm it exists under Production app secrets. Your code can tell the environments apart: Replit sets REPLIT_DEPLOYMENT=1 only in a published app.

4. Bind the server correctly. In server/index.ts:

const port = Number(process.env.PORT) || 5000; // keep the port your app already uses
app.listen(port, "0.0.0.0", () => {
  console.log(`Server listening on ${port}`);
});

If your .replit file lists ports, Replit's troubleshooting guide says one of them must have externalPort set to 80 for publishing to pass. Map 80 to the port your server listens on:

[deployment]
build = "npm run build"
run = "npm run start"
 
[[ports]]
localPort = 5000   # the port your server listens on
externalPort = 80

If you see "No run command configured" even though one is set, Replit's fix is to remove the run command in deployment settings, add it again, save and republish.

5. Let Replit migrate the database. When the Publish pane shows "Development database changes detected", it compares both databases and generates SQL. Answer rename questions carefully: choosing No, create new column for a real rename drops the data. Read the SQL even when the pane isn't orange, because a dropped empty table shows no warning. Use Create preview deploy to click through the app on a migrated copy (it expires after two hours), then Approve and publish.

Remove any schema commands from your build and start scripts. Replit says they would run on every publish, outside its review. Your build commands may differ from these; what matters is what is missing:

{
  "scripts": {
    "build": "vite build",
    "start": "NODE_ENV=production node dist/index.js",
    "db:push": "drizzle-kit push"
  }
}

Keep db:push for development only. It should not appear inside build or start.

6. Fix the SSL error. Replit's database docs give this pattern:

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: process.env.NODE_ENV === "production" ? { rejectUnauthorized: false } : false,
});

7. Move uploads out of the filesystem. Use App Storage, Replit's object storage, for anything users upload.

8. Speed up startup. Move slow work, such as seeding or warming caches, out of the request for the homepage.

9. Test the live URL. Sign up, pay, sign out and use the core feature on the published address, on your phone. Then open Monitoring for status codes, response times, CPU and memory.

How to prevent it

• Turn on monitoring when you publish so Replit emails you if the app goes down. Agent can also triage Monitoring alerts and attempt fixes. I'd leave the experimental Auto-republish setting off and review each fix before it goes live.
• Leave Block publishing of critical vulnerabilities on, and run the deep security scan before a launch.
• Connect a custom domain early. Region is locked at first publish, and remixing to move region can change the .replit.app address.
• To undo a bad release, Replit's help points to Publishing, History, where you can redeploy the last working version. That does not restore the production database, and neither does a checkpoint rollback: Replit's docs send you to point-in-time restore for that.

When to get help

The prototype to product guide covers everything around a launch, and the AI-built app launch guide has the full checklist. If payments are part of the release, read Replit Stripe payments. If you're weighing a move off Replit, start with exporting code from Replit.

The free vibe-code health check is a quick first pass. If the app needs fixing before it can go live, that's a Rescue Sprint.