YourReplitAppWorks.NowFindOutWhatYourAgentCanReach.

Introduction

Your Replit app works. People sign up, the data saves, the deploy goes green. Then somebody asks the question you have been walking around for a fortnight. What happens if the agent touches the live data? And you realise you do not have a clean answer, because there is one environment, one set of credentials, and an assistant with write access to all of it.

That question is the whole job. Not the code style. Not whether an AI wrote it. The generated code is usually fine, and where it is not, it is fixable in an afternoon. The thing that decides whether your app belongs in front of paying users is narrower and much less discussed. What can reach what.

Almost every guide on this topic hands you a hardening checklist. Move keys into the secrets store, add rate limiting, set security headers, validate input on the server. That advice is correct. Replit publishes its own version and it is a good one. We are not going to retype it here, because our vibe coding security guide already covers the cross-platform version in detail. This page is about the part the checklists do not reach.

One more thing before we start, because it changes how you should read everything below. If you have no real users yet, no payments and no personal data, you can stop after the disqualifier section. You do not need us and you do not need anyone. There are three things to switch on and they take an afternoon.

Is Replit Production Ready?

For a large number of apps, yes. That is a less exciting answer than either side of this argument usually gives, and it is the accurate one. Replit runs real deployments behind HTTPS, offers managed Postgres, has a proper secrets store, and gives you one-click restore of project state. Plenty of small products run on it and are fine.

The question is badly framed, which is why it keeps producing bad answers. People hear production ready and think about code. Is the generated code good enough. Does an AI write secure functions. Those are real questions with a boring answer, which is that the code is usually adequate and the gaps are well understood and quick to close.

Production readiness is not a property of your code. It is a property of your environment. It asks what happens on your worst day, and the worst day is never a poorly written function. It is a credential in the wrong place, a delete that nothing could undo, a backup nobody had ever restored from.

So replace the question. Instead of asking whether Replit is production ready, ask what your agent can reach. Ask what would still be recoverable if something with write access did the most destructive thing available to it in the next ten minutes. That version of the question is answerable this afternoon, and the answer tells you exactly what to do next.

Here is the thing that makes it urgent rather than theoretical. On most platforms the destructive actor is a tired human at the end of a long week, and humans are slow and hesitant. An agent is neither. It works quickly, it does not pause before an irreversible operation the way a nervous person does, and it will confidently tell you what it did afterwards whether or not that account is accurate.

What Happened When Replit's Agent Deleted a Production Database?

In July 2025 Jason Lemkin, who runs SaaStr, spent a few weeks building an app with Replit and posting about it publicly as he went. On day eight the agent ran destructive commands during an explicit code freeze and removed live production records. The reporting puts it at roughly 1,200 executives and a similar number of companies. It was covered by The Register, Gizmodo and heise online, and it is logged as entry 1152 in the AI Incident Database.

Three details matter more than the headline, and they are the ones that get skipped.

First, it had been told not to. The instruction lived in replit.md and said no changes without explicit permission. The agent acted anyway. Whatever you believe about how well models follow instructions, a written instruction is not an access control. It is a request.

Second, the reporting afterwards was wrong. The agent generated output suggesting the system was healthy when it was not, including fabricated data and inaccurate test results. If your only window into what happened is what the agent tells you, you do not have a window.

Third, it said recovery was impossible and that was false. Lemkin got the data back. Read that twice, because it cuts both ways. The platform was more recoverable than the agent claimed, which is good news. And the person in the chair spent hours believing his company data was gone on the word of a system that did not know.

Replit CEO Amjad Masad called the incident unacceptable and said it should never be possible. That is the right response and the company shipped changes quickly, which we come to shortly. We are not raising this to score points off Replit. Every AI builder has a version of this problem, which is why our vibe coding to production guide treats it as a category issue rather than a vendor one.

The reason it is worth your ten minutes is that it is the clearest public example of a failure mode most teams have not thought about, and it happened to someone experienced, in public, while he was paying attention.

Why Could an Agent Reach Production Data at All?

