Deploy your Bitnami Discourse Stack on 1&1 Cloud Platform now! Launch Now

Bitnami Discourse for 1&1 Cloud Platform


Discourse is an open source discussion platform with built-in moderation and governance systems that let discussion communities protect themselves from bad actors even without official moderators.

First steps with the Bitnami Discourse Stack

Welcome to your new Bitnami application running on 1&1 Cloud Platform! Here are a few questions (and answers!) you might need when first starting with your application.

What credentials do I need?

You need two sets of credentials:

  • The application credentials that allow you to log in to your new Bitnami application. These credentials consist of a username and password.
  • The server credentials that allow you to log in to your 1&1 Cloud Platform server using an SSH client and execute commands on the server using the command line. These credentials consist of an SSH username and key.

What is the administrator username set for me to log in to the application for the first time?

Username: user

What SSH username should I use for secure shell access to my application?

SSH username: root

What are the default ports?

A port is an endpoint of communication in an operating system that identifies a specific process or a type of service. Bitnami stacks include several services or servers that require a port.

IMPORTANT: Making this application's network ports public is a significant security risk. You are strongly advised to only allow access to those ports from trusted networks. If, for development purposes, you need to access from outside of a trusted network, please do not allow access to those ports via a public IP address. Instead, use a secure channel such as a VPN or an SSH tunnel. Follow these instructions to remotely connect safely and reliably.

Port 22 is the default port for SSH connections.

Bitnami opens some ports for the main servers. These are the ports opened by default: 80, 443.

How to start or stop the services?

Each Bitnami stack includes a control script that lets you easily stop, start and restart services. The script is located at /opt/bitnami/ Call it without any service name arguments to start all services:

$ sudo /opt/bitnami/ start

Or use it to restart a single service, such as Apache only, by passing the service name as argument:

$ sudo /opt/bitnami/ restart apache

Use this script to stop all services:

$ sudo /opt/bitnami/ stop

Restart the services by running the script without any arguments:

$ sudo /opt/bitnami/ restart

Obtain a list of available services and operations by running the script without any arguments:

$ sudo /opt/bitnami/

How to configure outbound email settings?

To configure SMTP settings using an external SMTP server, you have to add the lines indicated below to the /opt/bitnami/apps/discourse/htdocs/config/discourse.conf:

smtp_address = "SMTP_HOSTNAME"
smtp_port = SMTP_PORT
smtp_domain =
smtp_user_name = 'SMTP_USER'
smtp_password = 'SMTP_PASSWORD'
smtp_enable_start_tls = true

Restart the servers:

$ sudo /opt/bitnami/ restart

SMTP configuration for Gmail

Warning: If you use Discourse extensively, we recommend to use your own SMTP server for sending emails. The current Gmail sending limit is 500 emails per 24 hours.

An example for Gmail is as follows. Replace USERNAME and PASSWORD with your Gmail account username and password respectively.

smtp_address = ""
smtp_port = 587
smtp_domain =
smtp_user_name = ''
smtp_password = 'PASSWORD'
smtp_enable_start_tls = true
authentication = plain

To configure the application to use other third-party SMTP services for outgoing email, such as SendGrid or Mandrill, refer to the FAQ.

NOTE: If you are using Gmail as the outbound email server and have experienced issues trying to send emails correctly, check the How to troubleshoot Gmail SMTP issues to learn the causes of these issues and how to solve them.

How to install a plugin on Discourse?

