Does the Core plan include Deployments?

No. Core covers the workspace, Agent credits, private Repls, and higher resource limits inside the IDE. Deployments are billed separately on top, per deployment type. This surprises people who assume the monthly subscription covers everything — it does not, and the two line items appear separately on your Replit invoice each month. Budget for both if you are running production workloads.

Can I move from Autoscale to Reserved VM later without downtime?

Yes. In the Deployments tab you can promote a running deployment to a different type. There is a short cutover window during which requests may briefly route to both, but there is no need to redeploy from scratch, and your custom domain, environment variables, and secrets carry across automatically. Test the switch with a staging deployment before flipping production if you care about zero drops.

How is egress bandwidth calculated?

Egress is the outbound bytes your Deployment sends to clients — HTML, JSON, images, video, everything a browser or mobile app downloads from your app. Ingress (bytes coming in) is not billed. If you serve large media directly from your app you will pay egress on every download; if you serve them via signed URLs to object storage, the CDN handles the bytes and your Deployment egress line stays flat.

What is the smallest Reserved VM size and what fits in it?

The smallest Reserved VM is 1 vCPU with 1 GB of RAM. It fits a small websocket server, a lightweight Node or Python API with an ORM, or a Discord bot with dozens to low hundreds of concurrent users. It does not fit a Postgres database alongside your app process, a heavy ML inference workload, or anything that keeps large caches in memory. Upgrade if you see the OOM-killer in your logs.

Does Replit provide an SLA on Deployments?

Enterprise plans include a written SLA with credits for downtime beyond an agreed threshold. Core and Hacker plans do not — the service is best-effort, monitored publicly at status.replit.com, and status incidents get postmortems but no automatic credit. If an SLA is a compliance requirement, you either need the Enterprise plan or you need to host somewhere that contracts on paper for it.

Can I run a database inside a Deployment?

Technically yes, practically no. A Reserved VM can run Postgres, Redis, or SQLite in-process, but you lose the redundancy, backups, and managed upgrades of a real managed database. For anything with real data, use Replit's managed Postgres (Neon under the hood) or an external service and let the Deployment be stateless. Stateful deployments are a footgun that seems fine until the first restart deletes your customers' data.

How do custom domains work?

Every Deployment gets a *.replit.app URL for free. To attach a custom domain you add an A or CNAME record at your DNS provider pointing at Replit's edge, then confirm the domain in the Deployments settings. Certificates are issued automatically via ACME. The whole flow usually takes five to fifteen minutes end to end and works identically across all four deployment types.

What happens if I hit a compute or bandwidth limit?

By default the Deployment keeps serving and Replit bills the overage at the standard per-unit rate. You can set a spend cap in your account settings if you would rather have the Deployment throttle or fail closed than run up an unexpected bill. Which behaviour is right depends on the workload — customer-facing sites usually prefer to keep serving, background jobs usually prefer to fail loudly.

Replit Deployments pricing: Autoscale, Reserved VM, Static & Scheduled

The four deployment types at a glance

Replit Deployments ship in four flavours: Autoscale, Reserved VM, Static, and Scheduled. Each has a different pricing model, a different scaling behaviour, and a different set of workloads it is genuinely good for. Choosing the wrong one is the single most common mistake teams make when they graduate from a Repl running in a workspace tab to a public URL. The fix is not more optimisation — it is picking the right deployment type up front. This guide walks each one, with the compute + egress model, the workloads that suit it, and the workloads that punish it.

Autoscale

Autoscale runs your app on a serverless fleet that scales to zero when idle. You are billed by compute-seconds while requests are in flight, plus egress bandwidth. When traffic spikes, more instances spin up automatically; when nobody is using the app, you pay nothing for compute and only a token amount for the deployment slot itself. Autoscale is the default choice for low-to-moderate traffic apps that can tolerate a small cold start — internal tools, side projects, hobby APIs, marketing sites with a light backend, prototypes shown to a small group of beta users. The trade-off is that the first request after a period of idleness will pay a few hundred milliseconds to a second or two of cold-start latency.

Reserved VM

