Render disks: no zero-downtime deploys, no scaling, no shrinking

Before attaching a Render persistent disk, know the tradeoffs. You lose zero-downtime deploys: the old instance stops first, so expect a few seconds of downtime per deploy. You can't scale past one instance. Only files under the mount path persist, so configure your app to write exactly there. The disk is invisible to build, pre-deploy, and one-off jobs, so seed data or migrate at runtime instead. And size it carefully: you can grow a disk later but never shrink it. For relational data, prefer Render Postgres over a DIY disk-backed database.

Context: Official docs (Persistent Disks): documents that only filesystem changes under the disk's mount path are preserved; everything else stays ephemeral. Gotchas: a disk is accessible by only one service instance at runtime, so you can't scale a disk-backed service past one instance and deploys are not zero-downtime (the old instance stops before the new one starts, a few seconds of unavailability). You can't access the disk from the build command, pre-deploy command, or one-off jobs. Disk size can only be increased, never decreased.