Routes with no gate
Generated Express and Flask routes check nothing about the caller, and CORS answers every origin. We add auth middleware, validate every body, and lock CORS to your domains.
Fixed by Security hardeningReplit to production
Replit shipped your first version. We ship the one you can bill for
Replit Agent builds and hosts an app in one place, which is exactly what you want on day one and exactly what hurts on day ninety: hosting you can't leave, storage that was never meant for your data, and a server that trusts every request. Here is what we fix, and when it's worth moving.
In short
Taking a Replit app to production means separating the app from the environment it was born in: Express or Flask routes with no authentication middleware and CORS open to everyone, session secrets with a hard-coded fallback, relational data kept in Replit's key-value store, a schema that was pushed rather than migrated, and hosting on Replit Deployments whose cold starts and per-compute pricing surprise you at scale. Gen2Prod audits the project for free, fixes what matters at a fixed price from $290, and moves the hosting or the database only when there's a concrete reason.
- What Replit generates
- A Node/Express or Python Flask/FastAPI server with a React front end, typically in one repl
- Data
- Replit's Postgres (Neon-backed) or the Replit DB key-value store; schema usually pushed with Drizzle, not migrated
- Where it lives
- Replit Deployments — Autoscale or a Reserved VM — with secrets in Replit Secrets
- What we work in
- A Git export of the repl, by pull request; hosting stays or moves depending on the audit
- What it costs
- Free audit first, then from $290 per fix; full sprint quoted in 24 hours
What Replit apps get wrong in production
The list we find on most Replit projects, in the order it matters. Each one links to the service that fixes it.
Relational data in a key-value store
Replit DB is a convenient dictionary and a poor database: no relations, no indexes, no transactions. We move it to Postgres with a real schema and migrations, and keep every record.
Fixed by Database & queriesSchema by `db push`
The schema was pushed straight to the database, with no migration history and no way back. We introduce versioned migrations so a schema change is reviewable and reversible.
Fixed by Database & queriesCold starts and a bill that scales with users
Autoscale deployments sleep, and the first request pays for waking them; a busy app's compute costs climb faster than its revenue. We measure, then either tune the deployment or move it to a host priced for your shape of traffic.
Fixed by Deploy & CI/CDOne `server.js` for the whole product
Every route, query and helper in one file that grew with the prompts. We split it into modules so a change is small and testable.
Fixed by Refactor & cleanupYou find out from users
No error tracking, no uptime check, and logs that scroll past in the Replit console. We add monitoring and alerts wherever the app ends up hosted.
Fixed by Monitoring & alertsWhat we keep
A cleanup isn’t a rebuild. Replit did real work, and most of it stays.
- The app itself — the code is usually salvageable, and rebuilding it would cost more than fixing it
- Your data, all of it, through any storage or hosting move
- Replit as the editor, if you like working there; the repo can stay synced
- Replit hosting, when the audit shows it's fine for your traffic — moving is a decision, not a default
Replit — questions we get asked
Should I move my app off Replit hosting?
Not automatically. Replit Deployments are fine for many apps. Move when one of three things is true: cold starts are hurting real users, the compute bill is climbing faster than revenue, or you need something the platform doesn't offer — a specific region, a long-running worker, a compliance requirement. The free audit measures your app against all three and gives you a straight answer.
Is Replit DB fine for production?
For a to-do list, yes. For anything with users who own records that relate to other records, no — it's a key-value store with no relations, indexes or transactions, and it will get slow and then inconsistent. We move that data to Postgres with a proper schema, and you keep every row.
Can you move my Replit Postgres to Supabase or Neon?
Yes. Replit's Postgres is Neon-backed, so a move to your own Neon or Supabase project is a straightforward dump and restore with the connection strings updated. We add versioned migrations at the same time, so future schema changes are reviewable.
Why does my Replit app go to sleep?
Autoscale deployments scale to zero when idle, and the next request waits while the server starts. A Reserved VM stays up but costs a fixed amount whether or not anyone visits. Which is right depends on your traffic; we'll tell you after measuring it rather than guessing.