Reserved VM is an always-on virtual machine at a fixed monthly rate per size. No cold starts, no scale-to-zero, and pricing that is predictable to the cent. You pay whether traffic is zero or full, so the economics are the mirror image of Autoscale: cheap under heavy sustained load, expensive under light bursty load. Reserved VMs are the right pick for websocket servers, long-running background workers, apps with strict tail-latency SLAs, real-time collaboration back-ends, and anything that has to hold state in memory across requests. The sizes range from small (1 vCPU / 1 GB) up to multi-core machines with many gigabytes of RAM.

Static

Static deployments serve pre-built HTML, JavaScript, and CSS from Replit's CDN. Usually free within reasonable bandwidth caps. There is no compute charge because there is no compute — your build step produces a folder, and that folder is served from an edge cache. Best for landing pages, documentation sites, single-page-app frontends whose API lives on a separate deployment, and anything else that would otherwise be a Netlify or Vercel static hosting job. If your app has zero backend, Static is almost always the correct answer.

Scheduled

Scheduled deployments run your Repl on a cron schedule and bill by compute-seconds per run. No public URL, no request-response cycle — just a job that fires at, say, 03:00 every night and exits when it is done. Best for nightly ETL, weekly report generation, cache warming, database cleanup, invoice runs, and daily digest emails. Pricing is straightforward: how long the job took to execute multiplied by the compute rate for the machine class. A five-minute nightly job costs about as much as a small coffee per month.

How to choose between them

Traffic spiky and low-average, cold starts are tolerable → Autoscale.
Traffic sustained, or realtime, or memory-holding → Reserved VM.
No backend at all — just built assets → Static.
Runs on a timer, not on request → Scheduled.
Every one of those descriptions matches → split the app in two: static frontend + Reserved VM backend.

Worked examples

A hobby REST API serving 200 requests a day: Autoscale is the right answer. Even with generous request budgets, monthly compute is a few cents and cold starts are irrelevant because nobody notices. A collaborative document editor with 50 concurrent websockets: Reserved VM, small size, fixed monthly rate. Autoscale would either drop connections at scale-down or bill for the entire day since the connections never close. A marketing site with a contact form: Static for the frontend, and a Scheduled deployment or a tiny Autoscale endpoint for the form handler. A nightly database backup script: Scheduled, always.

Egress and the gotchas people trip on

Every deployment type bills egress bandwidth separately from compute. For most apps this is a rounding error, but two patterns push it higher than expected: serving large media files directly from your app instead of from object storage, and inefficient polling from mobile clients that pull the same JSON payload every few seconds. If your Deployment bill has a surprise line item, egress is the first place to check. Object storage plus a signed URL scheme cuts media egress almost to zero because the CDN, not your compute, serves the bytes.

Moving between deployment types

You can promote a deployment to a different type inside the Deployments tab without redeploying from scratch or losing your custom domain. The most common migration path is Autoscale to Reserved VM once traffic becomes sustained enough that cold starts hurt or the cumulative compute-seconds bill exceeds the flat Reserved rate. The opposite migration — Reserved VM to Autoscale — is rarer but useful when a product's usage collapses and you would rather pay per request than for an always-on box.

Reading a Deployments bill

The monthly Deployments line on your Replit invoice breaks down by deployment, then by cost type inside each deployment: compute, egress, and any add-ons (custom domain TLS is included; managed Postgres storage is separate). A common surprise is a small app that shows more egress than compute; that is almost always a media-serving pattern that should move to object storage. Another surprise is a Reserved VM sitting at low CPU with a full monthly charge; that is working as designed — you pay for reserved capacity, not for utilisation. Read the bill the day it arrives, tag any line item that looks off, and fix the underlying pattern before the next cycle. Deployment bills grow slowly and then suddenly; small monthly hygiene keeps them predictable.

Environment separation and staging

Running staging and production as separate Deployments off the same Repl is the cleanest pattern. Give each its own Deployment Secrets, its own database URL, and its own custom domain. When you want to promote a change, deploy to staging first, smoke-test, then deploy to production. Do not try to switch environments via runtime env-var flags in a single Deployment; you will eventually ship a config bug that takes down real traffic. The tiny extra cost of running a staging Autoscale deployment is a rounding error next to the cost of a bad prod deploy — and Autoscale scale-to-zero means staging costs almost nothing when nobody is testing.