Replit deploy, then dead — no hosting after git push

Your replit deploy showed success, then the live link died — empty page, 502, or stale build — while the Repl still runs fine inside the editor.

You hit Deploy, copied the URL, shared it. Visitors see a spinner, error page, or yesterday’s version. You pushed to GitHub expecting CI to refresh production. Nothing changed on the public hostname. The Agent said deployment was ready. Runtime secrets, database target, and SSL were not.

What you see when replit deploy is dead

Symptoms map to deployment config, not random bugs.

• 502 or application error. Start command wrong, crash on boot, or missing module in production image.
• White screen on deploy URL. Client builds but env vars undefined in deployment secrets.
• Data missing live. App points at dev database or empty Postgres while Repl Table Editor had rows.
• Auth works in Repl, fails on deploy URL. Callback URLs still use the dev hostname.
• Git push did nothing public. No autoscale trigger or deploy failed silently in tab.
• Custom domain not secure. DNS or certificate pending while default deploy URL works.

Compare deploy logs with Repl console. If preview works and deploy URL does not, secrets and connection strings diverged. The replit database article covers when Agent migrations wiped the instance your deploy still uses.

Why replit deploy fails after git push

Replit splits editor runtime from deployed runtime. The Repl loads secrets from the Secrets pane for development. Deployments read Deployment secrets — a separate list. Agent adds keys to dev. Production never sees them unless you copy each name.

Git push updates repository files. Hosting, SSL, and autoscale deploy are separate pipelines. Push without a linked deploy flow leaves the old revision live. Users blame git when the Deployments tab shows failed or skipped builds.

Database connection strings differ. Dev may use Replit’s built-in Postgres URL. Deploy must use the production connection string Replit assigns — or external Postgres you configure. Agent seed scripts against dev do not migrate to deploy automatically.

Auth and OAuth follow hostname. Supabase or Replit Auth allowlists must include the *.replit.app deploy hostname and custom domain. AI templates hardcode REPL_SLUG dev URLs.

Same last-mile pattern as lovable deploy: code ships, URLs and secrets do not self-update.

Autoscale deploy adds cold-start and memory limits on top of config gaps. A Repl that boots fine in the editor can exceed deployment memory when the Agent added heavy dependencies. Logs show OOM or timeout — easy to misread as “Replit down” when the fix is slimmer start command or fewer packages.

Static deploy suits frontends; full-stack Node needs the right deployment type. Picking the wrong template ships a build that never matches how you run locally.

Fix replit deploy step by step

1. Open Deployments in the Repl. Find latest production deployment. Status must be live, not failed or superseded.
2. Read deploy logs. Note crash on start, missing env, or migration errors. Fix the first fatal line.
3. Copy Secrets to Deployment secrets. Match every name the app reads: database URL, session secret, API keys. No typos.
4. Confirm start command. Static vs autoscale vs reserved VM — match framework. Wrong command exits immediately with 502.
5. Point DATABASE_URL at production data. Verify Table Editor or external Postgres matches what deploy uses. Run pending migrations on that instance only after backup.
6. Update auth redirect URLs. Add deploy hostname and custom domain to Supabase or provider settings.
7. Trigger redeploy after secret changes. Secrets do not hot-reload on all tiers. Deploy again from the tab.
8. Wire git push to deploy if you want CI. Enable autoscale from branch, or run deploy manually after merge until pipeline is stable.
9. Fix custom domain DNS and SSL. Wait for valid cert before sharing branded URL.

Never run Agent schema resets against the database tied to your live deploy URL without export backup.

Health checks and always-on settings differ by plan. A Repl that sleeps in dev may need reserved VM or always-on for production APIs. Users report “deploy dead” when the first request after idle times out — wake settings, not broken code. Check deployment type matches your stack before you rewrite application logic or burn another Agent session.

Checklist before you trust replit deploy

• Latest deployment status is live with recent timestamp
• Deploy logs show clean boot, no repeating crash loop
• Deployment secrets mirror every dev secret the app needs
• DATABASE_URL targets the production instance you intend
• Auth completes on deploy URL in private window
• Git push triggers new revision if you rely on CI — verify in tab
• Custom domain serves HTTPS without warnings
• One write and one read succeed on live data

FAQ

Why is my replit deploy dead after a successful build?

Deployment uses separate secrets and runtime from the Repl editor. Missing DATABASE_URL, wrong start command, or auth callbacks still on the dev hostname leaves production running code that cannot reach your data or session store.

Does git push automatically update replit deploy?

Only if autoscale or static deploy is wired to your branch and build succeeds. Push alone does not configure SSL, custom domains, or production env. Check Deployments tab for the latest live revision.

How is replit deploy different from Lovable publish?

Both move code to a public URL. Replit keeps compute and database inside the same account. You must still set deployment secrets, run migrations on the production database, and align auth URLs — same last-mile gaps as lovable deploy.