Specifying URL base via environment variable

Feature Requests
#1

I think this is a feature request, but if this is already possible, please tell me how :slight_smile:

I’m putting together a comprehensive set of services for my HTPC needs, these include Sonarr, Radarr, Deluge and more. I’m doing this using docker-compose.

As I’m starting multiple services that all have web UIs, I want to start an nginx reverse proxy as well that would simplify the way these web UIs are accessed, so instead of htpc-server:8989 for sonarr and htpc-server:7878 for radarr, I could simply go to htpc-server/sonarr and htpcs-server/radarr.

However, that means that I would have to configure the URL Base in the configuration file before starting the sonarr container. This is a bit of a hazzle (having to do some config file editing magic every time before the container start to make sure that the config option in config.xml matches the correct base url).

A much simpler solution would be if I could start the container up with an environment variable that specifies the URL base string.

So my question is: is this already possible?

If not, where do I create a feature request?

I would imagine that this would be as simple as “if environment variable SONARR_URL_BASE is set, use that, otherwise fall back to old behavior of reading the config file”.

#2

The location of your config file (more specifically the AppData directory) should be somewhere that survives a container restart anyway. I’m a bit puzzled how you manage it now…

#3

The config file directory is in a persisted volume yes. So the file is there.

But, only being able to specify the base url in the config file means that I have to put the value of it into an environment variable (for docker-compose) and then I’ll have to do some XML file manipulation magic to get that value into the config file before starting the container.

A much simpler approach would be to be able to just pass that env variable into the sonarr container and have it take care of it.

Besides, this is where most services that run in docker are heading, the ability to specify config via environment variables is used a lot but from the looks of it, sonarr isn’t going that route. I’m guessing that docker isn’t being considered as a first class deployment citizen. A bit weird IMO, but so be it.

I did put in a feature request but that got shut down pretty quick: https://github.com/Sonarr/Sonarr/issues/3184

#4

A base url is one of those “do this once” thingies imo. Either straight in the config file or through the GUI the first time you start sonarr.
Probably the easiest would be to create a config.xml file with the settings you want, and tell docker-compose to launch sonarr using that config.xml

I can understand the devs, it’s a very 1% feature (once again, imo) to set it via environment variables, and invites support hell and code for it has to be maintained / taken into account when making other changes to the application.
I guess from their point of view, there is a perfectly viable solution: config.xml.

#5

Environment variables for config conflicts with the config file. In addition to introducing more code to maintain you end up in a situation where the user has specified an environment variable and there is a different value in the config file, what do the settings show? What happens if the user changes the setting, since that wouldn’t take effect. What happens if Sonarr is restarted in the container? There are more edges than there are gains with this I feel.

You could have a script that runs before Sonarr starts that seeds the config file with values, this would mean a custom image unless you can convince the bigger images to take that on.

My config is as simple as:

    volumes:
      - ./data/:/config

Then I ship the .data directory and the docker-compose.yml file like Thirrian suggested.

I disagree that to have first class docker support you need to support environment variables for configuration, if everyone jumped off a bridge we wouldn’t jump too.

#6

even simpler than just using a specific hostname for that container/service?

eg, i’ve got a reverse entry for sonarr.home:80 to nas.home:32800 (to docker port 8989)

no need to tell sonarr its behind a reverse proxy, it just works, or at least is for me.

#7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.