Beginners Guide to Install Discourse for Development using Docker

That hasn’t been the case for several months now. Engine version 18 of Docker for Windows eliminated the need for the Hyper-V instance and having Linux running under it. You can now run Docker in Windows directly on Windows using Docker Desktop and run Linux instances inside of it without issue. Since the boot_dev script in /bin/ used to install/setup/launch the initial instance isn’t Windows-compatible, it means those of us on Docker 2.x for Windows can’t make use of Discourse natively. I imagine there’s likely a way to remedy that simply, but it would probably require moving the install/setup to within the container build (i.e. the Dockerfile) instead of relying on a shell script to do it.

A big appeal of the current setup is all the external helpers. /bin/d/rails c to get a console and so on.

I feel a flow that relies on always being inside a container maybe somewhat trickier.

Maybe give a shot at converting all the helpers to power shell? then we can have windows native rails / rake and so on wrappers?

1 Like

FYI I just ran the test suite on my Linux machine once using docker dev and another using native.

  • Docker Dev: 8m6s
  • Native: 7m55

This very minor diff could be entirely due to randomness. You basically pay no price performance wise for using our docker dev env on Linux and are up and running in seconds.


Is there a big docker cost on Mac though?


Enormous, cause first the Linux that runs Docker needs to be virtualized and second you pay a huge tax on filesystem mounts.


Sam, do you have any best practices for developing plugins within a docker environment you would be willing to share? I can see the appeal of building in this environment and have set it up a few times, but it seems to be a very different mindset from a development stance.

For example, do you do your edits in the local discourse directory and then restart the container or is the flow very different?


The flow should be identical with Docker, only thing you need to be careful about it not having any symlinks inside the plugins directory. As long as you are directly checking out it should “just work” ™ with no fiddling. You do all the edits on local.


Awesome! And glad I asked. I’m stuck in my old ways with symlink and rm -rf tmp. Thanks!


Technically you could get symlinks to work its just you would need to add another mount to the docker dev container. It would require a minor PR to discourse to add support to this, we could walk symlinks and smart mount or something in boot_dev.

1 Like

Does anyone know why the image from discourse is not loading in this mode?

I think this is why your image is not loading.


Thank you for your advice.

I wanted to install plugins, so based on your advice, I retried to google and I found this:

This works well.

Thank you again.

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

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:

1 Like

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

Symlink bin/bash ?

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!

1 Like