Volume Expansion and Snapshot Restores

A night landscape with tall, thin evergreen trees on the horizon and hot-air balloons floating among oversized stars, planets, and galaxies.
Image by Annie Ruygt

Fly.io operates hardware around the world to run your apps close to your users. This post is about our storage volumes, which are handy for running full stack apps. Deploy, say, a Laravel app now—it takes mere minutes.

Fly Volumes are the persistent storage that makes it possible to run full stack apps entirely on the Fly.io platform, keeping your configuration, session or user data in place across deployments. Looking at them from another angle, volumes are space on NVMe drives on our servers that you can rent for your apps to use.

We’ve recently made two major improvements to volumes: extending volume size, and self-service snapshot restores.

Extending a volume

Until recently, if you needed your volume to be bigger, you’d have to provision a new empty one and copy your data to it. This is not ideal, to put it mildly.

But you can now extend a volume on the CLI with fly volume extend <volume-id>.

The app instance attached to the volume does have to restart to allow the file system to be resized. This will happen automatically for “regular” apps, but Machines VMs will have to be restarted manually.

More details in the announcement on the Fly.io community forum and in the volumes docs.

Ideally, we’d be able to alert you when you hit a usage threshold on a storage volume, or even better, give you the option to increase your volume size automatically when you hit a threshold. We’re not there yet!

Restoring data from a volume snapshot

It’s been possible for some time to restore a Fly.io HA Postgres database from a snapshot, but if you were using another database, you had to ask us to dig up and restore a snapshot for you.

But now you can restore regular volumes: as of flyctl v0.0.363, individual volume restores can now be performed by specifying --snapshot-id at creation time.

Which means you can get back sandwiches.db by yourself (is there something other than sandwiches that you might store in an app’s database?), at your own convenience.

Volume snapshots are taken daily (but not at the same time every day), and shunted off to object storage where they live for five days before they expire.

If you need to restore from a snapshot, you identify the volume you want, list its snapshots, get the ID of the one you want from the list, and create a new volume by pointing fly volume create at that ID.

You can restore to a bigger volume, if you like, but not a smaller one than the snapshot came from.

Forum announcement. Docs.

Start simple

It’s just a couple commands to get an app deployed on Fly.io.

Try Fly for free