You might want to extend the functionality of Discourse by installing a plugin. If you want to do this, you must get the repository URL for the plugin (where PLUGIN_REPO_URL is the URL to the repository of the plugin you want to install, like:

You will have to execute the following commands:

$ cd /opt/bitnami/apps/discourse/htdocs
$ RAILS_ENV=production bundle exec rake plugin:install repo=PLUGIN_REPO_URL
$ RAILS_ENV=production bundle exec rake assets:precompile

How to remove a plugin on Discourse?

To remove a Discourse plugin, follow these steps:

  • Log in to the server console.
  • Navigate to the Discourse plugins directory:

      $ cd /opt/bitnami/apps/discourse/htdocs/plugins
  • Execute the following commands, replacing PLUGIN-DIR with the name of the directory containing the plugin you wish to remove:

      $ rm -rf PLUGIN-DIR
      $ RAILS_ENV=production bundle exec rake assets:precompile

How to create a full backup of Discourse?


The Bitnami Discourse Stack is self-contained and the simplest option for performing a backup is to copy or compress the Bitnami stack installation directory. To do so in a safe manner, you will need to stop all servers, so this method may not be appropriate if you have people accessing the application continuously.

Follow these steps:

  • Change to the directory in which you wish to save your backup:

      $ cd /your/directory
  • Stop all servers:

      $ sudo /opt/bitnami/ stop
  • Create a compressed file with the stack contents:

      $ sudo tar -pczvf application-backup.tar.gz /opt/bitnami
  • Restart all servers:

      $ sudo /opt/bitnami/ start

You should now download or transfer the application-backup.tar.gz file to a safe location.


Follow these steps:

  • Change to the directory containing your backup:

      $ cd /your/directory
  • Stop all servers:

      $ sudo /opt/bitnami/ stop
  • Move the current stack to a different location:

      $ sudo mv /opt/bitnami /tmp/bitnami-backup
  • Uncompress the backup file to the original directoryv

      $ sudo tar -pxzvf application-backup.tar.gz -C /
  • Start all servers:

      $ sudo /opt/bitnami/ start

If you want to create only a database backup, refer to these instructions for MySQL and PostgreSQL.

How to upgrade Discourse?

It is strongly recommended to create a backup before starting the update process. If you have important data, create and try to restore a backup to ensure that everything works properly.

Migrating the database

Follow the steps below to migrate the database from an old version to a new one:

  • Create a database backup of the running application with the following command:

     $ pg_dump -U postgres bitnami_discourse > backup.sql 
  • Create a tarball with the uploaded files of the running application:

     $ tar -czvf uploads.tar.gz /opt/bitnami/apps/discourse/htdocs/public/uploads
  • Copy both backups to the server hosting the new version.

  • On the new server, stop all servers and start only PostgreSQL:

     $ sudo /opt/bitnami/ stop
     $ sudo /opt/bitnami/ start postgresql
  • Remove the previous database:

     $ psql -U postgres 
     drop database bitnami_discourse;
     create database bitnami_discourse;
     alter database bitnami_discourse owner to bn_discourse;
     create extension hstore; create extension pg_trgm;
  • Restore the new database:

     $ psql -U postgres bitnami_discourse < backup.sql
  • Start the Redis server and migrate the database:

     $ sudo /opt/bitnami/ start redis 
     $ cd /opt/bitnami/apps/discourse/htdocs 
     $ bin/rake db:migrate RAILS_ENV=production
  • Restore the uploaded files in the new server:

     $ tar -xzvf uploads.tar.gz -C /
  • Restart all servers:

     $ sudo /opt/bitnami/ start

Keeping in sync with the Discourse repository at GitHub

IMPORTANT: This procedure is supported since the Bitnami Discourse Stack v0.8.5-0.
NOTE: This is an advanced feature that should be used only by someone that knows the application and what is happening at every step of the process described below. If not, there is a new Discourse version available every week and the standard process to upgrade the whole stack can be followed.

Since Discourse changes very fast, the Bitnami Discourse Stack includes the .git files necessary to stay in sync with the repository.

As some configuration parameters are adjusted during the installation, there may be some differences between the installed version and the repository even if the installer was built recently. Follow these steps:

  • Change to the Discourse application directory:

     $ cd /opt/bitnami/apps/discourse/htdocs
  • Stop the Apache and Discourse services:

     $ sudo /opt/bitnami/ stop apache
     $ sudo /opt/bitnami/ stop discourse_sidekiq
  • Stop and disable the Clockwork service if your current Discourse version uses it. This step is not required since v0.9.6.1.

     $ sudo /opt/bitnami/ stop discourse_clockwork
     $ sudo mv /opt/bitnami/apps/discourse/scripts/ /opt/bitnami/apps/discourse/scripts/
  • Edit the file /opt/bitnami/scripts/ and comment the line:

     . /opt/bitnami/scripts/
  • Edit the file /opt/bitnami/ruby/.bundler/config and comment the line:

     BUNDLE_BUILD__NOKOGIRI: --with-iconv-dir=/opt/bitnami/common
  • Change to the Discourse application directory:

     $ cd /opt/bitnami/apps/discourse/htdocs
  • Checkout the master branch and pull the latest version. You will need to checkout the Gemfile and Gemfile.lock files to overwrite Bitnami's changes to support offline installations. Note that you will need to configure Git as described in the Troubleshooting section to stash the changes if this is the first time you're using it.

     $ git checkout Gemfile*
     $ git checkout bin
     $ git stash
     $ git checkout master
     $ git pull
     $ git checkout tags/vLATEST_VERSION
     $ git stash apply
NOTE: You may need to remove raindrops, unicorn and kgio gems from the Gemfile.lock file.
  • Execute the following command:

      $ sudo bundle install --without development test sqlite --binstubs --deployment
  • Apply any new database migrations:

     $ sudo /opt/bitnami/ruby/bin/ruby bin/rake db:migrate RAILS_ENV=production
  • Recompile the application assets (it may take a few minutes):

     $ sudo chmod 666 log/production.log
     $ sudo /opt/bitnami/ruby/bin/ruby bin/rake assets:precompile RAILS_ENV=production
  • Remove the Discourse cache:

     $ sudo rm -rf tmp/cache
  • Restart Apache and Discourse servers:

     $ sudo /opt/bitnami/ start


  • If you run git and you get this output:

     Please tell me who you are.

    Run the commands below, replacing the placeholders with your name and email address:

     $ git config --global ""
     $ git config --global "Your Name"  
  • If you see the following error:

     rake aborted!
     cannot load such file -- rb-inotify

Check that you are running the command using the rake command in the Discourse directory and that the command is running in production mode:

    $ export RAILS_ENV=production
    $ cd /opt/bitnami/apps/discourse/htdocs
    $ bin/rake bundle install
  • If there is a merge conflict, it should be fixed manually. You will see an error like this:

     $ git stash apply
     Auto-merging app/assets/javascripts/discourse/routes/discourse_location.js
     CONFLICT (content): Merge conflict in app/assets/javascripts/discourse/routes/discourse_location.js
     Auto-merging app/assets/javascripts/discourse.js

    To resolve this, the files listed must be edited. There are two options:

    • Keep local changes. For each conflicting file:

      • Remove everything from <<<<<<< Updated upstream to ======= and the line >>>>>>> Stashed changes. Then, run the following command:

            $ git add FILENAME
      • Check everything. Output of this command should be as shown:

            $ git status
            Already up-to-date.
      • Unstage changes automatically set to be committed.

            $ git reset HEAD
    • Discard local changes. For each conflicting file:

      • Remove everything from ======= to >>>>>>> Stashed changes and the line <<<<<<< Updated upstream. Then, run the following command:

            $ git add FILENAME
      • Check everything. Output of this command should be as shown:

            $ git status
            Already up-to-date.
      • Unstage changes automatically set to be committed.

            $ git reset HEAD
  • On Linux 32-bit instances, you may have problems with the gem libv8- because there is no precompiled version of this gem for this platform. An easy workaround would be to edit the Gemfile.lock file and replacing libv8 ( with libv8 (

How to create an SSL certificate?

OpenSSL is required to create an SSL certificate. A certificate request can then be sent to a certificate authority (CA) to get it signed into a certificate, or if you have your own certificate authority, you may sign it yourself, or you can use a self-signed certificate (because you just want a test certificate or because you are setting up your own CA).

Follow the steps below:

  • Generate a new private key:

     $ sudo openssl genrsa -out /opt/bitnami/apache2/conf/server.key 2048
  • Create a certificate:

     $ sudo openssl req -new -key /opt/bitnami/apache2/conf/server.key -out /opt/bitnami/apache2/conf/cert.csr
    IMPORTANT: Enter the server domain name when the above command asks for the "Common Name".
  • Send cert.csr to the certificate authority. When the certificate authority completes their checks (and probably received payment from you), they will hand over your new certificate to you.

  • Until the certificate is received, create a temporary self-signed certificate:

     $ sudo openssl x509 -in /opt/bitnami/apache2/conf/cert.csr -out /opt/bitnami/apache2/conf/server.crt -req -signkey /opt/bitnami/apache2/conf/server.key -days 365
  • Back up your private key in a safe location after generating a password-protected version as follows:

     $ sudo openssl rsa -des3 -in /opt/bitnami/apache2/conf/server.key -out privkey.pem

    Note that if you use this encrypted key in the Apache configuration file, it will be necessary to enter the password manually every time Apache starts. Regenerate the key without password protection from this file as follows:

     $ sudo openssl rsa -in privkey.pem -out /opt/bitnami/apache2/conf/server.key

Find more information about certificates at

How to enable HTTPS support with SSL certificates?

TIP: If you wish to use a Let's Encrypt certificate, you will find specific instructions for enabling HTTPS support with Let's Encrypt SSL certificates in our Let's Encrypt guide.
NOTE: The steps below assume that you are using a custom domain name and that you have already configured the custom domain name to point to your cloud server.

Bitnami images come with SSL support already pre-configured and with a dummy certificate in place. Although this dummy certificate is fine for testing and development purposes, you will usually want to use a valid SSL certificate for production use. You can either generate this on your own (explained here) or you can purchase one from a commercial certificate authority.

Once you obtain the certificate and certificate key files, you will need to update your server to use them. Follow these steps to activate SSL support:

  • Use the table below to identify the correct locations for your certificate and configuration files.

    Variable Value
    Current application URL https://[custom-domain]/
      Example: or
    Apache configuration file /opt/bitnami/apache2/conf/bitnami/bitnami.conf
    Certificate file /opt/bitnami/apache2/conf/server.crt
    Certificate key file /opt/bitnami/apache2/conf/server.key
    CA certificate bundle file (if present) /opt/bitnami/apache2/conf/server-ca.crt
  • Copy your SSL certificate and certificate key file to the specified locations.

    NOTE: If you use different names for your certificate and key files, you should reconfigure the SSLCertificateFile and SSLCertificateKeyFile directives in the corresponding Apache configuration file to reflect the correct file names.
  • If your certificate authority has also provided you with a PEM-encoded Certificate Authority (CA) bundle, you must copy it to the correct location in the previous table. Then, modify the Apache configuration file to include the following line below the SSLCertificateKeyFile directive. Choose the correct directive based on your scenario and Apache version:

    Variable Value
    Apache configuration file /opt/bitnami/apache2/conf/bitnami/bitnami.conf
    Directive to include (Apache v2.4.8+) SSLCACertificateFile "/opt/bitnami/apache2/conf/server-ca.crt"
    Directive to include (Apache < v2.4.8) SSLCertificateChainFile "/opt/bitnami/apache2/conf/server-ca.crt"
    NOTE: If you use a different name for your CA certificate bundle, you should reconfigure the SSLCertificateChainFile or SSLCACertificateFile directives in the corresponding Apache configuration file to reflect the correct file name.
  • Once you have copied all the server certificate files, you may make them readable by the root user only with the following commands:

     $ sudo chown root:root /opt/bitnami/apache2/conf/server*
     $ sudo chmod 600 /opt/bitnami/apache2/conf/server*
  • Open port 443 in the server firewall. Refer to the FAQ for more information.

  • Restart the Apache server.

You should now be able to access your application using an HTTPS URL.

How to force HTTPS redirection with Apache?

Add the following lines in the default Apache virtual host configuration file at /opt/bitnami/apache2/conf/bitnami/bitnami.conf, inside the default VirtualHost directive, so that it looks like this:

<VirtualHost _default_:80>
  DocumentRoot "/opt/bitnami/apache2/htdocs"
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R,L]

After modifying the Apache configuration files:

  • Open port 443 in the server firewall. Refer to the FAQ for more information.

  • Restart Apache to apply the changes.

How to debug Apache errors?

Once Apache starts, it will create two log files at /opt/bitnami/apache2/logs/access_log and /opt/bitnami/apache2/logs/error_log respectively.

  • The access_log file is used to track client requests. When a client requests a document from the server, Apache records several parameters associated with the request in this file, such as: the IP address of the client, the document requested, the HTTP status code, and the current time.

  • The error_log file is used to record important events. This file includes error messages, startup messages, and any other significant events in the life cycle of the server. This is the first place to look when you run into a problem when using Apache.

If no error is found, you will see a message similar to:

Syntax OK

Updating the IP address or hostname

Discourse requires updating the IP address/domain name if the machine IP address/domain name changes. The bnconfig tool also has an option which updates the IP address, called --machine_hostname (use --help to check if that option is available for your application). Note that this tool changes the URL to http://NEW_DOMAIN/discourse.

$ sudo /opt/bitnami/apps/discourse/bnconfig --machine_hostname NEW_DOMAIN

If you have configured your machine to use a static domain name or IP address, you should rename or remove the /opt/bitnami/apps/discourse/bnconfig file.

$ sudo mv /opt/bitnami/apps/discourse/bnconfig /opt/bitnami/apps/discourse/bnconfig.disabled
NOTE: Be sure that your domain is propagated. Otherwise, this will not work. You can verify the new DNS record by using the Global DNS Propagation Checker and entering your domain name into the search field.

You can also change your hostname by modifying it in your hosts file. Enter the new hostname using your preferred editor.

$ sudo nano /etc/hosts
  • Add a new line with the IP address and the new hostname. Here's an example. Remember to replace the IP-ADDRESS and DOMAIN placeholders with the correct IP address and domain name.


How to find the PostgreSQL database credentials?

How to connect to the PostgreSQL database?

You can connect to the PostgreSQL database from the same computer where it is installed with the psql client tool.

$ psql -U postgres

You will be prompted to enter the *postgres* user password. This is the same as the [application password](/1and1/faq#how-to-find-application-credentials).

How to access phpPgAdmin?

For security reasons, phpPgAdmin is accessible only when using as the hostname. To access it from a remote system, you must create an SSH tunnel that routes requests to the Apache Web server from This implies that you must be able to connect to your server over SSH in order to access these applications remotely.

IMPORTANT: Before following the steps below, ensure that your Apache and PostgreSQL servers are running.
NOTE: The steps below suggest using port 8888 for the SSH tunnel. If this port is already in use by another application on your local machine, replace it with any other port number greater than 1024 and modify the steps below accordingly. Similarly, if you have enabled Varnish, your stack's Apache Web server might be running on port 81. In this case, modify the steps below to use port 81 instead of port 80 for the tunnel endpoint.

Accessing phpPgAdmin on Windows

In order to access phpPgAdmin via SSH tunnel you need an SSH client. In the instructions below we have selected PuTTY, a free SSH client for Windows and UNIX platforms. The first step is having PuTTY configured. Please, check how to configure it in the section how to connect to the server through SSH using an SSH client on Windows.

Once you have your SSH client correctly configured and you tested that you can successfully access to your instance via SSH, you need to create an SSH tunnel in order to access phpPgAdmin. For doing so, follow these steps:

  • In the "Connection -> SSH -> Tunnels" section, add a new forwarded port by introducing the following values:

    • Source port: 8888
    • Destination: localhost:80

    This will create a secure tunnel by forwarding a port (the "destination port") on the remote server to a port (the "source port") on the local host ( or localhost).

  • Click the "Add" button to add the secure tunnel configuration to the session. (You'll see the added port in the list of "Forwarded ports").

    PuTTY configuration

  • In the "Session" section, save your changes by clicking the "Save" button.
  • Click the "Open" button to open an SSH session to the server. The SSH session will now include a secure SSH tunnel between the two specified ports.
  • Access the phpPgAdmin console through the secure SSH tunnel you created, by browsing to
  • Log in to phpPgAdmin by using the following credentials:

    • Username: postgres
    • Password: application password. (Refer to our FAQ to learn how to find your application credentials).

Here is an example of what you should see:


If you are unable to access phpPgAdmin, verify that the SSH tunnel was created by checking the PuTTY event log (accessible via the "Event Log" menu):

PuTTY configuration

Accessing phpPgAdmin on Linux and Mac OS X

To access the application using your Web browser, create an SSH tunnel, as described below.

  • Open a new terminal window on your local system (for example, using "Finder -> Applications -> Utilities -> Terminal" in Mac OS X or the Dash in Ubuntu).
  • Run the following command, remembering to replace SERVER-IP with the public IP address or hostname of your server. Enter your SSH password when prompted.

         $ ssh -N -L 8888: bitnami@SERVER-IP
NOTE: If successful, the above command will create an SSH tunnel but will not display any output on the server console.
  • Access the phpPgAdmin console through the secure SSH tunnel you created, by browsing to
  • Log in to phpPgAdmin by using the following credentials:

    • Username: postgres
    • Password: application password. (Refer to our FAQ to learn how to find your application credentials).

Here is an example of what you should see:


How to modify PHP settings for Apache?

The PHP configuration file allows you to configure the modules enabled, the email settings or the size of the upload files. It is located at /opt/bitnami/php/etc/php.ini.

For example, to modify the default upload limit for PHP, update the PHP configuration file following these instructions.

After modifying the PHP configuration file, restart both Apache and PHP-FPM for the changes to take effect:

$ sudo /opt/bitnami/ restart apache
$ sudo /opt/bitnami/ restart php-fpm

How to modify the allowed limit for uploaded files in Apache?

Modify the following options in the /opt/bitnami/php/etc/php.ini file to increase the allowed size for uploads:

; Maximum size of POST data that PHP will accept.
post_max_size = 16M

; Maximum allowed size for uploaded files.
upload_max_filesize = 16M

Restart PHP-FPM and Apache for the changes to take effect.

$ sudo /opt/bitnami/ restart apache
$ sudo /opt/bitnami/ restart php-fpm    

How to upload files to the server with SFTP?

Although you can use any SFTP/SCP client to transfer files to your server, the link below explains how to configure FileZilla (Windows, Linux and Mac OS X), WinSCP (Windows) and Cyberduck (Mac OS X). It is required to use your server's private SSH key to configure the SFTP client properly. Choose your preferred application and follow the steps in the link below to connect to the server through SFTP.

How to upload files to the server

How to create a backup of Discourse using the admin interface?


To backup, follow the steps below:

  • Log in to the application as an administrator.
  • Select the "Admin -> Backups" menu item.
  • Click the "Backup" button.

    Discourse backup

It is possible to create a backup with or without uploaded images. Note this process could take some time depending on your database and the size of the uploaded files.

Once the backup has been created, download the backup file and store it in a safe location.


Restoring a backup in Discourse is disabled by default. To restore, follow the steps below:

  • Log in to the application as an administrator.
  • Enable restoration using the "Settings -> Backups -> Allow restore" menu.

    Discourse restore

  • Select the "Admin -> Backups" menu item.
  • Upload the backup file and restore its contents.
IMPORTANT: Discourse requires you to manually the postgres user's password, by editing the /opt/bitnami/postgresql/bin/ file and adding the line below:

How to change the default administrator email?

During the deployment of Discourse, the administrator email used by default is As the administrator user, you most likely want to change it to your personal email address.

Changing the default administrator email requires an email verification from the current email address, which is not possible from the Discourse settings panel. To do so, you need to perform some queries in the PostgreSQL database.

Follow the steps below in order to change the default administrator email in Discourse:

  • Log in to the server console. Refer to our FAQs to learn how to connect to the server through SSH.
  • Run the commands below:

      $ cd /opt/bitnami/apps/discourse/htdocs/
      $ sudo RAILS_ENV=production bundle exec rails c

    A new prompt should appear, as shown below:

  • At the prompt, run the following commands to change the email address of the default user account to a new email address. Replace the EMAIL_ADDRESS placeholder in the commands below with your desired email address:

      u = User.find_by_username("user") = "YOUR_NEW_EMAIL_ADDRESS"

The default administrator email address will be changed. You can verify the changes in your application admin panel:

  • In the top right menu, click the "Hamburger" button and select the "Admin" option.

    Discourse admin panel

  • Navigate to the "Users" section. You can check that the email associated with the admin user has changed:

    Discourse default admin email changed

How to enable multisite support?

Follow these steps to enable multisite support:

  • Create a new database and database user for the new site. Execute the following commands at the server console, remembering to replace the DATABASE_NAME, DATABASE_USER and DATABASE_PASSWORD placeholders with actual values.

     $ /opt/bitnami/postgresql/bin/psql -U postgres -c "CREATE DATABASE DATABASE_NAME;"
     $ /opt/bitnami/postgresql/bin/psql -U postgres -c "ALTER DATABASE DATABASE_NAME OWNER TO DATABASE_USER;"
     $ /opt/bitnami/postgresql/bin/psql -U postgres -d database_name -c "CREATE EXTENSION HSTORE; CREATE EXTENSION pg_trgm;"
  • Copy the config/multisite.yml.production-sample file:

     $ sudo cp /opt/bitnami/apps/discourse/htdocs/config/multisite.yml.production-sample /opt/bitnami/apps/discourse/htdocs/config/multisite.yml
  • Edit the file to use the database created previously. Replace the DATABASE_NAME, DATABASE_USER and DATABASE_PASSWORD placeholders with actual values, and the HOSTNAME placeholder with the host name for the new site.

       adapter: postgresql
       database: DATABASE_NAME
       username: DATABASE_USER
       password: "DATABASE_PASSWORD"
       host: /opt/bitnami/postgresql
       pool: 25
       timeout: 5000
       db_id: 2    # ensure db_id is unique for each site
       ### If you change this setting you will need to
       ###   - restart sidekiq if you change this setting
       ###   - rebake all to posts using: `RAILS_ENV=production bundle exec rake posts:rebake`
         - HOSTNAME
  • For testing purposes, add the new hostname to the /etc/hosts file, as below:

  • Migrate the database

     $ cd /opt/bitnami/apps/discourse/htdocs
     $ bin/bundle exec bin/rake multisite:migrate RAILS_ENV='production'
  • Create an administrative user:

     $ bin/rake admin:create RAILS_ENV='production' RAILS_DB=DATABASE_NAME

You should now be able to access your new site using the new domain name.

How to enable SSL in Discourse?

First, configure Apache to enable SSL connections. Then, force HTTPS for all Discourse links using one of the following options:

  • Enable the following option in the Discourse config file at /opt/bitnami/apps/discourse/htdocs/config/site_settings.yml:

       enable_flash_video_onebox: false
       use_https: true
NOTE: In Discourse versions prior to v0.9.8.1, the option name is use_ssl instead of use_https.
  • Update the HTTPS port entry in the database by following the steps below:

    • Log in to the server console.

    • Start the MySQL command-line client and connect to the MySQL database.

    • Execute the following SQL command, replacing the NEW_PORT placeholder with the number of the SSL port. If the SSL port is 443, leave the NEW_PORT placeholder empty.

        mysql> UPDATE site_settings SET value = 'NEW_PORT' WHERE name = 'port'
  • Disable HTTP and redirect all requests to HTTPS URLs.

  • Restart the server:

     $ sudo /opt/bitnami/ restart

How to use a CDN?

If using a CDN, users could experience problems with Discourse icons under Firefox. To fix this error, uncomment these lines in the /opt/bitnami/apps/discourse/conf/httpd-app.conf file:

<FilesMatch "\.(ttf|otf|eot|woff|font.css)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"

How to change to development mode?

Follow these steps:

  • Copy the production database settings to the development section of the config/database.yml file. If you prefer, you can also populate a new database.

  • Stop the Apache server:

     $ sudo /opt/bitnami/ stop apache
  • Checkout the latest Gemfile and Gemfile.lock files and install the required gems:

     $ cd /opt/bitnami/apps/discourse/htdocs
     $ git checkout Gemfile*
     $ sudo bundle install --without test sqlite
  • Clean assets

     $ ruby bin/rake assets:clean
  • Start the server in development mode. Instead of Apache with Passenger you can use the Thin server:

     $ sudo rails server -p 80

The Sidekiq and Clockwork servers run in production mode by default. Change the mode in the Clockwork script at /opt/bitnami/apps/discourse/scripts/, as shown below:

CLOCKWORK_START="/opt/bitnami/ruby/bin/ruby $DISCOURSE_HOME/bin/clockworkd start --clock=$DISCOURSE_HOME/config/clock.rb --log --pid-dir=$CLOCKWORK_PIDDIR --log-dir=$CLOCKWORK_PIDDIR RAILS_ENV=production"

Similarly, change the mode in the Sidekiq script at /opt/bitnami/apps/discourse/scripts/

SIDEKIQ_START="/opt/bitnami/ruby/bin/ruby $DISCOURSE_HOME/bin/sidekiq -P $SIDEKIQ_PIDFILE -e production -L 

Bitnami Documentation