Beginners Guide to Install Discourse for Development using Docker

Need bunele install each shutdown_dev then boot_dev, it’s a problem?

I had problems running this on nixos, because the scripts were not POSIX complaint.
I solved the issue with these changes: make docker dev install posix compliant by spirobel · Pull Request #7995 · discourse/discourse · GitHub


Did you test all the helpers? It is quite a sweeping change

1 Like

I made a list of all the files and went through all of them. They all worked. Afterwards I ran the checkbashisms script on them and I discovered something very weird.

bin/docker/boot_dev x
possible bashism in bin/docker/boot_dev line 35 (should be VAR="${VAR}foo"):
what it is: ENV_ARGS+=" -e $2"

what would be sh complaint: ENV_ARGS="${ENV_ARGS} -e $2"

bin/docker/rails x
possible bashism in bin/docker/rails line 4 (alternative test command ([[ foo ]] should be [ foo ])):
if [[ $# = 1 ]] && [[ “$1” =~ “s” ]];
bin/docker/unicorn x
possible bashism in bin/docker/unicorn line 4 (alternative test command ([[ foo ]] should be [ foo ])):
if [[ $# = 1 ]] && [[ “$1” =~ “s” ]];

so why did the scripts still work even though they shouldnt?
nixos /bin/sh is actually bash. Probably its best to talk with the people at nixos what is going with this. They seem to be really strict about not having /bin/bash but whats the point if thats bash anyway? There seems to be an effort to get discourse to be a nix package aswell: Its probably really nice for deployment and testing (if it works). Anway…all I wanted to do is write a discourse plugin … and now I am reading about this. :laughing:


Yeah I am not against bin/sh but it needs to be ported and the scripts use bash-isms now.

Symlink bin/bash ?

1 Like

I will do that. I think this was all a waste of time. (sorry for that :upside_down_face: ) This problem is clearly on the side of nixos. It has many benefits and I like using it, but this thing was just weird.


The Docker development flow now supports plugin symlinks, with two caveats:

  1. The symlink must refer to its target with an absolute path:

    - ln -s ../../discourse-plugin
    + ln -s ~/src/discourse-plugin
  2. Whenever a new plugin symlink is created, the Docker container must be restarted:

    d/shutdown_dev; d/boot_dev

Hopefully someone else will also find this useful!

(Also updated the topic wiki)


This is awesome, thanks heaps for the new feature, real happy to have parity with this setup!


Trying to get to the rails console to run SiteSetting.enable_sso = false on a Mac Docker dev install. Where do I need to be to do that?

d/rails c

from the root directory of discourse.


Thanks so much, Sam.

For others seeing this, you have to follow the above exactly. e.g. you can’t use rails c from the the d directory.

From within the d directory you’d need to run ./rails c, rails c would give you whatever rails was in your path, not the one in d.

I am not sure if my issue is directly related to yours, but I had the same error message.
I was using the vagrant file mentioned at the bottom of GitHub - discourse/discourse_docker: A Docker image for Discourse

Then I was using the cloned discourse folder inside of /vagrant, e.g. part of my “outer host”. This was not working and I ended up with the above error message.

Once I cloned discourse into a folder outside of /vagrant (e.g. /home/vagrant/workspaces/discourse) everything worked as documented.

I hope that helps …

I’ve had a look through here and a quick google search to no avail: is there an obvious reason why a dev Discourse instance would close connections; and if not, is there a way to track down why it is doing so?

I have set up Docker and git clone'd as per the instructions in a new Virtualbox VM (two in fact, first Arch, then Ubuntu Server 19.10).

./bin/docker/boot_dev --init goes fine, admin account set up without complaints. I run ./bin/docker/unicorn (with or without sidekiq) and it reports I, [2019-11-01T17:24:29.121913 #234] INFO -- : listening on addr= fd=33.

From there I browse to http://$VM_IP:9292, and it refuses to connect. Even trying telnet fails:

bertieb@ubunutu-vm:~/discourse$ telnet 9292
Connected to
Escape character is '^]'.
Connection closed by foreign host.

There is no obvious error in the logs or reported in unicorn’s output.

This happens with docker versions:

  • Docker version 18.06.1-ce, build e68fc7a (Ubuntu system repo)
  • Docker version 19.03.3-ce, build a872fc2f86 (Docker repos)
  • Docker version 19.03.4-ce, build 9013bf583a (Arch)

Is the issue particular to VMs? The Docker versions? The versions of Ubuntu/Arch I’m using? Something else entirely?

(PS: I ran the tests on one of the VMs, they completed after 15 minutes with only one failure, something to do with a default favicon. I didn’t save the output as it seemed unrelated to the issue, but I can run the tests again if needed)

1 Like

This was an issue but is now resolved as of FEATURE: allow publishing docker dev either locally or net wide · discourse/discourse@ff33899 · GitHub.

Connectivity now works as intended. If like me you happened to install a dev version after ~28th Oct but before today, git pull to update. Note the new -p flag to d/boot_dev if you want to listen for remote connections.


The problem is that the user within the docker container has an id of 1000 so unless your user also has an id of 1000 you will get permission denied when it tries to make changes to the local files / create new files.

I think the directories are:

  • tmp
  • app/assets/javascripts/plugins
  • public
  • log
  • db

Should the auto reload work when editing the plugin.rb? Or do I need to run d/unicorn -x each time I make a change

It should, but I don’t think it does properly, it is a very difficult problem.

It works for things outside the after_initialize do block, but anything inside the block will not auto-reload. I think technically the code does get reloaded, but it only gets run when the server boots, so reloading it isn’t very helpful.

Unfortunately it would require a pretty large architecture change to enable live reload on most plugin APIs.


How would these instructions be modified to encompass using Docker Machine instead of straight Docker Engine?