The question arrives in almost the same words every time: “should we move off Replit, and what will it cost us?” It is a good question and it is usually asked six months later than it should be, because the trigger is normally an invoice rather than an architecture review. This is our honest answer, including the part where the answer is no.
The running-cost comparison
Take a typical product: a web app, a background worker, a Postgres database, some user uploads, and a domain. Here is what that costs in each place. These are vendor list prices at the time of writing for a small production workload, not numbers from a specific engagement - the point is the shape of the curve, not the decimal places.
| Stage | Builder hosting | Your own cloud | Difference |
|---|---|---|---|
| One app, a few hundred users | $20 – $40 / mo | $25 – $45 / mo | A wash. Migrating now buys control and durability, not savings. |
| Three services, steady traffic | $75 – $150 / mo | $40 – $90 / mo | You stop paying per app. One database and one load balancer serve all three. |
| Real product, autoscaling | $300 – $900+ / mo | $120 – $350 / mo | Compute priced against use, with reserved capacity for the steady baseline. |
| Enterprise customer, compliance in scope | Not available at any price | $200 – $600 / mo | Some answers cannot be bought from a builder. A signed BAA is one of them. |
Notice where the crossover is. It is not at the top of the table. Most founders assume the case for migrating is financial and that it kicks in at scale; in practice the financial case appears around the second or third service, well before the traffic is impressive, because builder pricing is per app and cloud pricing is per resource.
The migration itself
A typical Replit-to-cloud migration for an app of this size is two to four weeks of engineering. Broken down by where the time actually goes, across the projects we have run:
| Phase | Share of the work | What eats the time |
|---|---|---|
| Inventory and target design | 15% | Finding every service the app touches, including the two nobody remembers adding. |
| Containerising and infrastructure as code | 30% | Usually straightforward. Occasionally a dependency that assumed a writable filesystem. |
| Separating state from code | 25% | Tracing every write path to work out which files are user data. This is the real work. |
| Dry run and reconciliation | 20% | Row counts, checksums, webhooks. Boring, and the reason nothing goes wrong on the day. |
| Cutover and handover | 10% | DNS, monitoring, and making you execute a rollback yourself before we leave. |
The line that surprises people is the third one. Separating state from code is not a deployment problem, it is an archaeology problem: somewhere in the codebase, generated eight months ago, something writes a file to disk, and the question of whether that file is a cache or a customer's invoice can only be answered by reading the code that produces it.
Three cases where you should not migrate
You are still looking for the product
If the app might be substantially different in three months, infrastructure work is the wrong place to spend the next three weeks. Builder hosting is genuinely excellent at the stage where the thing you are optimising for is how fast you can change your mind. Stay, and spend the week on the two things that are cheap and permanent instead: separate your environments and turn on point-in-time recovery.
The bill is not actually the problem
Sometimes the trigger is a $200 invoice that felt like a lot at the time. Two hundred dollars a month is four hours of engineering. If nothing else is wrong - the data is safe, the access rules hold, the app is fast enough - migrating to save $80 a month is a bad trade against three weeks of your attention.
Nobody will operate it
Owning infrastructure means somebody watches it. If that person does not exist and you are not going to hire or retain one, a managed platform is a legitimate architectural choice rather than a compromise. The failure mode we see is a migration completed and then abandoned: no one applying patches, no one reading the alerts, backups quietly failing for four months. That is worse than the builder you left.
The three things worth doing regardless
Whether you migrate this quarter, next year, or never, these three make the eventual move cheaper and the current situation safer. They are worth doing this month.
- Move user data off the container filesystem. Uploads to S3-compatible object storage, application data to a managed Postgres. Ephemeral disk quietly eating data is the most expensive Replit failure we get called in to fix, because it is discovered long after the deploy that caused it.
- Split development and production. Two databases, two credentials, a seed script. This is a day of work and it removes an entire category of catastrophe.
- Get the code into git with a pipeline. Even if deployment stays manual, having a history, a diff, and a review step changes what is possible later - including handing the codebase to someone else.
Do those three and the eventual migration is a deployment project rather than an archaeology project, which is roughly the difference between two weeks and five.
AWS or DigitalOcean
The answer depends on who operates it, not on the workload. DigitalOcean when you want a small number of moving parts, published flat pricing, and no dedicated ops person. AWS when you need managed services beyond compute and Postgres, a specific region, or a compliance posture you can hand to an enterprise buyer. The difference between them is much smaller than the difference between either of them and staying somewhere your data lives on an ephemeral disk.
We have written both routes up in detail, phase by phase: the Replit to AWS migration and its DigitalOcean counterpart each carry the risk register we work from and what we hand over at the end. If you want the version with your own numbers in it, the scoping call is free and frequently ends with us telling someone not to migrate yet.
Written by Kato Chojiro
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Connect on LinkedIn