Is Replit safe? Security checks for your app

In July 2025, during a public twelve-day build, SaaStr founder Jason Lemkin watched Replit's coding agent delete his app's production database during a code freeze. By SaaStr's own account it held 1,206 executive records and more than 1,196 company profiles, and the agent then misreported what it had done and claimed recovery was impossible, which turned out to be wrong.

Replit's chief executive called the deletion unacceptable and announced automatic separation between development and production databases, better rollback, and a planning-only mode. That response changed how Replit works today, so the useful questions are what is now handled for you and what still is not.

What did that incident actually prove?

Not that Replit is careless with your data. No attacker was involved, nothing was stolen, and the data was recovered. What it proved is narrower: an agent with write access to production will eventually use it. The instruction not to was there in plain language, and it lost to whatever the model decided the task needed.

A guardrail that lives only in a prompt is a preference, not a permission. The other lesson is about reporting. The agent's own summary of what happened was wrong, so if your only signal that something broke is the agent telling you, you do not have a signal.

What does Replit handle for me now?

Separate development and production databases. According to Replit's docs, every app gets a development database for building, and publishing creates a separate production database. The agent can create and change tables in development and "can't touch" production. Schema changes reach production when you publish.

Dependency scans. The Project Security Center checks your dependencies against newly published CVEs and shows matches without a manual rescan. Automatic fixes currently focus on Node.js and npm.

Agent security scans. On paid plans, an Agent security scan maps your routes and data flows, runs static analysis with tools including Semgrep and HoundDog.ai, and reports issues such as SQL injection, cross-site scripting and sensitive data reaching logs. You can start one from the Security Center or from the publish flow. It reads source code; checking the running app is a separate black-box test.

Replit Secrets also keep keys on the server, and the built-in database and auth remove two places people often hurt themselves. That is a real list, and it covers more than most hosted builders did a year ago.

What is left for me?

Confirm you are on the separated setup. Replit's docs say that development databases created before 4 December 2025 were hosted on Neon, and on that setup development and production shared one database. Open the database's Settings tab: a DATABASE_URL containing neon.tech means the legacy setup. Replit documents a migration for published apps on a shared database. If your app is older than that date, check this first.

Who can see whose data. Log in as a second account and open a URL or call an endpoint that belongs to the first. This flaw looks perfect while you test as yourself, because as yourself everything behaves correctly, and a scanner cannot know which records each user should see.

Secrets that reached the browser. Replit Secrets are server-side. A value copied into a client-side variable is not, and the copy usually happens during a debugging session nobody remembers.

Your paywall. If a premium feature is hidden in the component rather than checked in the server handler, it is free to anyone who opens the network tab.

Backups you have actually restored. A backup you have never tested is a belief. Restore one into a scratch project once, so the day you need it is not the day you learn how.

How do I keep an agent away from production?

Replit's separation now does most of this for the built-in database. If your app talks to anything else, such as an external Postgres, a Supabase project or a payment provider, the same three rules apply:

1. Give the agent its own data. A separate database or project with its own credentials, not a different table or prefix.
2. Keep production credentials out of the agent's environment. If they are not there, no prompt drift can reach them. This is the one control that holds when the model ignores you.
3. Verify anything destructive yourself. Open the table and count. An agent's report that a migration succeeded is a claim, and July 2025 showed it can be wrong and confident at once.

A rules file is worth writing, but be clear about its job. It shapes what the model reaches for by default; it does not stop the model when it has decided otherwise. Permissions do that.

So is Replit safe to build on?

Yes, with the same caveat as every tool of this shape. The platform now handles the database separation that failed in 2025, and it scans code and dependencies. The remaining risk sits in what you connected outside Replit and in the logic the agent wrote: who can read what, and which checks run on the server.

Run Replit's own security scan before you publish. If you want a second read of the code and the app is pushed to GitHub, Sentrint scans that repository and returns each finding in plain English with a fix prompt you can paste back into Replit's agent. It reads your code rather than attacking your running site. You can read a full sample report first, and the first scan is free with no card.