Install Discourse on macOS for development

:warning: This guide covers installation instructions for a macOS development environment, for production guides see: Install Discourse in production with the official, supported instructions

So you want to set up Discourse on macOS to hack on and develop with?

We’ll assume that you don’t have Ruby/Rails/Postgres/Redis installed on your Mac. Let’s begin :rocket: !

Install Discourse Dependencies

Run this script in your Terminal (or equivalent), to setup your machine for Discourse development:

bash <(curl -s

This script will install following new packages on your system:

In case you have any of this package pre-installed and don’t want to run entire script, see the script and pick the packages you don’t have currently installed. The script is fine-tuned for Discourse, and includes all the packages required for Discourse installation.

restart your terminal

Now that we have installed Discourse dependencies, let’s move on to install Discourse itself.

Restart your Terminal

Exit your shell and restarting it ensures that the paths to the installed packages are correctly picked up by the Terminal.

Clone Discourse

Clone the Discourse repository in ~/discourse folder:

git clone ~/discourse

~ indicates home folder, so Discourse source code will be available in your home folder.

Bootstrap Discourse

Switch to your Discourse folder:

cd ~/discourse

Install the needed gems

bundle install

Install the JS dependencies

yarn install

Next, run these commands to set up your local Discourse instance:

bundle exec rake db:create
bundle exec rake db:migrate
RAILS_ENV=test bundle exec rake db:create db:migrate

Start rails + Ember servers, you have two options here.

Option 1: using two separate Terminal tabs/windows, run Rails and Ember CLI separately via

bundle exec rails server



Option 2: using only one Terminal tab/window:

bin/ember-cli -u # will run the Unicorn server in the background

:tada: You should now be able to navigate to http://localhost:4200 to see your local Discourse installation. (Note that the first load can take up to a minute as the server is warmed up.)

You can also try running the specs:

bundle exec rake autospec

All (or almost all) the tests should pass.

Create New Admin

To create a new admin, run the following command:

RAILS_ENV=development bundle exec rake admin:create

Follow the prompts to create an admin account.

Configure Mail

Run MailHog:


Congratulations! You are now the admin of your own Discourse installation!

Happy hacking! And to get started with that, see Beginner’s Guide to Creating Discourse Plugins.

Last edited by @JammyDodger 2024-05-25T08:40:14Z

Check documentPerform check on document:

If anyone is getting failing specs with most of them being .count errors, then try the following:

RAILS_ENV=test bundle exec rake db:reset

I had a problem where development data somehow got into my test database and was causing lots of failures.


Is it possible to reset a discourse completely?


Yes, do:

rake db:drop db:create db:migrate

Note that this will wipe everything and you will have to create your Admin user account again.


Can someone assist me in how I can update my discourse?

/launcher rebuild app

returns an error.

1 Like

./launcher rebuild app is for discourse_docker based production setup. To update local/development Discourse instance you need:

cd ~/discourse
git pull origin master

I get this error @techAPJ,

error: Your local changes to the following files would be overwritten by merge:
Please commit your changes or stash them before you merge.

The error message is pretty clear:

Please commit your changes or stash them before you merge.

If you want to ignore your local changes, do:

git fetch origin
git reset --hard origin/master

Using the guide from the Ruby on Rails forum, I’m currently stuck on step 7.

This is probably a very “newbie” question, but how do I “point” to the experimental branch that was linked in that topic? I tried a few things and was ultimately giving the Unknown command mini_racer, message every single time.

1 Like

They’re fine asking here.

There are some specific m1 instructions we wrote that we reference on the rails forum in this guide.

I’d have to look on my m1 air later, and maybe my fellow coworks who recently setup new macs might know better if this is even still needed, but there is an example of how to point to a branch in step 7:

gem 'mini_racer', github: 'rubyjs/mini_racer', branch: 'refs/pull/186/head'

So you would edit this line in your local version of discourse/Gemfile:

and then run bundle install.


It’s linked right at the top of the original post.

The topic from the Ruby on Rails forum has been dead for many months now. The OP hasn’t been active since Feburary and hasn’t replied to any comments there asking for help.

There are more people to help me here. Just saying. :wink:

I tried copying that into Terminal and received the same Unknown command mini_racer, error from before.

Admittedly, the guide from the Ruby on Rails forum isn’t as clear as I’d hope in that regard.

Apologies in advance… :pray:


It’s not a command to run. You will need to EDIT the actual text file called “Gemfile” located inside the discourse directory.

1 Like

Doh! :facepalm:

Thanks! Let me try that right now.

In my opinion, somebody should edit the guide from the Ruby on Rails forum and provide further clarification regarding step 7. Just my two cents though.

I will be right back. Hold on a second…

1 Like

Sorry I have to run, but I think that mini_racer fix for m1 macs has been merged in. I just checked my Gemfile on my m1 mac and mine isn’t edited. So I think you can skip step 7.


I ran step 8 and received the Could not locate Gemfile error.

I (think) I was able to figure out step 7, but step 8 is still giving me trouble and is spitting out the error mentioned above.

You need to be inside of the discourse directory when you run bundle install.

Hi @merefield: Can you describe your remote setup a little more?

While developing a theme allows me to add changes on a live site, for developing a plugin I don’t see any way around doing it on my local machine, having the whole discourse codebase there (with my plugin on top of it).

The result is that for any (non-css) change when coding a plugin, when I reload it 1) kicks off my computer’s fan and 2) takes a solid 30 seconds to reload. And if I need to restart the server, it takes several minutes.

Those delays really add up–with the result that it might take me an hour to code something up that with my normal coding flow (where there’s hot reload or at most 2-3 seconds per change) would take 15 minutes.

So, I’d appreciate any suggestions for speeding things up.

This arguably would be better on the Ubuntu topic, as I’m just running that install on a cloud server, fronted by nginx and a full DNS (no docker), so I’m actually addressing the domain. Running everything from the terminal. I’ve even got Ember CLI working well in that set up now.

It’s not that quick either, but fast enough. It has the benefit of being able to run and test full https callback services.

The fastest plugin development environment by far that I’m aware of is local Docker Dev on WSL2 which screams. It’s also extremely simple to maintain. Unfortunately discourse_theme doesn’t work in that environment yet afaik so I’m back to my cloud server for that work.

It’s a little odd why Apple is lagging behind here? The Microsoft engineers have shown themselves to be very canny.


In case someone gets errors trying to install ruby 2.7.3, apparently something changed after Xcode 12 which breaks the install process with rbenv:

I kept getting this, even though I have the latest versions of psych and libyaml installed:

It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.

I tried the workaround they suggest in the guide, but I kept getting the same error and ended up having to use rvm:

rvm install 2.7.3
1 Like

Regarding how to program faster when doing a plugin, I’ve recently changed my approach. And it’s working great. Basically, move any front end stuff to a theme component, and only code the backend stuff in the plugin itself. I know others have figured that out before. But now that I’m doing it, programming is so much faster and nicer. Details here.