The default filesystem for services running on Render is ephemeral. Application data isn’t persisted across deploys and restarts, and this works just fine for most apps because they use managed databases to persist data.
But many applications need persistent disk storage that isn’t ephemeral. These include:
- Infrastructure components like Elasticsearch, Kafka and RabbitMQ.
- Databases like MySQL and MongoDB.
- Blogging platforms and CMSs like WordPress, Ghost and Strapi.
- Collaboration apps like Mattermost, GitLab and Discourse.
This is where Render Disks come in. Render services can use disks to store data that persists across deploys and restarts, making it easy to deploy stateful applications while benefiting from Render features like instant setup, fully-managed TLS certificates, private networking and auto deploys from Git.
Render Disks are backed by high performance SSDs with automatic daily snapshots.
Using disks is quick and easy. You can add a disk to a new service by clicking on Advanced during service creation and adding a name, absolute mount path, and the desired size for your disk.
You can also add a disk to an existing app by going to the Disks tab for your service, and picking a name, mount path and size.
A new deploy will be triggered once you click Save, and your disk will be available as soon as the deploy is live.
You can view disk usage over time and increase disk size on the Disks tab for your service.
To securely transfer files between your Render service and your local machine, you have a couple of options.
scp command can 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/file file 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/file file 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.
If you’d prefer not to use SSH and
scp, or need to transfer files from a service that does not support SSH, you can also use magic-wormhole:
- Navigate to the Shell tab on your Render Dashboard
- Install magic-wormhole
- Native runtimes: magic-wormhole is pre-installed on all of our native runtimes
- Docker services:
apt update && apt install magic-wormholeor the equivalent for your environment
- Send the file via
wormhole send /path/to/file
- Make note of 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.
No system is completely safe from data loss or corruption, which is why Render automatically creates snapshots for your disks once every 24 hours, and retains each snapshot for at least 7 days. You can use the Render Dashboard to restore a snapshot.
Restoring a snapshot will “rollback” to the state that the disk was in when a snapshot was taken. However, any data that changed on the disk between the time of the snapshot and the present time will be lost. Render doesn’t currently support restoring a portion of a disk snapshot.
Relying on a disk snapshot to restore a database is not recommended. Restoring a disk snapshot will likely result in corrupted or lost database data.
A disk is only accessible by a single runtime instance. This means:
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.
You can’t access a service’s disk from any other service.
Adding a disk to a service prevents zero downtime deploys. A new deploy first stops your app to prevent it from writing to disk, and only then brings up the new version so the app can start writing to the disk again. This typically only takes a few seconds, but your application will be unavailable during this time. This is a necessary safeguard to prevent data corruption that can occur when different versions of an app read and write to the disk simultaneously.
You can increase the allocated size for your disk at any time, but you can’t decrease it after creation. Increasing a disk’s size does not cause downtime, and the additional storage becomes available to your service within a few seconds.