Autoscale vs Reserved VM: Choosing the Right Deployment for Local File‑Based State

Short Answer

Neither deployment mode guarantees that local files survive a redeploy. Autoscale containers are fully ephemeral — the filesystem is rebuilt on every start, stop, or scale event. A Reserved VM keeps one always-on instance whose disk survives ordinary restarts (process crash, reboot), but the filesystem is reset whenever the deployment is redeployed or the VM is recreated. So a Reserved VM can keep your SQLite file alive between restarts, but it is not durable storage. If the data matters, move it to external storage regardless of which mode you pick.

Confirmed vs. Likely Behavior

Confirmed: Autoscale deployments recreate the container on each start or redeploy, so anything written to local disk is lost when the container stops or is replaced. This includes scale-to-zero idle periods — there is no disk to come back to.

Confirmed: Reserved VM deployments keep a single always-on instance, and the VM's filesystem persists across normal restarts but is cleared on redeploy or VM recreation.

Likely (verify before relying on it): a simple process restart on a Reserved VM — for example, your app crashing and being relaunched — does not wipe the disk, so an SQLite database or uploaded files survive as long as the VM itself is not replaced. Treat this as an operational convenience, not a persistence guarantee.

Cost and Scaling Trade-offs

• Autoscale bills per second of compute actually used and can scale to zero, making it cheap for sporadic traffic. In exchange, you get statelessness: no local disk, and concurrent instances cannot share a filesystem anyway.
• Reserved VM charges a fixed hourly/monthly fee for the always-on instance regardless of load. You pay more, but you get one machine with a disk that survives restarts.

The decision hinges on one question: can your app tolerate losing local state on every redeploy? If yes and redeploys are rare, a Reserved VM is workable. If no — or if you ever need more than one instance — Autoscale plus external storage is the correct architecture.

Recommended Path

1. For uploaded media, use object storage (Replit Object Storage or an external bucket) instead of the local disk.
2. For structured data, use an external database rather than a local SQLite file. If SQLite is non-negotiable, a Reserved VM is the only mode where it can function, and you should schedule regular backups off the VM.
3. Only then choose the deployment mode on cost: spiky or idle-heavy traffic favors Autoscale; a steady single-instance workload can justify the Reserved VM's fixed price.

Verify Before Committing

Pricing and persistence details change, so confirm both against current Replit documentation and your billing dashboard. A quick empirical check on a Reserved VM:

date > /tmp/persist-check.txt   # or your app's data directory
# kill the app process, let it restart, then:
cat /tmp/persist-check.txt     # should still exist
# now trigger a redeploy from the Replit UI and check again — expect it gone

For cost, run an Autoscale deployment under a typical load for an hour, record compute seconds used, and compare the extrapolated monthly figure against the quoted Reserved VM price for an equivalent size.