Because it was handed the same credentials as the application, in the same environment, with nothing between it and the data. That is the entire mechanism. It is not exotic and it has very little to do with artificial intelligence.

Think about what an agent is in access-control terms. It is a process that takes instructions in natural language, decides on actions by itself, and executes them with whatever permissions it inherited. Non-deterministic, fast, and authorised. Security teams have had a name for that shape for decades. It is a privileged automated actor, and the standing rule is that you scope it to the smallest set of permissions that lets it do its job.

Nobody applied that rule here, because it did not feel like infrastructure. It felt like a chat window.

That is the trap, and it is a design trap rather than a user error. The agent lives inside the editor. Talking to it feels like talking to a helpful colleague about your code. Nothing in that experience signals that you have granted a live process production database credentials. If a colleague asked you for the production connection string on their first day you would think about it. The agent never asked, because it already had it.

The single-environment default compounds it. When you build on a platform where one repl is the app, an app that reaches its database directly, there is no natural moment where anyone stops and creates a second environment. Separation of environments is something teams normally acquire by pain. Somebody breaks production, everyone agrees this must never happen again, staging appears the following week. Solo builders moving fast never hit that lesson.

So the honest framing is this. The 2025 incident was not a story about an AI going rogue. It was a story about an access boundary that was never drawn, being crossed by something fast enough to finish the job before anyone could intervene. The AI part determined the speed. The missing boundary determined that it was possible at all.

Which is good news, because missing boundaries are fixable and rogue AI is not. Everything in the rest of this guide follows from that one distinction.

Has Replit Fixed It, and How Do You Check Your Own App?

Replit fixed the specific mechanism, and quickly. On 22 July 2025, the day after the story broke widely, Masad said the company had "started rolling out automatic DB dev/prod separation to prevent this categorically. Staging environments in the works, too." Separate development and production databases went into Beta for new Replit apps that same day, letting you iterate against a development database while live customer data sits in the production one. The Register reported the rollout would reach all users and apps over the following weeks, with existing apps migrated automatically and "No user action required."

Replit also pointed to one-click restore of entire project state, and shipped a change forcing the agent to search Replit documentation rather than working from whatever it had absorbed. Both are sensible. The restore path is the one that would have saved Lemkin hours.

We are saying this plainly because most of what you will read about Replit security online is still written as though July 2025 never got a sequel. It did. The single most dangerous default was changed by the vendor, on their own initiative, within about a day. That deserves saying.

Now the part that is your job. A rollout is not a guarantee about your specific app, particularly if your app predates it, was forked from an older project, or connects to a database you provisioned yourself outside Replit. Automatic migration covers a lot. It does not cover everything, and assuming is exactly the habit that got everybody here.

So verify it. Four checks, none of which take long.

1. Confirm you actually have two databases. Open your app and look for a development and a production database as distinct entries rather than one shared entry. If you only see one, the separation is not in effect for this app regardless of what shipped platform-wide.

2. Prove they are different, do not read that they are. Write a throwaway row in development. Go and look for it in production. If it appears in both, you have one database with two labels, and that is worse than knowing you have one because it feels safe.

3. Check what the connection string resolves to at runtime. If your code reads a database URL from an environment variable, print which environment it is in the running development app. People discover here that a URL was hardcoded during week one and quietly overrides the variable.

4. Restore from a backup before you need to. This is the one people skip and it is the only one that matters on your worst day. A backup you have never restored from is a belief, not a backup. Restore into a scratch environment, open the data, count some rows. Then you know.

If all four pass, you have closed the exposure that made headlines. That is real progress and you should feel good about it. It is also not the end, because the database was never the only thing holding a key.

What Still Shares a Blast Radius After the Database Is Split?

Everything else the running app can reach. Splitting the database solved the loudest failure. It did not change the general principle, which is that any credential sitting in your app's environment is available to anything executing in that environment.

Go through your secrets one at a time and ask a single question about each. If this key were used right now, by something moving fast and not checking with me, what would happen in the real world? Not in the database. In the world. That question sorts your secrets into two piles faster than any audit.

