-
-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store images somewhere else than S3 #65
Comments
A relatively simple change could be to support S3 providers other than AWS and allow configuring the endpoint via an additional environment variable like Support for additional storage methods may not be necessary beyond this. There are FOSS options for S3 compatible storage so there would be no vendor lock-in. Focusing storage options on a single method may help keeping complexity lower, too. |
Looks like next-s3-upload has support for the endpoint already: |
support for storage on a local file system might be useful for homelab deployments |
it could, but you should also just be able to use for example Minio in order to reach the same functionality, and since you are running multiple containers already (postgres+app) i don't think the overhead of adding for example Minio would hurt too much. EDIT: it will complicate serving the images (you would need to expose your minio instance to the internet), while something like storing locally in a static folder might work well with only leaving the spliit app open to the internet |
I tried getting Minio running locally and got it to work with uploading the image to the bucket, but not with then showing it. I think you would have to make it work with serving images via presigned URLs (in addition to uploading via presigned URLs) in order to get it to work. I can continue looking into it another day if this would be a suitable solution? |
It seems we both gave it a try in parallel. 🙂 I'd be glad to hear your feedback to my attempt: #71 |
Looks very similar to my try! Except yours handles the next config parts way better than my solution. Very nice work! |
Regarding exposing to the internet, one of my concerns is having too many ports open on a home server so I have been trying to embed spliit as an add-on for homeassistant so that I can use a single open port as the entry point or their nabucasa proxy (see #56). The app would then be available from the homeassistant app and this along with all of my other tools are available in one place. This would solve the public URL problem too as the MinIO url would be considered local. |
Yeah, I run everything behind a reverse proxy, so I have only port 443 open to the internet, but using different sub-domains. But I do see the use case of being able to just source them from a static file directory. |
I would also prefer local storage for home-lab environments. MinIO makes it more complex overall and another service that has to be hardened against external threats. |
Should look to keep documents stored locally as for home-lab users looking to keep everything in-house would make the most sense. Once the docker hub image is available, you could look at integrating with other applications. If instead of uploading attachments into spliit, if we had the option to link to an outside URL, this would let me utilize my choice of document repository. Using paperless can create a document link, when I create an "Attachment" on a receipt in spliit, I could just put that paperless shared doc URL as value for that attachment type. This would be versatile because spliit users could then easily store these documents anywhere, (google drive, Paperless-ngx, nextcloud, ETC). |
@justcallmelarry could you please share how you configured Minio so the images are actually displayed in Spliit (PUT works fine). |
Any updates on this? |
FYI I am currently in the process of adding local file support (see my fork) so that S3 is not needed anymore. |
@swiftbird07 I had the problem of intergrating the minio docker image with the spliit docker image also. I could upload an image with PUT, but when the split application tried to do a GET it failed. For me, one of the solutions was to open the port 9000 ( The port minio was using for the buckets ) on my docker machine using UFW. There could have been other configuration changes that contributed to the application working I can share if it would help? I modified the composer file to use the minio image so they share a network. If you are still interested in fixing this, I'm happy to share what I have done! :) It took me a while to trouble shoot this. |
Yes I would appreciate that. Especially how did you set up the permissions etc? |
The steps I took for setup were as follows:
You can change the image to use the latest like this:
So my full compose.yaml looks like this:
I needed to use an older image due to the age of the machine running the images 😅
I've changed the relevent options to improve security like not mapping the db ports, and creating users for the bucket instead of using the admin and locking down permissions now that it's all working, but to start with the above instructions is all I used. Hopefully it helps! |
Since #63, users can attach images to expenses, but they can be stored only on S3. If someone has the need to store images somewhere else (locally, on an FTP server…), feel free to comment here with your need and we’ll see how to implement it.
The text was updated successfully, but these errors were encountered: