We are going to start charging for volume snapshots from January 2026

Fresh Produce
1

Starting January 1st, 2026, we’ll begin charging for volume snapshots usage. You’ll see the first charges on your invoice issued at the start of February 2026.

The price will be $0.08/GB per month, with the first 10GB free each month.

Usage is calculated based on total stored size of the snapshots, not provisioned volume size. If you’ve written 1GB to a 10GB volume, the stored snapshot size will be 1GB (approximately - ignoring filesystem overheads).

98% of customers won’t see any additional charges for snapshots. Out of the remaining 2%, 83% will see less than a 10% increase in their monthly bill.

Check your usage

To help you prepare for this change, you can preview your volume snapshot costs in the Billing section of the dashboard - check your Upcoming Invoice and the new Cost Explorer.

We started collecting volume snapshot usage data on October 7th, so the preview will be incomplete for October.

How snapshot storage works

Snapshots are incremental, meaning only changes since the previous snapshot consume additional storage. When the oldest snapshot expires, some of its stored data may move to the next incremental snapshot.

You can use flyctl volumes snapshots list <volume id> to see the snapshots for a volume and their current sizes. For example:

$ fly volume snapshot ls vol_vwj27nn8g2m8nn9r
Snapshots
ID                          STATUS   STORED SIZE  VOL SIZE  CREATED AT  RETENTION DAYS
vs_No7qonjDql7GS0x88qy9oJPJ created      2.0 GiB   5.0 GiB  4 days ago               5
vs_ggV3gzBQ3oVYHowGAGQ2Z7mx created       10 MiB   5.0 GiB  3 days ago               5
vs_ggV3gzBQ3oVYH2nOpJ2KNk1  created       11 MiB   5.0 GiB  2 days ago               5
vs_90Ao0PzMoNAgt0Y5zDp6qnMO created      900 MiB   5.0 GiB  1 day ago                5
vs_mJmQJ2VyQAm5SNyMDl08YyJ  created      101 MiB   5.0 GiB  3 hours ago              5

Total stored size: 3.22 GiB

Reducing your usage

We take automatic daily snapshots of all volumes by default.

If you want minimize costs, you can reduce the retention period of future snapshots. We store snapshots for 5 days by default, but you can set volume snapshot retention from 1 to 60 days. Since snapshots are incremental, reducing retention will have the most impact on frequently updated volumes.

If you’re certain that you won’t need to recover a volume (maybe it’s used as a cache, or you have another backup strategy), we’ve added a new volume option to disable automatic snapshots entirely. Remember volumes only exist on one server, so data can be lost if the server fails.

Snapshots cannot be manually deleted, but existing snapshots have time to expire naturally before billing begins.

Why?

Volume snapshots cost us money to store, so we need to charge to make them sustainable.

4 Likes
2

Thanks for the advance warning! Just to clarify, this is being assessed at the block-device level—as opposed to df /data or similar?

(Aside: there’s a little-known raw-volume option, which would gum up the latter rather badly.)

What I’m thinking is that if you filled an entire 1G volume with a file but then deleted that file the next day, you’d unexpectedly be charged for the entire 1G in perpetuity. (Since the blocks are now “dirty” from the perspective of someone who doesn’t have the filesystem metadata.)

Also, there’s no longer a zstd/gzip-style compression stage?

3

Yes, snapshots operate at the block-device level, and we’re assessing the total size of all the block device snapshots for a volume, after they’ve been stored with deduplication.

This is what discard/fstrim solves. In theory, running fstrim in the machine would mark the blocks as unused again, and this would be propagated out to the LVM device on the host without us having to understand the filesystem metadata.

The bad news is Firecracker doesn’t expose discard to guests right now, so you’re correct about what happens if you remove files from a volume and the space isn’t reused.

As a workaround, you could consider forking the volume. We e2fsck -E discard as part of the clone process, so snapshots of a forked volume won’t include unused blocks. We can only do this on ext4 volumes, of course.

We snapshot and back up encrypted volume block devices without decrypting them, so compression isn’t effective on these. Unencrypted volumes do get compressed, but we’d generally recommend encryption.

2 Likes