[Feature Request] Object Storage

[rjhenry]

I run most of my tools in Kubernetes, making use of object storage to minimise dependencies on local storage for uploads (and the like). Would adding the ability to use S3 (or S3-compatible tools, such as MinIO) be something that would be considered? I would imagine that this would work in the same way as using Postgres for a database, where backups are explicitly not managed by LubeLog any more.

Taking a rough look at a temporary Docker instance I started, it looks as though images and documents (/App/wwwroot/images and /App/wwwroot/documents respectively) could be reasonably easily replaced with object storage.
Translations (translations, /App/wwwroot/translations) look like a viable candidate to be replaced with a ConfigMap mounted to the right directory (and managed outside of LubeLog itself beyond selecting the language to use). This would only work for Kubernetes deployments, but similar could be accomplished in Docker "vanilla" by mounting a particular file in rather than a directory. Alternatively, support for object storage here would also work.
Config (config, /App/config/) looks like it could be a prime candidate to be migrated into the database - from the looks of things, you already do when authentication is enabled. Is it used for anything else?
Data - when using Postgres - looks to be unused so I haven't looked at this at all.
The only remaining directory that I am slightly confused by is the keys directory - from what I can tell, files and images aren't encrypted in any way, so I'm unsure as to what the keys are used for and by extension how that could be "kubernetes-ified". Possibly mounting via a secret, or possibly from some kind of env var?

I don't know much C# otherwise I would be trying to implement this myself, but I am more than happy to run tests and the like.
Thanks for spending your time and effort on a fantastic tool for the community!

[hargata]

I'd think the documents, images and translation files would be the easiest to migrate over, but the tricky part would be the config and keys directory.
The config file is still used for authenticating the root user(the first set of credentials you set up when you enable authentication) and the settings in there is the default settings for all new users(they inherit the settings such as dark mode, etc. from the base server config)

The keys directory is the trickiest one since changing it from the default directory to any other directory will require a lot of additional configuration. The keys are used for encrypting / decrypting session cookies to prevent spoofing and is an implementation provided by Microsoft.

[rjhenry]

Thanks for the well-thought-out response. Do you think a middle ground wherein documents, images and translation files are in object storage and then the other config and keys are managed on a persistent volume of some description?
It's less than ideal, as if that volume were to go away then the root user wouldn't be able to sign in and the sessions cookies would all be rendered useless, but does mean that documentation around vehicles is still preserved (and externally managed/backed up). It doesn't solve all the problems, but does at least mean the minimum of storage is required for the container/pod itself.

I wonder if anyone else would have any suggestions on how to manage config and/or keys directories?