Your Replit app runs. Will it survive being deployed?
Replit collapses building and hosting into one place — which is the magic and the trap. The workspace behaves like an always-on dev machine with its own secrets, database, and a public preview URL. Deployments are a different environment with different rules, and most Replit launch failures live exactly in that gap.
And then there’s the agent. The July 2025 incident where Replit Agent deleted a founder’s production database mid–code-freeze was a wake-up call for everyone shipping real apps from a repl. Replit has improved the defaults since, but the structural lessons stand. Here’s what to verify.
The 8 risks real Replit apps ship with
Compiled from documented incidents, CVEs, and platform docs — the same failure modes a Launch Check hunts for in your app, with what to do about each.
-
Works in the workspace, breaks deployed — secrets don’t carry over
Replit keeps two separate secret stores: workspace Secrets and deployment secrets. The agent wires your app against the workspace store, so everything works in preview — then the published app crashes or silently falls back to defaults because DATABASE_URL was never added to the deployment. Static deployments don’t support runtime env vars at all.
What to do: Before publishing, diff the deployment’s secret list against Tools → Secrets and add everything the server reads. Make the app fail loudly at boot on missing vars. If the app needs runtime secrets, deploy Autoscale or Reserved VM — never Static. Restart after secret changes.
-
Agent-built Express routes with no ownership checks
Replit Agent’s default output is React + Express + Postgres, optimized for “working demo fast.” Security reviews keep finding the same pattern: routes that trust the request body’s user ID, permission checks only in React, and CRUD endpoints where authentication exists but the ownership check — does this user own this record? — was never written.
What to do: Audit every route: auth middleware on all non-public endpoints, plus an ownership/role check on every query that takes an ID. Run Replit’s Project Security Center scan, then verify manually as user B with user A’s record IDs. Replit Auth identifies users — authorization is still entirely on you.
-
The agent can touch your production database
In July 2025, Replit Agent deleted a founder’s production database during an explicit code freeze, then claimed rollback was impossible (it wasn’t). The root cause was structural: one database shared between the workspace agent and the live deployment, with the agent running fully privileged. Replit has since shipped dev/prod database separation — but it rolled out gradually, and agent checkpoint rollbacks still don’t restore the database unless you explicitly tick it.
What to do: Verify your app actually has separate development and production databases (older apps may predate the rollout). Never let the agent debug against production data. Schedule your own pg_dump backups to storage outside Replit’s rollback system — and test a restore once.
-
Data written to the deployment filesystem silently disappears
Deployment filesystems are ephemeral: they reset on every re-publish and churn with autoscaling. The agent happily writes uploads, generated PDFs, or a SQLite file to local disk — it works for days, then vanishes on the next deploy. Builders discover this when users report their files are gone.
What to do: Grep for fs.writeFile, disk-storage uploads, and sqlite usage. Relational data goes to the Postgres database; files go to Object Storage or an external bucket. Then re-deploy and confirm user data survives.
-
Real users on the .replit.dev URL instead of a deployment
Every workspace has a public preview URL that looks shareable — but it’s only live while you’re working, can change between sessions, and exposes your half-finished app to anyone with the link. Builders get “your app is down” messages every time they close the editor.
What to do: Publish a real deployment and only share the .replit.app URL or a custom domain. The workspace is your dev environment, never your hosting.
-
On the Starter plan, your entire codebase is public — including git history
Free-plan apps are public: source, commit history, and anything ever pasted into code, scraped continuously by bots hunting API keys. The Secrets pane is excluded — but “temporary” hardcoded keys are not, and a key committed once stays in the visible history after you delete it from the file.
What to do: If the app has real users, move to a plan with private apps. Search the project and its git history for keys (sk-, AKIA, postgres://) and rotate everything that ever appeared — assume it’s harvested.
-
Autoscale kills background jobs, sessions, and first-request latency
Autoscale scales to zero: the first request after idle eats a multi-second cold start, anything outside request/response (setInterval jobs, queue workers, long websockets) dies when instances spin down, and agent-generated apps often use in-memory session stores — so users get logged out whenever instances recycle. None of this shows in the always-on workspace.
What to do: Match deployment type to workload: Reserved VM for bots, websockets, or background loops; Scheduled deployments for cron. Move sessions and caches into Postgres or an external store. On Autoscale, set minimum instances above zero for latency-sensitive apps.
-
The serverless Postgres sleeps — and bills by compute time
Replit’s SQL database (Neon-backed) suspends after ~5 minutes idle. Cut one way: first-query-after-idle timeouts your agent-generated code doesn’t retry. Cut the other: keep-alive pings and chatty pools that hold it awake 24/7 and quietly burn your monthly credits.
What to do: Configure the client for serverless — pool timeouts and retry-on-connect for the wake-up path. Audit anything that polls the database. Load-test the wake-from-idle path before launch, and watch compute-hours during week one.
Why trust this list? We build with AI ourselves and we've deployed production systems to millions of users. Reviewing and hardening AI-built apps is all we do — we know exactly what Replit gets right, and exactly where it breaks.
A checklist can't read your app. We can.
The items above are the pattern — your app is the specific case. A Launch Check ($799, one-time) is a senior engineer reviewing your actual Replit app across security, architecture, tests, delivery, and operations — back in 24–72 hours as a severity-ranked launch plan, plus a 15-minute findings call.
Start a Launch Check Not ready? Self-score free in 2 minutesGuarantee: If the report doesn’t change how you launch, tell us within 14 days — full refund.
Already live and something's breaking? Emergency rescue — same-day triage →
Common questions
Can Replit Agent really delete my database?
It happened — July 2025, to a real production app, during a code freeze. Replit has since separated development and production databases and improved guardrails, but two cautions remain: verify your app actually has the separation (older projects may not), and remember checkpoint rollbacks don’t restore the database by default. Keep your own backups outside the platform.
Autoscale or Reserved VM — which should I deploy?
Autoscale for request/response web apps that can tolerate cold starts and keep no state in memory. Reserved VM for anything with websockets, background jobs, bots, or in-memory state. The most common mistake is deploying an app with background loops to Autoscale — they silently stop running when instances scale down.
Is Replit safe for production apps?
Yes, with the discipline the workspace doesn’t force on you: deployment secrets configured separately, ownership checks in every route, persistent data off the local filesystem, the right deployment type, and your own backups. That gap between “runs in the workspace” and “survives production” is exactly what a launch review covers.