In a discussion titled ‘Where is %{base_url} coming from?’, di-rect reports that their Bitnami Discourse container uses ‘example.com’ for the %{base_url} variable in templates and cannot be changed post-installation. Falco notes Bitnami installs are unsupported here and recommends the standard Discourse install. di-rect clarifies their question is about the variable’s origin, not support. JammyDodger suggests a misconfigured install and recommends reinstalling with a backup. MichaIng advises editing the Docker Compose YAML before first run, pointing to lines 31 and 51. di-rect confirms changing it post-install doesn’t work and asks if it’s set statically. MichaIng dives into Discourse’s code, identifying current_hostname and force_hostname variables, noting force_hostname is hidden and not found in their DB dump. They speculate Bitnami may handle DISCOURSE_HOSTNAME differently. di-rect considers configuring as a single multisite and confirms not finding force_hostname in DB dumps [11]. MichaIng questions whether Bitnami’s container exposes Discourse directly or uses a reverse proxy like Nginx, as the official container does. The core issue remains: why %{base_url} defaults to example.com and how to override it reliably in Bitnami’s setup.
I’m running a Discourse container using the Bitnami image. The issue I experience there that all templates use example.com for the %{base_url} variable and I don’t seem to be able to change this.
I created a support ticket at Bitnami but while searching I never can find anywhere on the internet anything about the base_url variable.
We do not support installs using Bitnami images here. The recommendation is to install Discourse following the standard install guide if you want support.
I understand but that is in the base not my question: Where does %{base_url} come from or where is it based under ? I cannot even find that in the Discourse documentation or forum.
It sounds like something has gone wrong with your install if this isn’t being populated with the correct domain.
As has been mentioned, it may be easier for you to follow the standard install and restore a backup if you’ve still not managed to track down what’s gone wrong.
I know, but changing it after the first run doesn’t fix it, so I wonder if it needs to be done from the first run as I like to know if it sets this host(name) staticly or not.
Is the Bitnami container also compiling Discourse completely new when updating it, like the official one?
The variable seems to be defined here:
The current_hostname variable is set here:
The force_hostname variable is declared in the site settings template here:
As it is hidden, it cannot be changed in admin settings. As other site settings, I assume it would be stored in the database. I searched a database dump of our instance and force_hostname is not set or even declared. In our official discourse container YAML we have DISCOURSE_HOSTNAME assigned, but I guess this is a global setting, not a site setting, so this seems to be enforced differently.
current_hostname seems to be obtained from the current connecting, i.e. dynamic. But I cannot see where exactly it is defined, probably an external module/gem:
I’m not sure what the Bitnami container does with the DISCOURSE_HOST setting, so at least you could search your database for force_hostname until we find out more about how DISCOURSE_HOSTNAME from official container is stored and enforced.
Thank you for your support so far! I was, comparing to you findings, also thinking about config my install as single multisite. This could maybe make it work, but it’s indeed a matter of trying to sort things out where I have the feeling that Bitnami doesn’t change anything on Discourse itself; so why this issue indeed.
Okay so currently I fail do understand where/how both Discourse container variants internally apply the hostname based on the container YAML.
Does the Bitnami container composition not include another webserver but expose the Discourse web port directly? The official containet has another Nginx in front of Discourse, something I actually wanted to get rid of if possible, as we have another Apache webserver outside of the container already.