Discourse is the 100% open source, next-generation discussion platform
built for the next 10 years of the Internet. Whenever you need a mailing
list, a forum to discuss something, a chat room where you can type paragraphs,
then consider Discourse.


This charm installs the Discourse application, http://discourse.org


After you've successfully bootstrapped an environment, run the following:

juju deploy cs:~marcoceppi/discourse
juju deploy postgresql

Then create relations

juju add-relation discourse postgresql:db-admin

Discourse requires db-admin level access in order to enable the hstore
plugin. Finally, expose discourse:

juju expose discourse


There are several configuration options you can use to manage your Discourse
deployment. With the exception of admins, all defaults should suffice for most
deployments. Take care when adjusting other options as they may produce an
unstable deployment if unexpected values are used.


In order to access the Discourse Admin tools you must specify which users
should be admins. After creating your account in Discourse, add your name and
the name of others who should be admin using this configuration option. The
option takes a string of comma separated usernames. You can find a username by
visiting a user's profile and copying the last part of the URL, in this case
"marcoceppi": http://meta.discourse.org/users/marcoceppi. To set just one
admin do the following:

juju set discourse admins="marcoceppi"

Where "marcoceppi" is the username. For multiple admins use commas to
separate values:

juju set discourse admins="marcoceppi,codinghorror,sam,eviltrout"

If a user does not exist they will not be granted admin access and will
simply be skipped.

This will not be updated when a user is granted access via the admin panel. Also,
in the event you need to remove an admin you'll not only have to update this
configuration option but you'll also need to Revoke admin in the admin panel.
This option is designed to set up "god" users, to recover a board if
administrative access is lost, and during initial setup to define who gets
access to the site after installation. Further moderator and admin assignments
should happen in the admin panel.


If you maintain a forked version of the Discourse repository, you can deploy or
swap to that modified repository at any time. It's recommended you use upstreams
git repo at https://github.com/discourse/discourse.git or at least monitor it
for security and feature updates.

juju set discourse repository="https://code.example.tld/repo/discourse.git"

In order to make use of the version option, you will need to push to your
Discourse repo with the --tags option. Otherwise git tags will not be moved
over which the version option relies on.


Release is an easy way to "pin" your install at a known and familiar version of
Discourse, allowing you to "upgrade" to another version when you're ready. By
default this Discourse charm deploys against the "latest-release" Git tag which
is pointed at the latest version of Discourse.

For production deployments of Discourse it's recommended you change this version
either during deployment or shortly after to the corrosponding release
of Discourse you deployed. Doing so will ensure that during scale-out you'll
maintain the same version of Discourse between units. Failure to do so may
result in broken behavior due to version inconsistency between units.

juju set discourse version="v0.9.1"

Release can be any valid git ref (git tag, git branch) in the given repository


This option allows you to control how many instances of thin you wish to run on
one unit. By default (auto) will select a number of 2 or greater depending on
machine resources (CPU and RAM) available. If you wish to override this behavior
you can manipulate this option as long as it's a positive integer. All other values
will result in "auto" being used.

juju set discourse thins=2

Upstream recommends at least 2 instances of thin running in order to properly
handle requests to the application.


If you wish to modify the environment variables sent to the Application you can
override them here. This option is designed to allow performance tweaking
to be done against a Discourse install. By default this charm will apply the
recommended performance tuning for the verion of Ruby installed. To remove these
simply set this configuration option to a blank string ("")

juju set discourse env="RUBY_GC_MALLOC_LIMIT=90000000"

You can specify multiple variables using a space between KEY=VAL pairings


These are additional things you can do to enhance your base install.

Shared queuing server

If you have a need for a scaled out queuing server, or if you find yourself
with many discourse units, it will be beneficial to use a separate redis
server for queue management. To conserve resources all units, by default,
have their own redis-server installed. However, you can deploy and add
a relation to the redis-master
charm in order to provide a central redis server.

juju deploy redis-master redis
juju add-relation discourse redis:db

In doing so the local redis-server installs will be removed and the site
re-configured to use the new redis service. For more information on scaling
out redis, refer to the redis-slave

Additional Help

Nothing yet?


                            Git tag (release) or branch of discourse repository. See README.md for additional details
                            Comma separated list of usernames who should be an admin. eg: "codinghorror,sam,eviltrout"

                            Fully qualified git url to repository of discourse application
                            Environment variables used when running the webserver serving Discourse (thin). See README.md for more information

RUBY_GC_MALLOC_LIMIT=90000000 LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.0.1.0
                            Number of thin clients to run, set to auto to have things spun up based on resources, otherwise any positive integer greater than 1