Replit — and Replit Agent — is one of the fastest ways to go from idea to a running, deployed app. That speed comes with a few Replit-specific traps that are easy to miss until someone other than you is using it. Here’s what to lock down before you go live.
Secrets in the code — or in a public Repl
Replit has a Secrets manager for a reason, but the fast path is hardcoding an API key or dropping it in a file, and the agent may do the same. Worse: if your Repl is public, anyone can read your entire codebase — including any secret you committed and the git history.
Check: Are all keys in Replit Secrets, not in code? Is your Repl private? Grep the files for sk_, key, token, password.
The database’s access rules
Whether you’re on Replit’s built-in database, a Postgres add-on, or an external one, the same rule applies: the database must enforce who can see what — not just your app code. An agent-generated app often trusts the app layer entirely, so anyone who reaches the data directly is in.
Check: Can a logged-in user reach another user’s rows by changing an id in the request? Is access enforced at the data layer, not only in the UI?
Dev vs. Deployment
The Repl you build in and the Deployment real users hit aren’t the same environment — different config, sometimes different secrets. Things that “worked” in the workspace can behave differently, or expose more, once deployed.
Check: Have you tested the deployed URL — logged out, then as a real second user — not just the workspace preview?
Auth the agent stubbed
To get a flow working, generated code often stubs or simplifies auth: a hardcoded check, a client-side guard, or a literal // TODO: add real auth. It ships, and the TODO never gets done.
Check: Is every protected route and action verified on the server, with a real session — not a placeholder or a UI-only guard?
Cost and abuse on open endpoints
A Replit app with an AI call, an email, or a signup endpoint that’s open and un-rate-limited can be hammered — or run up a bill — overnight.
Check: Can a costly endpoint be called logged-out, in a loop, with nothing to stop it?
Before you go live
- Repl set to private; every secret in Secrets, none in code or history.
- The database enforces access — not just the app layer.
- Tested on the Deployment URL, as a second user.
- Real server-side auth on every protected route; rate limits on anything costly.