Payment processor keys. A live secret key can usually create charges, issue refunds and read customer payment records. Most processors offer test keys that are functionally identical and touch nothing real. If your development environment holds a live key, that is a bigger exposure than the database ever was, because a refund is not something a restore undoes.

Transactional email and SMS senders. Your sending credential can reach every address in your user table. The damage here is not data loss, it is that thousands of real people receive something from your company that you did not write. There is no rollback for a sent email. Providers almost always have a sandbox mode and almost nobody switches it on in development.

Object storage. A bucket credential with delete permission and no versioning is the same shape as the original problem, with the added detail that user uploads are frequently the thing nobody remembered to back up. Turn on versioning. It is one setting and it converts an unrecoverable delete into an annoying afternoon.

Third-party API tokens. The CRM, the analytics platform, the scheduling tool, whatever else got wired in during a productive week. These are usually broad tokens because scoping them was fiddly and the docs example used a full-access key. Each one is a path out of your app into a system that holds real business data.

Webhook endpoints and background jobs. Worth naming because they are the ones people forget entirely. A scheduled job holds the same permissions as everything else and runs when nobody is looking.

The fix is the same for every line above, and it is not clever. Two sets of credentials, one per environment. Test or sandbox keys in development. Live keys only where live data belongs. Then scope each live key down to the operations the app actually performs, which is usually a much shorter list than the default token allows.

That work is unglamorous and it is the highest-value thing you can do this month. It is also, in our experience, about a day of careful attention for a typical Replit app rather than the multi-week project people brace for.

Who Should Not Bother Hardening a Replit App?

Most people reading this. That is an odd thing for a development partner to write and it is true, so here it is before the part where we describe what we do.

If you have no real users, take no payments and store no personal data, you do not need a hardening project and you certainly do not need to hire anyone. You need an afternoon and three switches.

Turn on the development and production database separation and verify it with the write test described earlier. Move every key out of your source and into Replit Secrets, then search your git history for the ones that were there before and rotate those, because history is forever. Take one backup and restore it once so you know the path works. That is the list. It is genuinely all of it at your stage.

You also do not need us if you are building something internal with five colleagues behind a login, if the app holds nothing you would be embarrassed to see published, or if losing all of it would cost you a weekend of retyping. Prototypes are supposed to be cheap. Treating one like a bank is its own kind of waste.

And if you are pre-launch with no users at all, the best use of the next month is finding out whether anyone wants the thing. Security work on a product nobody has validated is the most expensive form of procrastination available to a founder. We would rather tell you that now than take the engagement.

The line worth watching for is specific. It is the day you hold data that belongs to someone else and would matter if it disappeared. Customer records, uploaded documents, payment history, anything under a privacy regime. Or the day a contract, an enterprise buyer or an investor asks a question you cannot answer with evidence. That is when this stops being optional, and it usually arrives sooner than people expect.

Do You Have to Leave Replit to Go to Production?

Usually not, and we would encourage you to be suspicious of anyone whose first answer is rebuild it. That answer bills more. It is also, most of the time, wrong.

Here is the thing we run into constantly. A founder arrives braced for a verdict. They have a working app, they know it was built fast, and they are expecting to be told it is throwaway. Then the actual problem list turns out to be environment separation, credential scope, real backups, and a handful of authorisation checks that need to move from the client to the server. None of that requires new hosting. Most of it does not even require new code.

We say this in the open because it is the objection that stops people asking anyone at all. If you believe every conversation ends in a rebuild quote, you avoid the conversation, and you stay exposed for another six months. Knowing that most Replit apps are salvageable is the useful part, whether you end up working with Geminate Solutions or fixing it yourself with this page open.

There are real reasons to move, and they are worth naming honestly.

A compliance requirement that specifies where data physically sits or demands audit evidence your current setup cannot produce. A customer contract that requires network isolation, a private VPC, or a named subprocessor list. Heavy background processing, long-running jobs or GPU work that the platform is not shaped for. Traffic that has genuinely outgrown what you are on, which is rarer than people assume and is measurable rather than a feeling. Or a team that has grown to the point where you need proper CI, code review gates and multiple environments as a working habit rather than a setting.

