Install Discourse on Ubuntu or Debian for Development

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


So you want to set up Discourse on Ubuntu or Debian to hack on and develop with?

We’ll assume that you work locally and don’t have Ruby/Rails/Postgres/Redis installed on your Ubuntu or Debian system. Let’s begin!

Requirements

We suggest having at least 4 GB RAM and 2 CPU cores.

Current compatibility:

OS Compatibility
Debian 11 :white_check_mark:
Crostini (Linux on ChromeOS) :white_check_mark:
Ubuntu 22.04 or later :white_check_mark:

Install Discourse Dependencies

As regular user run this script in terminal, to setup Rails development environment:-

bash <(wget -qO- https://raw.githubusercontent.com/discourse/install-rails/main/linux)

This will install the following new packages on your system:

In case you have any of this package pre-installed and don’t want to run the 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.

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

Clone Discourse

Clone the Discourse repository in ~/discourse folder:

git clone https://github.com/discourse/discourse.git ~/discourse

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

Setup Database

Already completed by the install script

Create role with the same name as your Linux system username:

cd /tmp && sudo -u postgres createuser -s "$USER"

Bootstrap Discourse

Switch to your Discourse folder:

 cd ~/discourse

Install the needed gems

source ~/.bashrc
bundle install

Install the JS dependencies

yarn install

Now that you have successfully installed gems, run these commands:

bin/rails db:create 
bin/rails db:migrate
RAILS_ENV=test bin/rails db:create db:migrate

Start rails and ember server:

bin/ember-cli -u

If the images are not appearing, use this command instead:
(you can also specify an IP if you are working on a remote server)

DISCOURSE_HOSTNAME=localhost UNICORN_LISTENER=localhost:3000 bin/ember-cli -u

You should now be able to navigate to http://localhost:4200 to see your local Discourse installation.

Create New Admin

To create a new admin, run the following command:

bin/rails admin:create

Follow the prompts, and a new admin account will be created.

Configure Mail

Run MailHog:

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 Reviewed by @blake on 2023-04-03T06:00:00Z

63 Likes

Is there any way to use a non-standard database username (such as PSQLDiscourse instead of my username)?

Has anyone run into issues with Redis consuming a huge amount of memory in their local dev environment? Things got to the point where my computer couldn’t run Discourse (just the Rails server) and VS Code at the same time, so I figured I’d better look into what was going on.

From the redis-cli:

127.0.0.1:6379> INFO memory
# Memory
used_memory:6816179504
used_memory_human:6.35G
used_memory_rss:6887792640
used_memory_rss_human:6.41G
used_memory_peak:6817064312
used_memory_peak_human:6.35G
used_memory_peak_perc:99.99%
used_memory_overhead:47045661
...
total_system_memory:33565863936

I’m not sure if this is expected. It seems like a lot of keys:

27.0.0.1:6379> DBSIZE
(integer) 536194

Maybe a maxmemory value should be added to this script: install-rails/linux at main · discourse/install-rails · GitHub. For now I’m going with:

maxmemory 1073741824
maxmemory-policy allkeys-lru

That’s calmed things down a lot. Discourse still seems to be able to handle my dev site’s one simultaneous user. I also disabled backups and digest emails in on the local site.

Edit: 536194 keys seemed like a lot. I went ahead and deleted them from database 0 with FLUSHDB. That seems to have fixed the issue:

INFO memory
127.0.0.1:6379> INFO memory
# Memory
used_memory:58237032
used_memory_human:55.54M
used_memory_rss:66449408
used_memory_rss_human:63.37M
used_memory_peak:59375664
used_memory_peak_human:56.63M
used_memory_peak_perc:98.08%
used_memory_overhead:1186813
used_memory_startup:865888
used_memory_dataset:57050219
used_memory_dataset_perc:99.44%
allocator_allocated:58599296
allocator_active:59891712
allocator_resident:63754240
total_system_memory:33565859840
total_system_memory_human:31.26G
used_memory_lua:45056
used_memory_vm_eval:45056
used_memory_lua_human:44.00K
used_memory_scripts_eval:5064
number_of_cached_scripts:7
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:32768
used_memory_vm_total:77824
used_memory_vm_total_human:76.00K
used_memory_functions:184
used_memory_scripts:5248
used_memory_scripts_human:5.12K
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:allkeys-lru
allocator_frag_ratio:1.02
allocator_frag_bytes:1292416
allocator_rss_ratio:1.06
allocator_rss_bytes:3862528
rss_overhead_ratio:1.04
rss_overhead_bytes:2695168
mem_fragmentation_ratio:1.14
mem_fragmentation_bytes:8233048
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_total_replication_buffers:0
mem_clients_slaves:0
mem_clients_normal:204037
mem_cluster_links:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

I wish I’d looked at the keys before deleting them. It’s possible something was messed up with my dev install.

1 Like