Replit apps moved from the workspace to a deployment you can rely on
Taking an app built in Replit or with Replit Agent to production: choosing the deployment, getting secrets and the database right, adding tests and rollback, and deciding whether to stay on Replit or move.
Replit is a browser-based development environment with an AI agent in it, and its pitch is that the same place where the app is written is where it runs. That is the difference from the other tools on this page. A Lovable or Base44 app is mostly about what the generated code leaves open; a Replit app is as much about where and how it is deployed.
The workspace and the deployment are not the same thing. Replit offers different deployment types, including an autoscaling one that can scale to zero when idle and a reserved one for apps that must be running continuously, and the filesystem of a deployed app is not a place to keep data. Third-party guides disagree on whether workspace secrets carry over to the deployment automatically, so check that in your own project rather than assuming either answer.
We have not published a client engagement on Replit and hold no partnership with it. The work here is the production checklist from our vibe coding service, with the deployment questions at the front.
What we build on Replit
The right deployment type for what the app does
An app that serves occasional requests and can start cold is not the same as one that holds a connection, runs a schedule or must answer instantly. We choose the type from the behaviour, and test a cold start and a restart rather than discovering them in front of a customer.
Secrets and configuration in the deployment, not the workspace
Every key the app needs is confirmed present in the deployed environment, none are in the code or the history, anything that was ever exposed is rotated, and the app fails loudly at start if one is missing instead of limping.
Data in a database, not on disk
A deployed app's local files should be treated as temporary. Anything that must survive goes to a managed database or object storage, with backups that have been restored at least once, because a backup nobody has tried to restore is a hope.
A route out of the workspace
The code in a repository, a way to build and run it that does not depend on the workspace, tests on the parts that matter, and a deployment that can be rolled back. That leaves the app movable, which is the real protection against being stuck.
What goes wrong on Replit
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
It works in the workspace and fails when published
The usual causes are a missing secret, a path or port that differs, a package that was present in the workspace and not declared, or data that was written to disk. We reproduce the deployment from clean, so the first failure is ours, in a test, and not a visitor's.
- 02
State kept in files or memory
Sessions, uploads and caches that live on one instance disappear on restart and are not shared when an autoscaling deployment runs more than one. We move that state to a store that outlives the process.
- 03
The agent changed something unrelated while fixing something else
An agent working through a request can edit files, schema and settings well beyond what was asked, and checkpoints are a safety net, not a review. We use the repository's history and a pull request so every change is a diff someone read, and keep production data and credentials out of the agent's reach.
- 04
Platform-specific services that fail anywhere else
Built-in database and authentication helpers work on the platform and, according to third-party hosting guides, can fail when the code is run elsewhere. Knowing which ones the app uses tells you what a move would cost, long before you need to make one.
Where Replit is the wrong answer
Staying on Replit is a reasonable answer for a lot of apps. If it runs a small internal tool or a prototype used by a few people, the deployment is set up properly and the data is in a managed database, hardening it where it is costs far less than moving it. We would move it when you need a specific region, compliance or network arrangement, when the cost of running it has overtaken the cost of owning the infrastructure, when the app depends on platform-specific services that would be awkward to keep, or when you want a team who have never heard of Replit to be able to work on it. And if the app handles money or personal data, it should have been through a security review whatever it runs on.
Projects that did not use Replit
Here for the argument rather than as evidence of Replit work. Each one bears on a decision above, and the note says which.
Related reading
Replit, specifically
Yes, if it is deployed properly: the right deployment type, secrets set in the deployment, data in a managed database rather than on disk, and a way to roll back. The question is not whether Replit can host it but whether the app has been prepared for it.
Most often a missing secret, a value that differs between the workspace and the deployment, a dependency that was not declared, or something written to the local filesystem. Check the deployment's logs and environment first. If it is still unclear, we can reproduce it from clean and find the cause.
Generally, yes. The code is yours to put in a repository and run elsewhere. The work is in anything tied to the platform, such as built-in database or authentication helpers, which would have to be replaced. A short review tells you which ones the app uses and what replacing them involves.
Not directly. Work on a branch or copy, review each change as a diff, keep production credentials out of reach, and run migrations against a copy first. Checkpoints help you undo something; they do not tell you it was right.
No. We hold no partnership, certification or endorsement from Replit, and nothing here should be read as one.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no