Replit Deployments: Pricing, Limits, and When to Move Your App to Your Own Cloud

You built the app in Replit, Agent got it working, and now someone other than you needs to use it. The question that follows is not "how do I click Publish" — Replit's own docs cover that in a page — but whether Replit Deployments are the right place to run it once it matters, what that costs as usage grows, and how hard it is to move the app into your own cloud account later. This guide answers those three questions with Replit's published prices, a plain list of what each deployment type can and cannot do, and the exact steps to get the app out when you outgrow it.

All prices and limits below were read from replit.com/pricing and docs.replit.com on 2026-09-24. Replit changes them often; check the linked pages before you decide anything on a number.

What Replit Deployments are, and what each type costs

"Deployments" (Replit now also calls this "Publishing") is Replit's built-in hosting. When you publish, Replit takes a snapshot of your Replit App and runs it on its own infrastructure, separate from the editor. There are four types, and Replit picks one for you by default based on the project:

Two more numbers matter for the bill. Replit's Core plan is $20/month ($18 on annual billing) and Pro is $100/month ($90 annual); both include monthly credits that deployment usage draws down before you are charged extra, and Core includes 100 GiB of outbound data transfer per month. The free Starter plan lets you publish one app, and that deployment expires after 30 days. Replit's own publishing costs page is the source for all of this.

What an Autoscale bill actually looks like

"Compute units" are the part people cannot picture. Replit counts 18 units per CPU-second and 2 units per RAM-second, billed at $0.60 per million. So an app configured with 1 vCPU and 2 GiB of RAM that is actively serving requests for 100 hours in a month (360,000 seconds) uses roughly 6.5 million CPU units and 1.4 million RAM units — about $4.75 of compute, plus the $2 base, plus $0.40 per million requests. Call it $7 for a month of moderate, bursty traffic. That is cheap, and it is the honest headline: for a prototype or a low-traffic internal tool, Replit Deployments are hard to beat on price.

The bill becomes a problem in two specific cases. An app that is busy most of the time (a popular API, anything polling, a websocket-heavy UI) stops being "bursty" and you are paying per second for what a fixed VM would give you flat. And an app whose traffic you do not control — a launch, a Reddit post, a bot scraping you — can turn a $7 month into a surprise, because scaling up is automatic and the cap is a "max machines" setting most people never open.

When Replit Deployments are the right answer

Stay on Replit if all of the following are true:

• The app is a prototype, a demo, or an internal tool used by a handful of people.
• Nobody has asked where the data lives or which account it runs in.
• Traffic is low or unpredictable enough that scale-to-zero is a feature, not a risk.
• You are still changing the app daily in the Replit editor and want publish to be one click.

There is no prize for leaving early. Moving hosting is work, and the point of a builder like Replit is to postpone that work until it pays for itself.

Five signs you have outgrown it

1. The bill stopped being predictable. Autoscale charges by the second of actual work. If you are checking the usage page every week, you are already paying a "not knowing" tax on top of the compute.
2. You need always-on, and the VM tiers do not fit. Reserved VM solves cold starts and long connections, but the shapes are fixed (0.5, 1, 2 or 4 vCPU). A modest Node or Python service on a $15 shared VM is fine; a memory-hungry app jumps straight to $50–$130/month for a single machine with no redundancy.
3. Private networking or a VPC came up. Replit Deployments run in Replit's infrastructure. If a customer, a security review, or a partner API needs your app inside a private network, on a static egress IP you own, or in a specific region in your own account, there is no setting for that — it is a different kind of hosting.
4. Someone asked for the data in their own cloud. The moment a buyer says "this has to run in our AWS account," you are in bring-your-own-cloud territory, and the builder's hosting was never designed for it.
5. The database and the background jobs are the product. Replit's managed PostgreSQL is convenient (20 GB of free storage per app for development, and a production database capped at 10 GiB per Replit's billing docs at the time of writing). If your data is going to outgrow that, or you need workers, queues, and file storage alongside the web process, you are assembling a real backend and want to do it somewhere built for that.

How to get your app out of Replit

The good news: a Replit App is a normal code project. Nothing is locked in. The export has four parts, and the order matters.

1. Push the code to a GitHub repository you own

In the Replit workspace, open Tools, click + and add the Git tool. The Git pane can initialise a repository and sync it to GitHub without the command line: connect your GitHub account, create or choose a repo, commit, push. From here on, GitHub is the source of truth and every host you might move to deploys from it.

Before you push, do the search every AI-built app needs, because Agent sometimes writes keys straight into the code:

git grep -nE "(sk-[a-zA-Z0-9]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN)"

Anything that turns up gets rotated at the provider and moved to step 2.

2. Export the secrets

Replit Secrets are exposed to your app as ordinary environment variables (process.env.MY_SECRET, os.getenv("MY_SECRET")). They are not part of the Git repository, so they will not travel with the code. In the Secrets tab, use Edit as .env to see the whole set in one place, copy it somewhere safe, and plan to enter each value into the new host's secret store. Do not commit that file.

Also list the variables Replit was setting for you without asking — the database connection string is the important one. Print them from a shell in the workspace:

env | grep -iE "(DATABASE|PG|REPL)" | cut -d= -f1

3. Move the database

Replit's SQL database is managed PostgreSQL, and the Settings tab of the Database tool shows the connection string and connection details for external tools. That means the standard Postgres move works: dump from Replit, restore into the managed Postgres you have created at the destination, and prove the restore before you switch traffic.

pg_dump "$REPLIT_DATABASE_URL" -Fc -f replit.dump
pg_restore --list replit.dump | head            # sanity-check what is in it
pg_restore -d "$NEW_DATABASE_URL" --no-owner replit.dump

If the app used Replit's key-value database instead of SQL, there is no equivalent elsewhere; that data has to be read out with the client and written into a real table. It is rarely large, but it is the step people forget until the new deployment comes up empty.

4. Redeploy from the repo and cut over the domain

Connect the GitHub repo to the new host, enter the secrets from step 2 with the new database URL, deploy, and test on the host's temporary URL. Only then move DNS. If you set up a custom domain on Replit, you already know the records; you are just changing their targets. The step-by-step for domains, TLS and migrations is the same as for any builder export and is written up in our Lovable/Bolt/Replit export guide.

Where to run it instead: three destinations compared

The middle column is where most Replit apps go next, and our Railway vs Render vs Vercel comparison covers how to choose between them. The right column is the one people avoid because of the setup effort, not because it is the wrong answer — and for the VPC, own-account and data residency cases in the list above, it is the only answer.

The shortcut for the third column

If your app has hit signs 3, 4 or 5 and you would rather not learn cloud infrastructure this quarter, this is exactly the hand-off we do. You send us the GitHub repository from step 1. We deploy it into your own AWS, GCP or Azure account — the database, secrets, domain, TLS and monitoring included — or run it as a managed API for you, and you never touch a Replit usage page again. It is priced per project, not as a retainer; the comparison with a conventional engagement is in DevOps as a service. Send us the repo and we will tell you what the move actually involves before you commit to anything.