By default, Render services have an ephemeral filesystem. Without a persistent disk, any changes you make to a service’s local files are lost every time the service redeploys or restarts.
Persistent disks are useful for services such as:
- Infrastructure components (Elasticsearch, Kafka, RabbitMQ, etc.)
- Blogging platforms and CMSs (WordPress, Ghost, Strapi, etc.)
- Collaboration apps (Mattermost, GitLab, Discourse, etc.)
- Custom datastores (MySQL, MongoDB, etc.)
Before you attach a persistent disk, it’s helpful to understand important limitations and considerations.
You create persistent disks from the Render Dashboard. You can do so during service creation (click Advanced at the bottom of the creation form), or any time after creation from your service’s Disks page:
- Set your disks’s name.
- This value is for informational purposes only.
- Set your disk’s mount path (such as
- Only filesystem changes under this path are preserved across deploys and restarts! The rest of your service’s filesystem remains ephemeral.
- Choose a disk size.
- You can increase your disk’s size later, but you can’t decrease it. Pick the smallest value that currently works for your service.
- Save your changes.
After you save, Render triggers a new deploy for your service. The disk becomes available as soon as the deploy is live.
View your disk’s usage over time from your service’s Disks page in the Render Dashboard:
Render automatically creates a snapshot of your persistent disk once every 24 hours. If your disk experiences critical data loss or corruption, you can completely restore its state to any available snapshot. Snapshots are available for at least seven days after they’re created.
- If you restore a snapshot, all changes to your disk that occurred after the snapshot are lost.
- Render doesn’t support restoring only a portion of a disk snapshot.
- Do not restore a snapshot of a disk that’s used for a custom database instance. See details.
Restore a snapshot from your service’s Disks page in the Render Dashboard:
If you use a persistent disk specifically to back a custom database instance on Render (such as MySQL or MongoDB), do not perform a disk restore for database recovery purposes. If you do, your database might restore to a corrupted state.
For example, if your
ssh command looks like this:
scp commands look like this:
# Copying a file from your service to your local machine
scp -s YOUR_SERVICE@ssh.YOUR_REGION.render.com:/path/to/remote/file /destination/path/for/local/filefile 100% 5930KB 999.9KB/s 00:05
# Copying a file from your local machine to your service
scp -s /path/to/local/file YOUR_SERVICE@ssh.YOUR_REGION.render.com:/destination/path/for/remote/filefile 100% 5930KB 999.9KB/s 00:05
We recommend using SCP with the
-s flag to use the more modern SFTP protocol. Future releases of SCP will default to using SFTP, and this flag will no longer be needed.
The Magic-Wormhole library enables you to transfer files to and from your disk-backed service without using SSH and SCP.
In the Render Dashboard, go to your service’s Shell page.
If you have a Docker-image-backed service, use the shell to install
apt update && apt install magic-wormholeor the equivalent for your environment.
magic-wormholelibrary is pre-installed on all Render native runtimes.
Use the shell to transfer your file with the
wormhole send /path/to/filename.txtSending 10.5 MB file named 'filename.txt' Wormhole code is: 4-forever-regain
Note the code that appears in the output from
wormhole. Then, from any internet-connected machine, install magic-wormhole and run
wormhole receive, entering in the code when prompted.
When attaching a persistent disk to your service, note the following:
A persistent disk is accessible by only a single service instance, and only at runtime. This means:
You can’t access a service’s disk from any other service.
You can’t scale a service with a disk to multiple instances.
You can’t access a service’s disk from a one-off job you run for the service (one-off jobs run on separate compute).
Adding a disk to a service prevents zero-downtime deploys. This is because:
When you redeploy your service, Render stops the existing instance before bringing up the new instance.
This instance swap takes a few seconds, during which your service is unavailable.
This is a necessary safeguard to prevent data corruption that can occur when different versions of an app read and write to the same disk simultaneously.
You can’t add a disk to a cron job service.
- As an alternative, you can add a disk to a background worker, which is useful for processes that run continuously and don’t expose a port.
You can increase your disk’s size later, but you can’t decrease it. Pick the smallest value that currently works for your service.
- Increasing a disk’s size does not cause downtime. The additional storage becomes available to your service within a few seconds.