[FEAT]: Move some of the config options from file to database

[aleksasiriski]

Continuation of #628 (comment)

[ralgar]

Thanks for opening this.

EDIT: The more I thought about this last night, the more I realized that @onedr0p is right about this. While the pattern I am currently using has worked well for me, it's still hacky, and it's mostly a hangover from being limited by SQLite.

Postgres implementation opens up new doors that are almost certainly better. For example, I could still bootstrap an initial configuration, and then rely on the migrations to do their thing. Secret rotation could be accomplished at runtime, using a sidecar or similar.

[aleksasiriski]

I think onedr0p made an excellent point, config files / env should only be declared (not changed during runtime) and everything that can and should be changed during runtime should be inside the database (like radarr, sonarr, prowlarr, etc.).

[onedr0p]

If anything, there's an opportunity to write automation for building out and bootstrapping jellyseerr with using the jellyseerr API so you can write 3rd party tools to help provision an instance of jellyseerr. However this is all overkill for me as it's a one-time process, if I was bootstrapping jellyseerr constantly I would look into contributing / writing tooling to help provide that functionality.

[ralgar]

One thing I've realized is that moving certain parameters into the DB could potentially force a user into having to manually edit the DB, under certain (probably rare) circumstances.

For example: My Jellyseerr instance uses Jellyfin as the sole authentication backend. If the URL of the Jellyfin server changes for some reason, and I don't update it in Jellyseerr beforehand, I will be completely locked out of the Web UI. If I'm not able to revert the networking environment to its previous state (let's say I have no ownership or control of it), then I'm forced to edit the endpoint URL manually.

This generally wouldn't be an issue for those of us running Docker/Podman/K8s, or running virtual networks, etc. For users with more basic setups though, for example Proxmox + VMs/LXCs + networking that relies on their LAN's DHCP, this could end up forcing them into database surgery.

Just something to consider.