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.
Monitoring Disk Usage
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.
Once you have set up SSH, you can use SCP. If your
ssh command looks like this:
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 environments: magic-wormhole is pre-installed on all of our native environments
- 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.
Using a database’s recommended backup tool (for example: mysqldump or mongodump) is the recommended way to backup and restore a database without corrupted or lost data.
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. However, this is needed to prevent data corruption that can happen when different versions of an app read and write to the disk at the same time.
Disks are not available to the build container.
You can increase the allocated size for your disk at any time, but you can’t decrease it after creation. Increasing the size will not cause downtime and your service will see the new disk size in seconds.
Services with disks can only run as a single instance for now. We plan to remove this limitation in the future to enable multiple service instances each with its own disk. Combined with Render’s built-in private networking, this will let you deploy clusters for stateful applications like MongoDB and Elasticsearch.
A disk cannot be shared between multiple services and can only be accessed by the single service that has been added to.
A disk cannot be attached to Cron jobs. As an alternative, Background workers are useful for processes that need to run continuously and that don’t expose a port.