[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.

[abelfodil]

e 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.

For something this fundamental, perhaps it should be moved to env variables? Or at least have the env var take precedence over DB

[abelfodil]

Following the discussion in #186 (comment), I propose migrating everything currently stored in settings.json into a database table (or multiple tables). This migration should be transparent, happening behind the scenes without disrupting the user experience.

While a provisioning mechanism would be a nice addition, I believe it’s important to stay focused on the initial goal: eliminating the reliance on volumes for storing settings.

Here’s my proposed re-implementation of the Settings module:

---

Option 1: Single KV Table (Preferred)

All existing settings would reside in a single table, using a key-value (KV) structure:

Column Name	Data Type	Description
id	SERIAL (PK)	Primary key
key	VARCHAR(255)	Unique key for the setting (e.g., "applicationTitle", "manageUsers")
value	JSONB	Value of the setting (can store any data type)
created_at	TIMESTAMP	Timestamp of creation

Note: JSONB is supported in both PostgreSQL and SQLite.

Note 2: Having the created_at field means the settings would be versioned, allowing users to undo their changes.

This approach offers maximum flexibility and allows for an almost 1:1 migration, as the underlying data type (JSON) remains unchanged.

A similar approach could be to store the entire settings.json file within a single row of the table and version that instead.

---

Option 2: Multiple Domain-Specific Tables

Alternatively, we could create separate tables for different domains of settings:

1. Organizers Settings: A table to store attributes for Radarr, Sonarr, and potentially Lidarr in the future, with a type identifier (e.g., Radarr/Sonarr). Suggested name: organizers_settings.
2. Streaming Apps: A table for Jellyfin, Emby, and Plex. Suggested name: streaming_apps.
3. Libraries: A table for libraries, with a foreign key linking to streaming_apps. Suggested name: libraries.
4. Notification Settings: A table for all notification agents. Suggested name: notification_settings.
5. Jobs Settings: A table for job configurations. Suggested name: jobs_settings.
6. Main Settings: A single table for core application settings.

While this approach is more structured, it feels excessive to create multiple tables for similar entities. Additionally, any new fields would require writing new migrations, which could complicate maintenance.

---

Bonus (Out of Scope)

1. Logs: Logs could be moved to a separate table, similar to how the *Arr apps handle logging (although they have a separate DB for them).
2. API Cache: The API cache could be moved to Redis. For the image cache, if the content is fetched from a CDN, it could remain as-is; otherwise, it could also be moved to Redis.
3. Jobs: Jobs could be moved to Redis, following a design similar to Immich’s implementation. This would allow jobs to be queued, ensuring that only a single instance handles a specific job in the queue.

[Fallenbagel]

(quoting a discussion in the Postgres feature request issue)

I feel like this defeats the purpose of this issue. The idea is to not require a persistent volume for important things like settings by using PostgreSQL.

While that may seem that way, the scope of current PR/issue for Postgres support was just put, to support Postgres with the current SQLite schema.

While this may be an unpopular opinion and might be disappointing for most of you, and I hope you understand where we are coming from, after careful consideration, at least for now, we do not plan to migrate settings.json to db for a couple of reasons (some of them have been discussed in the discussion above as well):

• settings.json allows users to do straightforward edits like changing the media server URL or other configurations (beneficial for average users)

• settings.json allows for easy migration of media servers since:

  • Values can be editted as mentioned before
  • It allows for the setup page to be called easily in scenarios where they need to update everything related to media Server like admin jellyfinUserIds while retaining their data, similar to how jellyfin/emby handles it with their XML configurations

• if moved to db, changing of media server url or migration like that will be harder (especially for average users who probably would need such a thing), like modifying ports, customise schedules with values not possible in Web ui, by using just a simple text editor

• Currently, it's very easy to just edit the settings.json to replace these values as json doesn't require additional database management tools or knowledge

• Small JSON files like settings.json introduces minimal overhead, as it is loaded into memory. These settings rarely change so I feel it's more practical

• JSON files are less prone to corruption in certain cases

• settings.json avoids introducing additional complexity and burden for maintainers (it is just two of us who are volunteering their free time) and support providers (who will get multiple support requests for the above-highlighted issues they could face)

• settings.json allows you to make changes and customise settings even just for testing rapidly

• users can easily share it which is very useful when providing troubleshooting/support (especially when it's usually just a single person doing this). If it were in db, it would make it more complex and time-consuming.

• and lastly easier backup because they will just need to copy a single file.

That's our decision on this matter, for now.