A few days ago we added the ability to launch your apps with object storage provided by Tigris configured. This is a unique take on S3’s model as Tigris replicates objects globally to ensure they’re fast for anyone using your app, it works like a CDN and S3 combined. (I digress)
How it works
If you run fly launch from the command line and then choose to customize your app, you’ll be able to set up your bucket from the UI, like this:
Then, we’ll automatically set the following ENV variables in your app:
AWS_ACCESS_KEY_ID
AWS_ENDPOINT_URL_S3
AWS_REGION
AWS_SECRET_ACCESS_KEY
BUCKET_NAME
This should make it slightly easier to get your apps running with object storage!
You can read more about Tigris on Fly.io (check out shadow buckets if you’re migrating from S3, they’re very cool and make the process completely painless!)
8 Likes
I’d like clarification on the rfeplication pattern/strategy. I think it replicates to other regions based on the access pattern. Does it do this on the first or fifth request, or a mixed algorithm? Also, does the replication work with the cache-control header or not?
@pmbanugo, when data is replicated close to the user based on access pattern in a simplified form, you can think of it happening on first access. However, if the bucket has a high number of concurrent requests, then it may not strictly be the first request. You can also specifically control which regions you want the data stored in, as documented here.
The cache-control headers are used to control caching as well as return those headers with the object when the object is fetched.
1 Like
When I have max-age, and s-maxage in the cache values, which one does Tigris respect?
would s-maxage be considered in the future? Ideally to make browsers use a different ttl and CDNs or Tigris use s-maxage.
What happens if the cache-control header isn’t specified? how does it determine how long to keep it in the cache?
We will definitely be adding support for s-maxage so that browser can have a different TTL than the cached data in Tigris.
If the cache-control header is not specified, it is determined by several backend strategies to decide the duration. A maximum duration is assigned (1 hour for static assets and 15 minutes for other data), but data will be evicted from the cache earlier if the object is modified i.e. modification will evict the data from the cache irrespective of the duration.
Thanks. I’d be looking forward to it. I have a prototype app that I’d like to have some static asset have a very short TTL on the client/browser, but Tigris or intermediate proxy could cache for longer period.
Sounds good, I’ll let you know once we have this feature.
1 Like
