Disks

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.

Get Started

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.

Transferring Files

To securely transfer files between your Render service and your local machine, you have a couple of options.

SCP

Once you have set up SSH, you can use SCP. If your ssh command looks like this:

ssh YOUR_SERVICE@ssh.YOUR_REGION.render.com

your 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

Magic Wormhole

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:

1. Navigate to the Shell tab on your Render Dashboard
2. Install magic-wormhole
   • Native runtimes: magic-wormhole is pre-installed on all of our native runtimes
   • Docker services: apt update && apt install magic-wormhole or the equivalent for your environment
3. Send the file via wormhole

   wormhole send /path/to/file

4. 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.

Disk Snapshots

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.

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.

Application Considerations

• 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 during its build command or pre-deploy command (these commands run on separate compute).

  • 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’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 need to run continuously and that don’t expose a port.

• 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.