# Tigris-backed volumes

**URL:** <https://community.fly.io/t/tigris-backed-volumes/20792>\
**Category:** Fresh Produce\
**Tags:** storage, volumes, tigris\
**Created:** [July 11, 2024, 9:38pm UTC](https://community.fly.io/t/tigris-backed-volumes/20792 "2024-07-11T21:38:46Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![wjordan](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/wjordan/32/1280_2.png) [@wjordan](https://community.fly.io/u/wjordan)\
**Post date:** [July 11, 2024, 9:38pm UTC](https://community.fly.io/t/tigris-backed-volumes/20792/1 "2024-07-11T21:38:46Z")

</div>

Hi all! We have a few small updates to our work on [Bottomless S3-backed volumes](https://community.fly.io/t/bottomless-s3-backed-volumes/15648), which should make it a bit easier for folks to get started using this feature.

> ⚠ Note— **this is still an experimental feature**. It’s not officially supported or ready for production use, and backwards compatibility is not guaranteed. If you run into problems, please get in touch with us here on the community forum.

## Volumes 🫶 Tigris

Since Tigris [launched](https://www.tigrisdata.com/blog/object-storage-public-beta/) earlier this year, we’ve had quite a bit of interest in using Tigris as the provider for object-storage backed volumes. We’re really excited about this combination too! This setup was possible via `fly storage create` (or adding a Tigris bucket during `fly launch`) plus a bit of environment-variable tweaking, but it’s now a bit easier through the `fly volumes lsvd setup` command directly. When you run `fly volumes lsvd setup` and select `Tigris` as the service, it will automatically create a Tigris bucket with all necessary secrets on your app to get going.

We also made a small tweak to the `lsvd` binary to recognize the `BUCKET_NAME` environment variable that the Tigris extension sets by default (in addition to `FLY_LSVD_S3_BUCKET`), to make the integration smoother.

## Multiple Machines Support

The initial release of object-storage backed volumes came with this warning:

> For now, don’t run more than one LSVD-enabled machine per app! They’ll conflict with each other and corrupt your volume.

This is now supported- each instance can upload its logs to a different prefix in the same bucket (currently `lsvd/$FLY_MACHINE_ID` by default), so running multiple LSVD-enabled machine instances per app works out of the box.

Note that this prefix change is incompatible with existing deploys of LSVD-enabled machines. If you need backwards compatibility for an existing volume, set the `FLY_LSVD_KEY_PREFIX=/` environment variable, or rename/move existing object files to the new prefix.

## Fly App support

The initial release required you to add an `--lsvd` flag to the `fly machines run` command to create a machine with the required `lsvd` background daemon running to provide the volume. Now, the daemon automatically starts on any machine with `FLY_LSVD_*` variables set in its environment, no additional flags required.

* * *

## Speedrun

These three updates combined make it easier to launch an app with object storage-backed volumes: After creating an app, run `fly volumes lsvd setup`, select `Tigris`, enter the volume size and mount path, then deploy like usual. That’s it!

Feedback and additional testing will be tremendous help as we continue iterating on this feature, so please feel free to try it out, kick the tires a bit and let us now how it’s working (or not) for you! We’re actively working on this and hope to have more updates ready to share soon.

---

<div class="post-metadata">

**Author:** ![agad](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/agad/32/45886_2.png) [@agad](https://community.fly.io/u/agad)\
**Post date:** [July 12, 2024, 2:25pm UTC](https://community.fly.io/t/tigris-backed-volumes/20792/2 "2024-07-12T14:25:24Z")

</div>

Just FYI, the link to the example database using S3 currently throws an error if I try to visit [https://ct-log-viewer.fly.dev/](https://ct-log-viewer.fly.dev/).

---

<div class="post-metadata">

**Author:** ![Alex21](https://avatars.discourse-cdn.com/v4/letter/a/5e9695/32.png) [@Alex21](https://community.fly.io/u/Alex21)\
**Post date:** [July 12, 2024, 9:13pm UTC](https://community.fly.io/t/tigris-backed-volumes/20792/3 "2024-07-12T21:13:20Z")

</div>

> [@wjordan](#):
>
> each instance can upload its logs to a different prefix in the same bucket

Does this mean that each instance sees its own separate filesystem? Or are they able to share files? E.g., if one instance writes a file “test.txt”, can the other instances read it?

---

<div class="post-metadata">

**Author:** ![Cavalato](https://avatars.discourse-cdn.com/v4/letter/c/cdc98d/32.png) [@Cavalato](https://community.fly.io/u/Cavalato)\
**Post date:** [November 28, 2024, 4:49pm UTC](https://community.fly.io/t/tigris-backed-volumes/20792/4 "2024-11-28T16:49:40Z")

</div>

Hey Jordan

Do you have an ETA on when this will be ready for production loads?

What are the dangers on our side if we jump into this before it is officially supported?

---

<div class="post-metadata">

**Author:** ![morse](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/morse/32/39591_2.png) [@morse](https://community.fly.io/u/morse)\
**Post date:** [February 26, 2025, 9:39am UTC](https://community.fly.io/t/tigris-backed-volumes/20792/5 "2025-02-26T09:39:46Z")

</div>

This feature would be awesome for my use case: a video generator using assets uploaded by the user to generate an edited video. Is this feature still being actively developed?

---

<div class="post-metadata">

**Author:** ![angusfretwell](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/angusfretwell/32/40865_2.png) [@angusfretwell](https://community.fly.io/u/angusfretwell)\
**Post date:** [April 9, 2025, 5:22am UTC](https://community.fly.io/t/tigris-backed-volumes/20792/6 "2025-04-09T05:22:36Z")

</div>

Adding to the chorus! Is there an ETA on this being production-ready, or has development been abandoned?

I’m running a PHP application (CiviCRM) on Fly which writes data to the filesystem, and changing the application to use object storage directly isn’t feasible in the short term. So right now I’m stuck deploying to a single Fly machine with an attached volume.

I’ve explored using GeeseFS to mount a Tigris bucket as a FUSE filesystem, but it’s not stable or performant enough.

This sounds like a promising solution for my use-case. I’ll probably give it a whirl regardless, but would love some clarity on what the future looks like for this feature.
