Acconut
commented
6 months ago The only idea I've had so far is that I can use the post-finish hook to see if this user has a custom S3 config and if they do, grab the new files and move it to their S3 account.
Yes, this is currently the best way to implement the desired behavior. Another option is to run one tusd process per upload destination, but that is only really doable if you have a predetermined number of upload destinations.
Perhaps the tusd s3store.go package can be modified to look for different S3 configs in a database or in the metadata before using the default S3 store?
It is possible and we are thinking about it because people keep asking for this feature, but we are not yet actively working on it :) That being said, we would prefer a solution that allows customization for all storages and is not limited to just the S3 storage, so people using GCS could also take advantage of this.
I hope this helps!
Question
I'm working on an app where user files will be stored on our own storage backend where we create a unique S3 bucket per user, or on their own S3 account if they provide the endpoint, access key, and secret key. How would you recommend we achieve this? The only idea I've had so far is that I can use the post-finish hook to see if this user has a custom S3 config and if they do, grab the new files and move it to their S3 account. But 1) that adds a new layer of complexity where things could possibly go wrong, and 2) this still incurs charges on our end because the file first has to touch our storage backend before then getting moved to the user's account, which also generates additional bandwidth usage.
Perhaps the tusd s3store.go package can be modified to look for different S3 configs in a database or in the metadata before using the default S3 store?