Is launcher rebuild app required for maxmind key upgrade?

Quick question:

If we add our MaxMind key to app.yml do we have to run launcher rebuild app for this configuration change?

Am guessing the answer is "of course, noob, you must rebuild" but would refer not to rebuild since it wipes some changes we prefer to keep in the Docker Discourse app (like our mysql migration config, some import scripts, etc).

Routinely, I make sure we have fresh backup copies of our custom scripts in our /shared/mygoodstuff directory, but have also added some begin, rescue, end code to various files, so would prefer not to rebuild, if possible and avoidable, to install maxmind key.

Any good news or, as I suspect as a noob, am I “sandwich out of luck” on this?



For config update, it needs just

./launcher destroy app
./launcher start app

But I’m afraid that for Maxmind it needs to download geodb and this is part of the rebuild app.

I also need some small changes… Is there any recommended practice to keep this in place after rebuild probably using git and clever app.yml hack? git cherry pick comes to mind…


You can create templates that apply your changes to the new container when it is built. You can look in templates/import for examples.

When I have a custom import script, I keep it in a persistent volume and have a shell script that copies it to the right place and then runs it.


On a similar question… if I may :slight_smile:

On a live site, and we do the launcher rebuild app magic, the site often goes down for a short period of time during the rebuild / restart process. Sometimes we notice a nginx “bare bones” page during the hiccup period, other times some text message indicating the site is not available.

What is the best practice to insure the site is down (not viewable) for the least amount of time during launcher rebuild app even for a second or two? For example, during a backup, the site remains visible and we see the now is not a good time to post kinda message; but during launch rebuild app the behavior is more bare bones.

Am I doing something wrong when I do a the launcher rebuild app magic because regardless of the server and setup, there is always some downtime where users will see something we don’t want them to experience?

That is the main basic for my original question, and the reason we want to avoid launcher rebuild app for a config change.

Any best practices or clues for a noob on this?



Some config changes only require a:

./launcher stop app
./launcher destroy app
./launcher start app 

This works for stuff like email server settings.

Anything else which requires data be transferred or manipulated (plugins, maxmind db etc) will need a rebuild.

The majority of upgrades are zero-impact, and can be done via Two or three times a year, a base image change will necessitate a full rebuild. The most effective way to do those is a two-container install. Running two containers separates the database from the application, and speeds up rebuild times significantly.

The one other thing I would recommend to reduce downtime is to build yourself a staging site: a representative copy with all the same plugins, themes and components. Before taking down your main site to add a plugin or make any changes, test it away from your live copy. It will significantly reduce the chance of an outage due to error, plugin compatibility or similar technical problem.

That way you’re only impacting your users once, and already know it will work.



Thanks for that suggestion. Do you know of a good tutorial on this; as I am still getting my head around Docker; or better yet do you mind to describe how to this this here? Before, when I have tried some fancy Docker tricks I ended up making matters worse.

Yes, this is how I have been doing it so far. Make the major changes in the staging site and then when we are happy with the changes, make a backup, sftp that backup to the main site and then manually (on the command line), run discourse restore. This method results in a simple the site is currently in read only mode (paraphrasing) message and remains up, visible to the users during transition. This works nicely based on my two weeks very noob experience.

However, the two Docker container approach on the same server you mentioned seems interesting as well. The problem, at least for me in my noobiness, is that when I have tried this in the past (a few times last week), I had major problems getting Discourse to run on ports different than :80 and :443 regardless of how skillful I tried to modify app.yml.

Basically, I tried:

  • cp -rf /var/discourse /var/discourse2
  • edit app.yml in /var/discourse2/containers (changing the port mappings for :80 and :443)
  • ./launcher rebuild app

… and I always get some failure message where Docker cannot access the new ports I have specified like :8080 or :4443.

I’m sure it just a Docker rookie mistake on my part; but I cannot get it to work.

However, this method has worked well for me, consistently:

  1. Take a backup of production site.
  2. sftp that backup to the staging site
  3. restore staging site with snapshot from production
  4. make changes
  5. ./launcher rebuild app
  6. test, and if successful
  7. make backup of staging site
  8. sftp that backup to the production site
  9. restore production site with backup from staging site

This is a lot of work to just add our maxmind key :slight_smile: so hopefully I can learn how to get the two docker container solution to work well.

1 Like

You can safely add the MaxMind key and trigger a rebuild (which is necessary as the MaxMind database needs to be downloaded once a valid key is provided).

Apologies if I created some confusion in my description of the two-container install above. I wasn’t suggesting you just copy your app.yml and run two containers side-by-side on different ports. The two-container install is to separate the app and database elements of a single install. Your existing site would go from one container to two. It makes servicing either element (i.e. running launcher rebuild) much quicker.

Look at the two-container install as a future project, it’s not a necessity for now. There’s more info on it in this topic:


Thanks @Stephen

I tried that on a staging machine; as follows:

  • Got a new maxmind key from their web site in my account.

  • Added the newly minted key in app.yml like so:





  • Yet, In each attempt after launcher rebuild app, the results are the same, getting a 401 Error: Invalid license key

#<Thread:0x000055ffa3d98908@/var/www/discourse/lib/tasks/assets.rake:219 run> terminated with exception (report_on_exception is true):
/var/www/discourse/lib/tasks/assets.rake:231:in rescue in block (2 levels) in <top (required)>': undefined local variable or method name’ for main:Object (NameError)
from /var/www/discourse/lib/tasks/assets.rake:220:in block (2 levels) in <top (required)>' /var/www/discourse/lib/file_helper.rb:59:in block in download’: 401 Error: Invalid license key (OpenURI::HTTPError)
from /var/www/discourse/lib/final_destination.rb:399:in block (3 levels) in safe_get' from /var/www/discourse/lib/final_destination.rb:398:in catch’

Have tried this a number of times with freshly minted keys and in each case, we get the 401 invalid key, which makes no sense to me, because we are using freshly minted license keys (and read a number of meta topics on this as well)

Am I missing some other environmental variable?

Currently, we are using using DISCOURSE_MAXMIND_LICENSE_KEY

All builds fine if we comment out DISCOURSE_MAXMIND_LICENSE_KEY FYI.


Just to confirm, the key is one of the free Geolite2 keys, and you signed up here to get it?

The yml can be pretty picky with formatting, is your DISCOURSE_MAXMIND_LICENSE_KEY: indented to the same level as the other items in your env: section?


Yea and yes…

Screen Shot 2020-03-22 at 1.51.36 PM

Honestly, I checked those things many times before asking the question; free free to check and confirm.

In the attached image, it is commented out because if I uncomment them, launcher rebuild app fails.

I did notice in when looking at my account, that maxmind seemed to have recognized a key a week ago, so I’m trying to rebuild with that key now.

Will post back the results.



On the development / staging server, using the first maxmind key assigned, launcher rebuild app was successful and it’s working in the admin area.

Regarding my original question, I don’t see anyway around launcher rebuild app because taking a snapshot of the DB on the staging server and restoring it on production will not eliminate the need for doing a launcher rebuild app on production.

As I understand the backup and restore process (not that I understand it fully like you guys), that process is about the postgress DB and not Gem and bundles, so I don’t see any way around launcher rebuild app on the production server.


Bit the bullet, added the working maxmind key to the production app.yml and did the launcher rebuild app magic during the slow weekend time, and all is fine :slight_smile:


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