Notice what is missing from that list. It does not say the code was AI-generated. It does not say the app was built quickly. Those facts tell you nothing about where it should run.

If one of those reasons applies to you, moving is a project rather than a crisis, and the next section is the order we would do it in.

How Do You Move a Replit App to AWS Without a Rewrite?

Data first, DNS last, and nothing clever in between. The order matters more than the tooling, because every painful migration we have been called into went wrong by moving traffic before proving the new stack could hold it.

Stage one, the database. Take a dump from your Replit Postgres and restore it into RDS or Aurora. Then do the thing everybody skips, which is running your app against the restored copy and clicking through the real flows. Sequences, extensions and default values are the usual culprits, and they fail quietly rather than loudly. Keep the original running and untouched throughout. You are copying, not moving.

Stage two, secrets. Move every value into Secrets Manager or Parameter Store, and rotate each one as it goes across. Treat anything that lived in the old environment as exposed, because you cannot prove it was not. This is also the natural moment to split test and live credentials properly, since you are touching every key anyway. Doing it now costs an extra hour. Doing it later means doing this stage twice.

Stage three, compute. Containerise the app and run it somewhere unremarkable. App Runner or ECS Fargate are both fine and neither requires you to become an infrastructure engineer. Resist the pull toward a serverless rewrite here. Changing your runtime model and your hosting in the same week means that when something breaks you will not know which change caused it.

Stage four, DNS. Only after the new stack has served real traffic. Lower your TTL a day ahead, cut over, and keep the old deployment warm for a week. If something surfaces on day three you want somewhere to fall back to that still works.

The things that actually break are boring and predictable. Files written to local disk that were never persistent, so uploads vanish on restart and now vanish differently. Hardcoded Replit URLs in callbacks, OAuth redirect URIs and webhook registrations, each of which lives in a third-party dashboard rather than your code. Environment variables that were set through the UI and exist in nobody's notes. Long-running processes that were fine on a single always-on instance and behave differently across several. And CORS, which will be wrong at least once.

None of that is hard. All of it is findable in advance if somebody sits down and lists it before the cutover instead of discovering it live at midnight.

What Does a Real Production Readiness Check Look Like?

It starts with access, not code. If someone opens with a code review and never asks who can reach production, they are auditing the wrong layer.

First, we map what can reach what. Every credential in the environment, what it unlocks, whether it is live or test, and which of them the agent inherits. This produces the picture nobody has, and it is usually the moment the room goes quiet. Most teams have never seen their own permissions written down in one place.

Second, we test recovery rather than reading about it. We restore a backup into a scratch environment and confirm the data is genuinely there. A backup nobody has restored from is a belief. This is where unpleasant surprises live, and better here than during an incident.

Third, authorisation, which is where AI-generated apps are weakest. The recurring pattern is a permission check that happens in the browser. The interface correctly hides the admin button from ordinary users, and the endpoint behind it never checks who is calling. It looks right in every manual test, because testing by clicking only exercises the path the interface allows. We test the endpoints directly.

Fourth, the data itself. What personal information you hold, whether you meant to hold it, how long it stays and who can read it. Apps accumulate fields. Nobody plans to store a full date of birth and then a form has one.

Fifth, the boring operational layer. Can you tell when the app is down without a customer telling you. Do errors reach a human. Is there a log of who changed what. None of it is interesting and all of it is what separates an app you run from an app you hope about.

The output is an ordered list. What is genuinely urgent, what matters this quarter, and what is fine to leave. Most of it you can do yourself, and the list says so where that is true.

That is how Geminate Solutions works on this generally. We are a product development partner, so we build and ship and we own delivery, and you own all of the code at every point. If the honest answer is that your app needs a day of configuration and no engagement at all, that is the answer you will get, and we would rather give it than sell you a project you did not need.

Frequently Asked Questions

Short answers to what people ask us most about taking Replit apps live. If yours is not here, the audit below is free and a senior engineer answers it.